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:
>=20
>> I assume you are talking about =
devclass_get_device()/device_find_child().
>>=20
>> 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.
>>=20
>> About (1), lower unit devices can fails to attach[0], thus newly
>> attached bus will now have a negative offset.
>>=20
>> 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.
>>=20
>> 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.
>=20
> I believe there is one more thing that needs to be addressed, which I =
ran into while trying to do the arge/mdio attachment:
>=20
> 4) the device attach method may require access to the other device to =
complete the attachment, but that other might not be attached yet.
>=20
> 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=
_______________________________________________
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"