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?  
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-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Reply via email to