Date: Sat, 7 Jul 2012 10:02:16 -0600 From: Warner Losh <imp@bsdimp.com> To: Stefan Bethke <stb@lassitu.de> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, Arnaud Lacombe <lacombar@gmail.com> Subject: Re: Interfacing devices with multiple parents within newbus Message-ID: <7AAA45BE-520B-4753-823E-D17D1AB0A5E0@bsdimp.com> In-Reply-To: <A1DF0EAD-65A4-4231-9F4B-08D8443BC241@lassitu.de> References: <CACqU3MU6iv%2Bo26fCdL5M6Kg6XMM1uZPih5FBiBKPOD9WDx%2BNGg@mail.gmail.com> <FEAC4049-11B0-4B3D-BB7A-0946DBBFF530@bsdimp.com> <CACqU3MWTKSpVRbJracCjSLVHko8RSpXw6vpC3o3UaAyTizos3A@mail.gmail.com> <A1DF0EAD-65A4-4231-9F4B-08D8443BC241@lassitu.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7AAA45BE-520B-4753-823E-D17D1AB0A5E0>