Re: [RFC] device probe order

[Alexander Aring <alex.aring@gmail.com>]

On Thu, Dec 24, 2015 at 01:46:53PM +0300, Peter Mamonov wrote:
> On Wed, 23 Dec 2015 20:46:02 +0100
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
> 
> > Hi Peter,
> > 
> > On Wed, Dec 23, 2015 at 07:10:58PM +0300, Peter Mamonov wrote:
> > > Dear All,
> > > 
> > > I've ported an UHCI driver from the u-boot to the barebox (WIP). To
> > > interoperate with the EHCI driver, the UHCI driver should be probed
> > > ater the EHCI driver. Both drivers are binded via the device tree
> > > mechanism. How can i achieve the correct probe order?
> > 
> > Do you have an example binding to look at? Normally I would assume
> > that the binding makes sure somehow that the uhci driver has to be
> > probed.
> 
> 
> At the moment the binding is quite straightforward:
> 
> 		ehci: ehci@1ba00200 {
> 			compatible = "generic-ehci";
> 			reg = <0x00000000 0x20 0x00000000 0x100>;
> 			status = "disabled";
> 		};
> 
> 		uhci: uhci@1ba00000 {
> 			compatible = "generic-uhci";
> 			reg = <0x00000000 0x200>;
> 			status = "disabled";
> 		};
> 
> Probably, we can add "companion = <&ehci>;" into the uhci node and
> check if the ehci has been probed by calling of_find_device_by_node(),
> as  Alexander Aring proposed.
> 

I mentioned the -EPROBE_DEFER because we do the same way at handling rpi
power domains, which requires the firmware module at first. See [0].

There we use:

fw_np = of_parse_phandle(pdev->dev.of_node, "firmware", 0);

in you case it would be:

ehci_np = of_parse_phandle(pdev->dev.of_node, "companion", 0);
where "pdev->dev.of_node" is uhci device node.

If this fails then we return -ENODEV, but you better don't do nothing
then because "companion" is optional then.

Back to Linux solution at [0]:

After that function "rpi_firmware_get" tries to get some driver data and
this driver data is available only when the firmware is successful probed.
Means: return -EPROBE_DEFER when function "rpi_firmware_get" returns
NULL, otherwise you can be sure that ehci is probed.

Note:
This is the linux way and I don't know if this works under barebox. :-)
Maybe there exists a better way, what Sascha said, that the device-tree
will do low-level handling of -EPROBE_DEFER somehow. I know that some
subsystems e.g. power domains will do that somehow in special
power-domain device-tree handling and magic handle the device probing in
the correct order (but at the end it's really some handling with
-EPROBE_DEFER).

- Alex

[0] https://github.com/anholt/linux/blob/b936d16077b18a575c5b892c8fe21a6ca67fc31a/arch/arm/mach-bcm/raspberrypi-power.c#L175
[1] https://github.com/anholt/linux/blob/rpi-4.2.y/drivers/firmware/raspberrypi.c#L251

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox