Re: Interfacing devices with multiple parents within newbus

On Jul 7, 2012, at 6:25 AM, Stefan Bethke wrote:

> Am 06.07.2012 um 17:33 schrieb Arnaud Lacombe:
> 
>> I assume you are talking about devclass_get_device()/device_find_child().
>> 
>> 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.
>> 2) there is no reference counting on the returned device.
>> 3) there is no track record of the reference being given.
>> 
>> About (1), lower unit devices can fails to attach[0], thus newly
>> attached bus will now have a negative offset.
>> 
>> About (2) and (3), referenced device (think KLD) might go away and the
>> child will not be told. In this situation, I want the child to be
>> detached prior to its parent.
>> 
>> As such, looking up other node by name would fit in what I call
>> "bypassing newbus purpose". I might just as well export a damn
>> function pointer and make my life easier.
> 
> I believe there is one more thing that needs to be addressed, which I ran into while trying to do the arge/mdio attachment:
> 
> 4) the device attach method may require access to the other device to complete the attachment, but that other might not be attached yet.
> 
> Circular dependencies nonwithstanding, it would be highly desirable for a device driver developer to be able to simply declare all prerequisites for attachment, and have newbus call attach only after everything is there. Right now, the drivers attach method is called by the parent bus as soon as enumeration is completed.

The device should go ahead and attach.  When multiple devices need to communicate with each other, they need to coordinate things.  newbus is a weak coordination mechanism.  Stronger coordination mechanisms would be FDT or ACPI which can tie known devices to a device_t rather than to just a name.  The device_t will be around even if that device is attached and detached.

> A notification mechanism (similar to the devfs notification but with an exposed KPI) might be an alternative, as mentioned in this thread.

This would also work.   However, many of proposed uses for this seem more and more to me to need a non-newbus mechanism to cope with.  You'll absolutely require the notification method since devices can detach at any time.  Circular dependencies are way too easy to create.

In the Atmel work I'm doing and have done, there's devices that provide services to other devices (mostly pin muxing and GPIO).  I don't try to get the GPIO device to attach first, but rather have routines that can be called to accomplish these things.  During the early boot, I have to use the GPIO device to turn on pins so that I can even talk to things like the MII bus of the internal NIC.  While the GPIO devices have device_t's to allocate resources and to create dev_t nodes, I don't marshal everything through newbus. When I want to map a pin as an interrupt source for the PHY chip, that call is made directly.  When I need to shut off a device's pin and instead drive it via the GPIO logic, that's just a call. etc.

Warner