linux-kernel - Re: [PATCH 2/2] ARM: dts: NSP: avoid unnecessary probe deferrals

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] [day] [month] [year] [list]

Message-ID: <b8ef1b3d154e104d943d22dcb07bff2756a82315.camel@alliedtelesis.co.nz>
Date:   Mon, 28 Oct 2019 21:44:24 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     "sbranden@...adcom.com" <sbranden@...adcom.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "bcm-kernel-feedback-list@...adcom.com" 
        <bcm-kernel-feedback-list@...adcom.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "rjui@...adcom.com" <rjui@...adcom.com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>
CC:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 2/2] ARM: dts: NSP: avoid unnecessary probe deferrals

On Tue, 2019-10-29 at 09:21 +1300, Chris Packham wrote:
> On Fri, 2019-10-25 at 10:26 -0700, Florian Fainelli wrote:
> > On 10/24/19 9:00 PM, Chris Packham wrote:
> > > The pinctrl node is used by the gpioa node. Which may have more
> > > descendants at a board level. If the pinctrl node isn't probed first the
> > > gpio is deferred and anything that needs a gpio pin on that chip is also
> > > deferred.
> > 
> > If what you care is to optimize your boot flow such that no re-probing
> > occurs, maybe another solution to look at is to re-order the order in
> > which subsystems are initialized or built (_initcall changes or
> > drivers/Makefile changes), because changing Device Tree certainly does
> > not scale over platforms and I recall Rob indicating that he wanted to
> > introduce randomized platform_device creation from
> > of_platform_bus_populate() at one point or another.
> > 
> 
> Hmm. I might be missing something. pinctrl-nsp-gpio.c uses
> arch_initcall_sync() and pinctrl-nsp-mux.c uses arch_initcall() so in
> theory they are already in the right order.
> 

Actually the init calls are made in the required order w.r.t each
other. But they are both before of_platform_populate, so it's back to
the device tree being the determining factor for when the probe()
functions are run.

With the current kernel I get

nsp_pinmux_init:
nsp_gpio_init:
OF: of_platform_populate:
OF: of_platform_bus_create: /axi@...00000/gpio@20
nsp_gpio_probe:
gpiochip_add_data_with_key: GPIOs 480..511 (18000020.gpio) failed to
register, -517
nsp-gpio-a 18000020.gpio: unable to add GPIO chip
OF: of_platform_bus_create: /axi@...00000/pinctrl@...c0
nsp_pinmux_probe:
... much later ...
nsp_gpio_probe:

Would it be acceptable to change the init calls to device_initcall()
and device_initcall_sync()? pinctrl-nsp-mux.c could even be converted
to (builtin_)platform_driver.

> > > 
> > > Normally we and nodes in the device tree to be listed in their natural
> > > memory mapped address order but putting the pinctrl node first avoids
> > > the deferral of numerous devices so make an exception in this case.
> > 
> > That is a workaround more than a real solution, though I understand why
> > you would to do that. One downside is that the entries are no longer in
> > incrementing register address order and that is visually disturbing and
> > who knows, maybe a drive by contributor whose pet project will be to
> > order the Device Tree entries by incrementing addresses will change that
> > in the future...
> > 
> 
> I guess really what's needed is something that understands phandles and
> tries to produce a dependency tree based on that.
> 
> > > 
> > > Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
> > > ---
> > >  arch/arm/boot/dts/bcm-nsp.dtsi | 14 +++++++-------
> > >  1 file changed, 7 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
> > > index da6d70f09ef1..dd7a65743c08 100644
> > > --- a/arch/arm/boot/dts/bcm-nsp.dtsi
> > > +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
> > > @@ -172,6 +172,13 @@
> > >  		#address-cells = <1>;
> > >  		#size-cells = <1>;
> > >  
> > > +		pinctrl: pinctrl@...c0 {
> > > +			compatible = "brcm,nsp-pinmux";
> > > +			reg = <0x3f1c0 0x04>,
> > > +			      <0x30028 0x04>,
> > > +			      <0x3f408 0x04>;
> > > +		};
> > > +
> > >  		gpioa: gpio@20 {
> > >  			compatible = "brcm,nsp-gpio-a";
> > >  			reg = <0x0020 0x70>,
> > > @@ -458,13 +465,6 @@
> > >  					     "sata2";
> > >  		};
> > >  
> > > -		pinctrl: pinctrl@...c0 {
> > > -			compatible = "brcm,nsp-pinmux";
> > > -			reg = <0x3f1c0 0x04>,
> > > -			      <0x30028 0x04>,
> > > -			      <0x3f408 0x04>;
> > > -		};
> > > -
> > >  		thermal: thermal@...c0 {
> > >  			compatible = "brcm,ns-thermal";
> > >  			reg = <0x3f2c0 0x10>;
> > > 
> > 
> >