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 for Android: free password hash cracker in your pocket

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

Message-ID: <5d75b0ba-81c6-3d54-5bef-1127cd1c9998@gmail.com>
Date:   Fri, 25 Oct 2019 10:26:04 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Chris Packham <chris.packham@...iedtelesis.co.nz>,
        robh+dt@...nel.org, mark.rutland@....com, rjui@...adcom.com,
        sbranden@...adcom.com, bcm-kernel-feedback-list@...adcom.com,
        linus.walleij@...aro.org
Cc:     devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ARM: dts: NSP: avoid unnecessary probe deferrals

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.

> 
> 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...

> 
> 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>;
> 


-- 
Florian