Re: Interfacing devices with multiple parents within newbus

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

> Hi,
>=20
> On Fri, Jul 6, 2012 at 11:33 AM, Arnaud Lacombe <lacombar@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.
>=20
> 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 ?
>=20
> AFAIK, you can not.
>=20
> 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

_______________________________________________
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"