6 messages, 4 authors, 2012-03-18 · open the first message on its own page
From: Benjamin Herrenschmidt <hidden>
Date: 2012-03-16 21:23:54
On Fri, 2012-03-16 at 16:21 -0500, Kumar Gala wrote:
Guys, Are you aware of any reason that we can't call of_platform_bus_probe() or multiple times. Timur's run into an issue in which all devices don't get registered properly if we call of_platform_bus_probe() times with different of_device_id struct's.
Nothing comes to mind... Grant ? Cheers, Ben.
From: Grant Likely <hidden>
Date: 2012-03-17 07:27:17
On Sat, 17 Mar 2012 08:23:54 +1100, Benjamin Herrenschmidt [off-list ref] wrote:
On Fri, 2012-03-16 at 16:21 -0500, Kumar Gala wrote:quoted
Guys, Are you aware of any reason that we can't call of_platform_bus_probe() or multiple times. Timur's run into an issue in which all devices don't get registered properly if we call of_platform_bus_probe() times with different of_device_id struct's.Nothing comes to mind... Grant ?
Neither for me. Should work. g.
From: Tabi Timur-B04825 <hidden>
Date: 2012-03-17 13:35:02
Grant Likely wrote:
quoted
quoted
quoted
> Are you aware of any reason that we can't call of_platform_bus_probe() > or multiple times. Timur's run into an issue in which all devices > don't get registered properly if we call of_platform_bus_probe() times > with different of_device_id struct's.Nothing comes to mind... Grant ?Neither for me. Should work.
I posted a work-around patch here: http://patchwork.ozlabs.org/patch/128533/ Without this patch, drivers cannot probe on DMA *channels*, or any other grandchildren of the root node. -- Timur Tabi Linux kernel developer at Freescale
From: Grant Likely <hidden>
Date: 2012-03-18 09:08:04
On Sat, 17 Mar 2012 13:35:02 +0000, Tabi Timur-B04825 [off-list ref] wrote:
Grant Likely wrote:quoted
quoted
quoted
quoted
> Are you aware of any reason that we can't call of_platform_bus_probe() > or multiple times. Timur's run into an issue in which all devices > don't get registered properly if we call of_platform_bus_probe() times > with different of_device_id struct's.Nothing comes to mind... Grant ?Neither for me. Should work.I posted a work-around patch here: http://patchwork.ozlabs.org/patch/128533/ Without this patch, drivers cannot probe on DMA *channels*, or any other grandchildren of the root node.
That's because you're using it wrong. of_platform_bus_probe() creates platform devices at the starting level and every level below it as described by the bus ids. It is illegal to call of_platform_bus_probe() twice at the same level in the DT. g.
From: Tabi Timur-B04825 <hidden>
Date: 2012-03-18 16:14:23
Grant Likely wrote:
That's because you're using it wrong. of_platform_bus_probe() creates platform devices at the starting level and every level below it as described by the bus ids. It is illegal to call of_platform_bus_probe() twice at the same level in the DT.
Well, *I* am not using it wrong. Notice that my patch fixes (or works around) the commit that *did* do it wrong: http://patchwork.ozlabs.org/patch/126289/ -- Timur Tabi Linux kernel developer at Freescale
From: Grant Likely <hidden>
Date: 2012-03-18 18:22:07
On Sun, 18 Mar 2012 16:14:23 +0000, Tabi Timur-B04825 [off-list ref] wrote:
Grant Likely wrote:quoted
That's because you're using it wrong. of_platform_bus_probe() creates platform devices at the starting level and every level below it as described by the bus ids. It is illegal to call of_platform_bus_probe() twice at the same level in the DT.Well, *I* am not using it wrong. Notice that my patch fixes (or works around) the commit that *did* do it wrong: http://patchwork.ozlabs.org/patch/126289/
Fair enough; I just wanted to point out that there it can only dig as deep into the tree as is specified by the bus ids. The exact problem wasn't calling the function twice, but rather trying to call the function twice from the same level of the tree. BTW, I also recommend moving to of_platform_populate() for new code. I think the behaviour is more consistent for fdt platforms and it is more convenient for devices that are children of the root. g.