Re: Interfacing devices with multiple parents within newbus

On Jul 6, 2012, at 1:09 PM, Ian Lepore wrote:
> Just blue-sky dreaming here on the fly... what we really have is a
> resource-management problem.  A device comes along that needs a GPIO
> resource, how does it find and use that resource? =20

I rather like that idea.  The connection between devices is more like =
meta-data needed to obtain the resources/services that other devices =
provide.  You really want to talk in those terms, rather than in newbus =
attachments.

The platform told me that pin AT91_PIOA_12 is my interrupt line.  I'd =
like to wire up an ISR to that please.
The platform told me that pin AT91_PIOC_33 is the data pin for my two =
wire bus.  An error happened and to reset it I need to tell the pin =
muxing service to take it off line.  then I need to tell the GPIO =
service I have to force it high, let it flow, and force it low.
The platform told me that this NIC is connected to PHY 2 on miibus 3.  =
I'm the NIC driver and want to connect.
I'm the USB subsystem.  I'd like to know if one or two usb ports are =
connected to the HUB.  The hardware can't tell me, so the platform code =
has to give me hints.  If I allocate the pins for each of those two =
ports I'll know.  In some configurations, I can get both sets.  In =
others, I can only get one set.

All of those problems could be solved with newbus kobj connections.  Or =
they could be solved by the platform and/or drivers registering =
resources and services and the other drivers in the system using it.  =
Multipass would help a lot with that, since you could probe/attach all =
the service providers first, then everybody else could talk the higher =
level interfaces.

Warner

P.S. multipass could solve the dependency problem, but in kinda a poor =
way...

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"