[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eda5b1da03d4adfa5761c49527a9232ec7facae3.camel@codeconstruct.com.au>
Date: Thu, 02 May 2024 10:23:58 +0930
From: Andrew Jeffery <andrew@...econstruct.com.au>
To: "Peng Fan (OSS)" <peng.fan@....nxp.com>, Linus Walleij
<linus.walleij@...aro.org>, Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>, Dvorkin Dmitry <dvorkin@...bo.com>,
Wells Lu <wellslutw@...il.com>, Maxime Coquelin
<mcoquelin.stm32@...il.com>, Alexandre Torgue
<alexandre.torgue@...s.st.com>, Emil Renner Berthing <kernel@...il.dk>,
Jianlong Huang <jianlong.huang@...rfivetech.com>, Hal Feng
<hal.feng@...rfivetech.com>, Orson Zhai <orsonzhai@...il.com>, Baolin Wang
<baolin.wang@...ux.alibaba.com>, Chunyan Zhang <zhang.lyra@...il.com>,
Viresh Kumar <vireshk@...nel.org>, Shiraz Hashim
<shiraz.linux.kernel@...il.com>, soc@...nel.org, Krzysztof Kozlowski
<krzk@...nel.org>, Sylwester Nawrocki <s.nawrocki@...sung.com>, Alim Akhtar
<alim.akhtar@...sung.com>, Geert Uytterhoeven <geert+renesas@...der.be>,
Patrice Chotard <patrice.chotard@...s.st.com>, Heiko Stuebner
<heiko@...ech.de>, Damien Le Moal <dlemoal@...nel.org>, Ludovic Desroches
<ludovic.desroches@...rochip.com>, Nicolas Ferre
<nicolas.ferre@...rochip.com>, Alexandre Belloni
<alexandre.belloni@...tlin.com>, Claudiu Beznea <claudiu.beznea@...on.dev>,
Dong Aisheng <aisheng.dong@....com>, Fabio Estevam <festevam@...il.com>,
Shawn Guo <shawnguo@...nel.org>, Jacky Bai <ping.bai@....com>, Pengutronix
Kernel Team <kernel@...gutronix.de>, Chester Lin <chester62515@...il.com>,
Matthias Brugger <mbrugger@...e.com>, Ghennadi Procopciuc
<ghennadi.procopciuc@....nxp.com>, Sean Wang <sean.wang@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>, Sascha Hauer
<s.hauer@...gutronix.de>, Joel Stanley <joel@....id.au>, Dan Carpenter
<dan.carpenter@...aro.org>
Cc: linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-tegra@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-stm32@...md-mailman.stormreply.com,
linux-samsung-soc@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-rockchip@...ts.infradead.org, linux-riscv@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, imx@...ts.linux.dev,
linux-aspeed@...ts.ozlabs.org, openbmc@...ts.ozlabs.org, Peng Fan
<peng.fan@....com>
Subject: Re: [PATCH 20/21] pinctrl: aspeed: g5: Use scope based
of_node_put() cleanups
On Wed, 2024-05-01 at 20:56 +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@....com>
>
> Use scope based of_node_put() cleanup to simplify code.
>
> Signed-off-by: Peng Fan <peng.fan@....com>
> ---
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> index 5bb8fd0d1e41..61fbfddb5938 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> @@ -2629,14 +2629,13 @@ static struct regmap *aspeed_g5_acquire_regmap(struct aspeed_pinmux_data *ctx,
> return ctx->maps[ip];
>
> if (ip == ASPEED_IP_GFX) {
> - struct device_node *node;
> + struct device_node *node __free(device_node) = NULL;
> struct regmap *map;
>
> node = of_parse_phandle(ctx->dev->of_node,
> "aspeed,external-nodes", 0);
> if (node) {
> map = syscon_node_to_regmap(node);
> - of_node_put(node);
> if (IS_ERR(map))
> return map;
> } else
> @@ -2648,7 +2647,7 @@ static struct regmap *aspeed_g5_acquire_regmap(struct aspeed_pinmux_data *ctx,
> }
>
> if (ip == ASPEED_IP_LPC) {
> - struct device_node *np;
> + struct device_node *np __free(device_node) = NULL;
> struct regmap *map;
>
> np = of_parse_phandle(ctx->dev->of_node,
> @@ -2660,7 +2659,6 @@ static struct regmap *aspeed_g5_acquire_regmap(struct aspeed_pinmux_data *ctx,
> return ERR_PTR(-ENODEV);
>
> map = syscon_node_to_regmap(np->parent);
> - of_node_put(np);
> if (IS_ERR(map))
> return map;
I think I agree with Krzysztof's feedback on the Samsung patch[1], and
that I prefer the existing approach for the Aspeed driver. My reasoning
suggests the existing implementation does the right thing. That said,
the code could be adjusted to use early returns and consistent variable
names, which might make it easier to reason about. I'll consider a
follow-up patch to address that.
Regardless, thanks for taking the time to explore the cleanup.
Andrew
[1]: https://lore.kernel.org/lkml/34193501-5b7b-4ffd-8549-a04c6930d02d@kernel.org/
> } else
>
Powered by blists - more mailing lists