Re: Interfacing devices with multiple parents within newbus

On Jul 6, 2012, at 12:46 PM, Arnaud Lacombe wrote:

> Hi,
> 
> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe <lacombar_at_gmail.com> wrote:
>> That's neither correct nor robust in a couple of way:
>> 1) you have no guarantee a device unit will always give you the same resource.
> this raises the following question: how can a device, today, figure
> out which parent in a given devclass would give it access to resources
> it needs.
> 
> Say, you have gpiobus0 provided by a superio and gpiobus1 provided by
> the chipset and a LED on the chipset's GPIO. Now, say gpiobus0
> attachment is conditional to some BIOS setting. How can you tell
> gpioled(4) to attach on the chipset provided GPIO without hardcoding
> unit number either way ?
> 
> AFAIK, you can not.
> 
> Even hints provided layout description is defeated. Each device in a
> given devclass need to have a set of unique attribute to allow a child
> to distinguish it from other potential parent in the same devclass...

hints can hard-wire the device to a given bus.  This also can hard-wire the unit number, which will be stable even if one of them fails to attach.

But since the FDT language provides a richer set of connections than is possible with raw newbus, perhaps the solution to your problem should be handled in the FDT domain where you can look up a device name and have the FDT layer do the proper mapping into newbus rather than trying to guess at unit numbers.

The reference count problem would still be there, but that's a different issue that we have all over the place and need to solve before we can properly lock NEWBUS.

Warner