linux-kernel - RE: [PATCH] clk: renesas: r9a06g032: Avoid needless probe deferring

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: <TY1PR01MB176963BDA18D948161AAD264F5510@TY1PR01MB1769.jpnprd01.prod.outlook.com>
Date:   Fri, 20 Jul 2018 13:57:22 +0000
From:   Phil Edworthy <phil.edworthy@...esas.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
CC:     Simon Horman <horms@...ge.net.au>,
        linux-clk <linux-clk@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>
Subject: RE: [PATCH] clk: renesas: r9a06g032: Avoid needless probe deferring

Hi Geert,

On 20 July 2018 13:41, Geert Uytterhoeven wrote:
> On Fri, Jul 20, 2018 at 2:26 PM Phil Edworthy wrote:
> > On 20 July 2018 13:12, Geert Uytterhoeven wrote:
> > > On Fri, Jul 20, 2018 at 2:06 PM Phil Edworthy  wrote:
> > > > On 20 July 2018 12:21, Geert Uytterhoeven wrote:
> > > > > On Wed, Jul 18, 2018 at 4:34 PM Phil Edworthy wrote:
> > > > > > To avoid all SoC peripheral drivers deferring their probes,
> > > > > > both clock and pinctrl drivers should already be probed. Since
> > > > > > the pinctrl driver requires a clock to access the registers,
> > > > > > the clock driver should be probed before the pinctrl driver.
> > > > > >
> > > > > > Therefore, move the clock driver from subsys_initcall to
> core_initcall.
> > > > > >
> > > > > > Signed-off-by: Phil Edworthy <phil.edworthy@...esas.com>
> > > > >
> > > > > Thanks for your patch!
> > > > Thanks for your review!
> > > >
> > > > > The (not yet upstreamed) pinctrl driver uses postcore_initcall(), right?
> > > > No, the pinctrl driver uses subsys_initcall, but postcore_initcall
> > > > or arch_initcall may be better to make it clear about the dependencies.
> > >
> > > if the pinctrl driver uses subsys_initcall(), ...
> 
> > > > > > -subsys_initcall(r9a06g032_clocks_init);
> > > > > > +core_initcall(r9a06g032_clocks_init);
> > >
> > > ... using postcore_initcall() or arch_initcall() here, should work
> > > with platform_driver_probe()?
> > Nope, you have to use platform_driver_register() for DT based drivers.
> > subsys_initcall is the earliest you can use platform_driver_probe().
> 
> So drivers/misc/atmel_tclib.c and drivers/pinctrl/pinctrl-coh901.c, which use
> arch_initcall(), cannot work?
How those drivers work I do not know. However, I tried with the rzn1 clock
driver and it does not work.

> If that is really true, you can still use subsys_initcall() in the clock driver, and
> subsys_initcall_sync() in the pinctrl driver.
True, I'm not sure how people decide which initcall to use and whether the
_sync variants of the initcalls have a special meaning or intention. As far as
I know they were introduced for threaded probes, so are we supposed to
use them for driver dependencies like this?

Do you know why the rza1 pinctrl driver is running from core_initcall()?

Thanks
Phil