Date: Fri, 6 Jul 2012 11:33:56 -0400 From: Arnaud Lacombe <lacombar@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Interfacing devices with multiple parents within newbus Message-ID: <CACqU3MWTKSpVRbJracCjSLVHko8RSpXw6vpC3o3UaAyTizos3A@mail.gmail.com> In-Reply-To: <FEAC4049-11B0-4B3D-BB7A-0946DBBFF530@bsdimp.com> References: <CACqU3MU6iv%2Bo26fCdL5M6Kg6XMM1uZPih5FBiBKPOD9WDx%2BNGg@mail.gmail.com> <FEAC4049-11B0-4B3D-BB7A-0946DBBFF530@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Fri, Jul 6, 2012 at 1:04 AM, Warner Losh <imp@bsdimp.com> wrote:
>
> On Jul 5, 2012, at 5:14 PM, Arnaud Lacombe wrote:
>
>> Hi folks,
>>
>> The problem has been raised in the last BSDCan during a talk, but no
>> clear answer has been given. Some (pseudo-)devices might require
>> resources from multiple other (pseudo-)devices.
>>
>> For example, a device is sitting on an SMBus, but need to access a
>> software controlled LED, sitting on a GPIO bus, itself sitting on an
>> LPC bus... Or a variant where everything is controlled on the same
>> chip, but different GPIO banks. For that specific example, all the
>> GPIO pin could be implement on the same GPIObus, however, gpiobus(4)
>> is limited to 32 pins and the chip provides 5 banks of 8 pins, ie. a
>> total of 40 pins[0]. In the same idea, a device sitting on GPIOs
>> controlled by two independant chips, say one being an ICH10R chipset
>> on a PCI device function, and the other being a
>> SuperIO on an LPC bus.
>>
>> This situation make me really dubious that FreeBSD will be able to
>> support configuration such as:
>>
>> esdhc@50004000 { /* ESDHC1 */
>> cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */
>> wp-gpios = <&gpio3 11 0>; /* GPIO4_11 */
>> status = "okay";
>> };
>>
>> or:
>>
>> ecspi@50010000 { /* ECSPI1 */
>> fsl,spi-num-chipselects = <2>;
>> cs-gpios = <&gpio1 30 0>, /* GPIO2_30 */
>> <&gpio2 19 0>; /* GPIO3_19 */
>> status = "okay";
>> [...]
>>
>> This example is taken from Linux' `arch/arm/boot/dts/imx53-smd.dts'.
>> Here, SDHC or SPI controller are using different GPIO devices. Note
>> that these GPIO pins does not seem to be multi-function pins as
>> another .dts defines ESDHC1 as:
>>
>> esdhc@50004000 { /* ESDHC1 */
>> cd-gpios = <&gpio2 13 0>; /* GPIO3_13 */
>> wp-gpios = <&gpio2 14 0>; /* GPIO3_14 */
>> status = "okay";
>> };
>>
>> AFAIK, newbus is unable to model any of the above situation without
>> being bypassed one way or another.
>>
>> any hints ?
>
> That's not correct. You don't need a parent-child relationship in newbus to interact with another node in the tree. You can look up the other node by name, and then call functions based on finding that other device.
>
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.
What would be need is an interface where the child need to have a way
to say "resources I need are not complete, tell me when a new device
in devclass Z is attached that I can check if it fills my need", ala:
- dev0 is probed
- dev0 tells it is present, but need unavailable resource in devclass
X and devclass Y
- dev0 is marked as pending
- dev1 is attached in devclass X
- dev0 is asked if dev1 would suit it
- dev0 answers negatively
- dev2 is attached in devclass X
- dev0 is asked if dev2 would suit it
- dev0 answers positively
- dev0 continues its probe, but still need unavailable resource in devclass Y
- dev3 is attached in devclass Y
- dev0 is asked if dev3 would suit it
- dev0 answers positively
- dev0 finishes its probe
- dev0 is attached
[...]
- dev3 is to be detached
- dev0 is detached
- dev3 is detached
- Arnaud
[0]: for many reason; hardware failure, configuration change (think
GPIO on multi-function pin)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MWTKSpVRbJracCjSLVHko8RSpXw6vpC3o3UaAyTizos3A>