From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E284217705; Tue, 6 Jan 2026 10:04:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767693887; cv=none; b=MWapmuqcvBVnJLYW2ibPAg1LVdtBnir7KPI7WdMWUsM1TgvulHUsZdhCJYJOrRcaR3yoUoyYk6yFfiHNbeeu0BEZQelCLSg/mE7R8FaV5OajGLUnSdfJRBGmNbZfFASlm1tWRduWN3+oB/RlC9IqcQNG6/VDvnnk6PuidZjxrsY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767693887; c=relaxed/simple; bh=BX5i5r7iYCiq72nQEofPbVD1g+CVJeFayk88C7dR/w0=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IvV4fbMxH7aOwZNcL/0nbVFa7MlgizapzZ7mOEEAZi7Uu4Dvx7PiMcnljuAhl8ZJkeOvlXN6zzhPnNLoXZimcccKHc2CyLPVqI3Jxvl6AnXIlrs0xvKFak9Jm27Kw3gaz4rtdwzaehuMciuiQYT9vPCXo8SrYOd5UWrKzBmhBHI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.224.150]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4dlmwy0YMBzJ470w; Tue, 6 Jan 2026 18:04:34 +0800 (CST) Received: from dubpeml100005.china.huawei.com (unknown [7.214.146.113]) by mail.maildlp.com (Postfix) with ESMTPS id 70AF84056A; Tue, 6 Jan 2026 18:04:35 +0800 (CST) Received: from localhost (10.48.149.114) by dubpeml100005.china.huawei.com (7.214.146.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Tue, 6 Jan 2026 10:04:33 +0000 Date: Tue, 6 Jan 2026 10:04:29 +0000 From: Jonathan Cameron To: Krzysztof Kozlowski CC: Miguel Ojeda , Rob Herring , "Saravana Kannan" , Nathan Chancellor , "Nick Desaulniers" , Bill Wendling , Justin Stitt , Russell King , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , Krzysztof Kozlowski , "Alim Akhtar" , Madhavan Srinivasan , Michael Ellerman , "Nicholas Piggin" , "Christophe Leroy (CS GROUP)" , Nipun Gupta , Nikhil Agarwal , Abel Vesa , Peng Fan , Michael Turquette , "Stephen Boyd" , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Vinod Koul , Sylwester Nawrocki , Mauro Carvalho Chehab , "Rafael J. Wysocki" , Viresh Kumar , , , , , , , , , , , Subject: Re: [PATCH 02/11] ARM: at91: Simplify with scoped for each OF child loop Message-ID: <20260106100429.00001852@huawei.com> In-Reply-To: <20260105-of-for-each-compatible-scoped-v1-2-24e99c177164@oss.qualcomm.com> References: <20260105-of-for-each-compatible-scoped-v1-0-24e99c177164@oss.qualcomm.com> <20260105-of-for-each-compatible-scoped-v1-2-24e99c177164@oss.qualcomm.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: dmaengine@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml100010.china.huawei.com (7.191.174.197) To dubpeml100005.china.huawei.com (7.214.146.113) On Mon, 05 Jan 2026 14:33:40 +0100 Krzysztof Kozlowski wrote: > Use scoped for-each loop when iterating over device nodes to make code a > bit simpler. > > Signed-off-by: Krzysztof Kozlowski 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 > } > > if (!pdev) { >