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...Received on Sat Jul 07 2012 - 14:17:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:28 UTC