Re: Interfacing devices with multiple parents within newbus

Hi,

On Fri, Jul 6, 2012 at 3:09 PM, Ian Lepore
<freebsd_at_damnhippie.dyndns.org> wrote:
> On Fri, 2012-07-06 at 14:46 -0400, 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...
>>
>>  - Arnaud
>
> Talking about a child being unable to choose the correct parent seems to
> indicate that this whole problem is turned upside-down somehow; children
> don't choose their parents.
>
actually, I think I was wrong, I thought device were attached to a
devclass, but they are truly attached to a given device. My mistake.

> 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?
>
> Well, we have a resource manager, could that help somehow?  Could a
> driver that provides access to GPIO somehow register its availability so
> that another driver can find and access it?  The "resource" may be a
> callable interface, it doesn't really matter, I'm just wondering if the
> current rman stuff could be leveraged to help make the connection
> between unrelated devices.   I think that implies that there would have
> to be something near the root of the hiearchy willing to be the
> owner/manager of dynamic resources.
>
AFAIR, rman is mostly there to manage memory vs. i/o mapped resources.
The more I think about it, the more FTD is the answer. The open
question now being "how to map a flexible device structure (FTD) to a
less flexible structure (Newbus)" :/

 - Arnaud