linux-kernel - Re: [PATCH] dmaengine: at_xdmac: use module_platform

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YQEUFADKhGtzz++g@matsya>
Date:   Wed, 28 Jul 2021 13:53:48 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     Clément Léger <clement.leger@...tlin.com>
Cc:     Ludovic Desroches <ludovic.desroches@...rochip.com>,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        linux-arm-kernel@...ts.infradead.org, dmaengine@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dmaengine: at_xdmac: use module_platform_driver

On 28-07-21, 09:38, Clément Léger wrote:
> Le Wed, 28 Jul 2021 12:26:50 +0530,
> Vinod Koul <vkoul@...nel.org> a écrit :
> 
> > On 25-06-21, 11:00, Clément Léger wrote:
> > > 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@...tlin.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

> 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

> 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

-- 
~Vinod