linux-kernel - Re: [PATCH 02/11] ARM: at91: Simplify with scoped for each OF child loop

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: <20260106100429.00001852@huawei.com>
Date: Tue, 6 Jan 2026 10:04:29 +0000
From: Jonathan Cameron <jonathan.cameron@...wei.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@....qualcomm.com>
CC: Miguel Ojeda <ojeda@...nel.org>, Rob Herring <robh@...nel.org>, "Saravana
 Kannan" <saravanak@...gle.com>, Nathan Chancellor <nathan@...nel.org>, "Nick
 Desaulniers" <nick.desaulniers+lkml@...il.com>, Bill Wendling
	<morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>, Russell King
	<linux@...linux.org.uk>, Nicolas Ferre <nicolas.ferre@...rochip.com>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>, Claudiu Beznea
	<claudiu.beznea@...on.dev>, Krzysztof Kozlowski <krzk@...nel.org>, "Alim
 Akhtar" <alim.akhtar@...sung.com>, Madhavan Srinivasan <maddy@...ux.ibm.com>,
	Michael Ellerman <mpe@...erman.id.au>, "Nicholas Piggin" <npiggin@...il.com>,
	"Christophe Leroy (CS GROUP)" <chleroy@...nel.org>, Nipun Gupta
	<nipun.gupta@....com>, Nikhil Agarwal <nikhil.agarwal@....com>, Abel Vesa
	<abelvesa@...nel.org>, Peng Fan <peng.fan@....com>, Michael Turquette
	<mturquette@...libre.com>, "Stephen Boyd" <sboyd@...nel.org>, Shawn Guo
	<shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix
 Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>,
	Vinod Koul <vkoul@...nel.org>, Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Mauro Carvalho Chehab <mchehab@...nel.org>, "Rafael J. Wysocki"
	<rafael@...nel.org>, Viresh Kumar <viresh.kumar@...aro.org>,
	<linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<llvm@...ts.linux.dev>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-samsung-soc@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>,
	<linux-clk@...r.kernel.org>, <imx@...ts.linux.dev>,
	<dmaengine@...r.kernel.org>, <linux-media@...r.kernel.org>,
	<linux-pm@...r.kernel.org>
Subject: Re: [PATCH 02/11] ARM: at91: Simplify with scoped for each OF child
 loop

On Mon, 05 Jan 2026 14:33:40 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@....qualcomm.com> wrote:

> Use scoped for-each loop when iterating over device nodes to make code a
> bit simpler.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@....qualcomm.com>
Interesting bit of code. I guess there is some history here that didn't
get captured as a comment?

> 
> ---
> 
> Depends on the first patch.
> ---
>  arch/arm/mach-at91/pm.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
> index 35058b99069c..68bb4a86cd94 100644
> --- a/arch/arm/mach-at91/pm.c
> +++ b/arch/arm/mach-at91/pm.c
> @@ -982,15 +982,12 @@ static void __init at91_pm_sram_init(void)
>  	struct gen_pool *sram_pool;
>  	phys_addr_t sram_pbase;
>  	unsigned long sram_base;
> -	struct device_node *node;
>  	struct platform_device *pdev = NULL;
>  
> -	for_each_compatible_node(node, NULL, "mmio-sram") {
> +	for_each_compatible_node_scoped(node, NULL, "mmio-sram") {
>  		pdev = of_find_device_by_node(node);
> -		if (pdev) {
> -			of_node_put(node);
> +		if (pdev)
>  			break;
> -
		}
I'm curious if there are DT out there that ever causes the code to get to 
here?  There might be multiple mmio-sram nodes but if there were seems unlikely
the driver wants which ever one has a pdev at a given point in time.
That feels like a weird race condition. So in practice I'd expect this to
always either get the first one, or none.
e.g. Why this can't just be

node = of_find_node_by_name("mmio-sram);
if (node) {
	pdev = of_find_device_by_node(node);
}

or something along those lines.

Given risk of a regression maybe better to do what you have here.
So with that in mind
Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>

>  	}
>  
>  	if (!pdev) {
>