Le Wed, 28 Jul 2021 13:53:48 +0530,
Vinod Koul [off-list ref] a écrit :

On 28-07-21, 09:38, Clément Léger wrote:

quoted

Le Wed, 28 Jul 2021 12:26:50 +0530,
Vinod Koul [off-list ref] a écrit :
  

quoted

On 25-06-21, 11:00, Clément Léger wrote:  

quoted

The driver was previously probed with platform_driver_probe.
This does not allow the driver to be probed again later if
probe function returns -EPROBE_DEFER. This patch replace the
use of platform_driver_probe with module_platform_driver which
allows that.

Signed-off-by: Clément Léger <clement.leger@bootlin.com>
---
 drivers/dma/at_xdmac.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index 64a52bf4d737..109a4c0895f4 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c

@@ -2238,11 +2238,7 @@ static struct platform_driver

at_xdmac_driver = { }
 };
 
-static int __init at_xdmac_init(void)
-{
-	return platform_driver_probe(&at_xdmac_driver,
at_xdmac_probe); -}
-subsys_initcall(at_xdmac_init);
+module_platform_driver(at_xdmac_driver);    

You are also changing the init call here, there is a reason why
dmaengine drivers are subsys_initcall.. have you tested this?
  

I understood that the subsys initcall was there to probe the DMA
driver earlier than other drivers (at least I guess this was the
reason). I  

That is correct

quoted

also tested it and can confirm you this works as expected on my
platform (sama5d2_xplained and sama5d27_som1).

In my configuration, the clocks are provided using SCMI and the SCMI
driver probes them later than other drivers.   

Heh, clocks should get probed even earlier

Yes, even clocksources might need them... But that's another story.

quoted

With the current subsys_initcall, platform_driver_probe calls
__platform_driver_probe which will eventually calls platform_probe.
This one will fails because SCMI clocks are not available at this
time. And as said in the kernel doc, __platform_driver_probe is
incompatible with deferred probing. This leads to failure of all
drivers that needs DMA channels provbided by at_xdmac.

With module_platform_driver, the at_xdmac driver is correctly probed
again later and all drivers that depends on DMA channels provided by
this one are also correctly probed. The deferred probing mechanism
seems to do its job correctly (at least in my case).  

OK would then recommend making it like module_platform_driver ie
remove platform_driver_probe, so the defer probe would work, but keep
the init at subsys level. That should work for you while keeping this
sane for folks that dont need this

Ok, I'll modify it this way, thanks.



-- 
Clément Léger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel