device probe order

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?

Quoted 7 lines · Peter Mamonov

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?

Normally this should done by returning "-EPROBE_DEFER" inside the probe function. There was some RFC last years for supporting EPROBE_DEFER [0] and it seems these are mainline.

However you need some bool which indicates that the EHCI driver is probed.

int uhci_probe(foobar) {

if (!indicate_ehci_is_probed(foobar)

	return -EPROBE_DEFER;
}

- Alex

[0]
http://barebox.infradead.narkive.com/ZWIXXU0R/patch-v2-0-6-introduce-deferred-probing

Quoted 13 lines · On Wed, 23 Dec 2015 17:35:51 +0100 Alexander Aring <[email protected]> wrote:

Quoted 7 lines · Peter Mamonov

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?

Normally this should done by returning "-EPROBE_DEFER" inside the probe function. There was some RFC last years for supporting EPROBE_DEFER [0] and it seems these are mainline.

Quoted 2 lines

However you need some bool which indicates that the EHCI driver is probed.

Thanks, Alex. As i understand, this is the linux-way solution.

Sasha, is it ok to add a global variable to indicate the EHCI presence? Or should we follow the way proposed by the mentioned RFCs, i.e. introduce dependencies between drivers?

Quoted 17 lines · Peter Mamonov

Quoted 14 lines · On Wed, 23 Dec 2015 17:35:51 +0100 Alexander Aring <[email protected]> wrote:

Quoted 8 lines · Peter Mamonov

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?

Normally this should done by returning "-EPROBE_DEFER" inside the probe function. There was some RFC last years for supporting EPROBE_DEFER [0] and it seems these are mainline.

Quoted 9 lines

Quoted 2 lines

However you need some bool which indicates that the EHCI driver is probed.

Thanks, Alex. As i understand, this is the linux-way solution.

Sasha, is it ok to add a global variable to indicate the EHCI presence? Or should we follow the way proposed by the mentioned RFCs, i.e. introduce dependencies between drivers?

mhhh, maybe a simple "get_device_by_name" works here.

If returning NULL then return -EPROBE_DEFER. Don't know if this is a good solution, name need to be unique then.

btw:
Just found that "of_find_device_by_node" returns -EPROBE_DEFER when nothing was found. This was introduced by the patch series.

Maybe it helps to look how the current use-cases deals with -EPROBE_DEFER or get_device_by_name is enough.

- Alex

Quoted 34 lines · On Wed, 23 Dec 2015 18:04:43 +0100 Alexander Aring <[email protected]> wrote:

Quoted 17 lines · Peter Mamonov

Quoted 14 lines · On Wed, 23 Dec 2015 17:35:51 +0100 Alexander Aring <[email protected]> wrote:

Quoted 8 lines · Peter Mamonov

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?

Normally this should done by returning "-EPROBE_DEFER" inside the probe function. There was some RFC last years for supporting EPROBE_DEFER [0] and it seems these are mainline.

Quoted 9 lines

Quoted 2 lines

However you need some bool which indicates that the EHCI driver is probed.

Thanks, Alex. As i understand, this is the linux-way solution.

Sasha, is it ok to add a global variable to indicate the EHCI presence? Or should we follow the way proposed by the mentioned RFCs, i.e. introduce dependencies between drivers?

mhhh, maybe a simple "get_device_by_name" works here.

If returning NULL then return -EPROBE_DEFER. Don't know if this is a good solution, name need to be unique then.

Quoted 3 lines

btw:
Just found that "of_find_device_by_node" returns -EPROBE_DEFER when nothing was found. This was introduced by the patch series.

I like this approach better, than introducing a global variable. Will look further into it.

Quoted 7 lines

Maybe it helps to look how the current use-cases deals with -EPROBE_DEFER or get_device_by_name is enough.

- Alex

Quoted 41 lines · On Thu, 24 Dec 2015 12:48:37 +0300 Peter Mamonov <[email protected]> wrote:

Quoted 37 lines · On Wed, 23 Dec 2015 18:04:43 +0100 Alexander Aring <[email protected]> wrote:

Quoted 17 lines · Peter Mamonov

Quoted 14 lines · On Wed, 23 Dec 2015 17:35:51 +0100 Alexander Aring <[email protected]> wrote:

Quoted 8 lines · Peter Mamonov

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?

Normally this should done by returning "-EPROBE_DEFER" inside the probe function. There was some RFC last years for supporting EPROBE_DEFER [0] and it seems these are mainline.

Quoted 9 lines

Quoted 2 lines

However you need some bool which indicates that the EHCI driver is probed.

Thanks, Alex. As i understand, this is the linux-way solution.

Sasha, is it ok to add a global variable to indicate the EHCI presence? Or should we follow the way proposed by the mentioned RFCs, i.e. introduce dependencies between drivers?

mhhh, maybe a simple "get_device_by_name" works here.

If returning NULL then return -EPROBE_DEFER. Don't know if this is a good solution, name need to be unique then.

btw:
Just found that "of_find_device_by_node" returns -EPROBE_DEFER when nothing was found. This was introduced by the patch series.

Quoted 2 lines

I like this approach better, than introducing a global variable. Will look further into it.

Unfortunately of_find_device_by_node() returns a valid pointer to the device before the device probe function is called. I guess get_device_by_name() behaves in the same way.

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?

Hi Peter,

Quoted 2 lines · Peter Mamonov

Dear All,

Quoted 4 lines

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.

Sascha

Quoted 5 lines · On Wed, 23 Dec 2015 20:46:02 +0100 Sascha Hauer <[email protected]> wrote:

Hi Peter,

Quoted 2 lines · Peter Mamonov

Dear All,

Quoted 8 lines

Quoted 4 lines

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.

Quoted 33 lines · Peter Mamonov

Quoted 11 lines · On Wed, 23 Dec 2015 20:46:02 +0100 Sascha Hauer <[email protected]> wrote:

Hi Peter,

Quoted 7 lines · Peter Mamonov

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?

Quoted 3 lines

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";
		};

Quoted 4 lines

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

Let me summarize my efforts:

"Global variable" solution works fine, however it is not elegant enough:

drivers/usb/host/ehci-hcd.c +4 -0

index 862444b..d06e001 100644
@@ -138,0 +139,2 @@ static struct descriptor {
+int ehci_probed = 0;
+

@@ -1346,0 +1349,2 @@ static int ehci_probe(struct device_d *dev)
+       ehci_probed = 1;
+

drivers/usb/host/uhci-hcd.c +2 -0

index 5a5314f..c99426c 100644
@@ -81,0 +82,2 @@
+extern int ehci_probed;
+

"Device tree" solution doesn't work, because of_find_device_by_node() returns pointer to the device even though the device probe function wasn't called. The question is: how to tell if the device probe function was called?

drivers/usb/host/uhci-hcd.c +0 -0

index c99426c..44eca36 100644