[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240704233155.61b5323c@booty>
Date: Thu, 4 Jul 2024 23:31:55 +0200
From: Luca Ceresoli <luca.ceresoli@...tlin.com>
To: Rob Herring <robh@...nel.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, Saravana Kannan <saravanak@...gle.com>,
Nathan Chancellor <nathan@...nel.org>, Michael Turquette
<mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, Tony Lindgren
<tony@...mide.com>, Bjorn Andersson <andersson@...nel.org>, Emilio
López <emilio@...pez.com.ar>, Chen-Yu Tsai
<wens@...e.org>, Jernej Skrabec <jernej.skrabec@...il.com>, Samuel Holland
<samuel@...lland.org>, Krzysztof Kozlowski <krzk@...nel.org>, Daniel
Lezcano <daniel.lezcano@...aro.org>, Thomas Gleixner <tglx@...utronix.de>,
Florian Fainelli <florian.fainelli@...adcom.com>, Broadcom internal kernel
review list <bcm-kernel-feedback-list@...adcom.com>, Linus Walleij
<linus.walleij@...aro.org>, Bartosz Golaszewski <brgl@...ev.pl>, Jonathan
Cameron <jic23@...nel.org>, Lee Jones <lee@...nel.org>, Shawn Guo
<shawnguo@...nel.org>, Pengutronix Kernel Team <kernel@...gutronix.de>, Uwe
Kleine-König <ukleinek@...nel.org>, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>, Richard
Leitner <richard.leitner@...ux.dev>, Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>, Nicolas Ferre
<nicolas.ferre@...rochip.com>, Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>, Christophe Leroy
<christophe.leroy@...roup.eu>, "Naveen N. Rao"
<naveen.n.rao@...ux.ibm.com>, Damien Le Moal <dlemoal@...nel.org>, "Peng
Fan (OSS)" <peng.fan@....nxp.com>, Thomas Petazzoni
<thomas.petazzoni@...tlin.com>, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, llvm@...ts.linux.dev,
linux-clk@...r.kernel.org, linux-omap@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-sunxi@...ts.linux.dev, linux-samsung-soc@...r.kernel.org,
linux-gpio@...r.kernel.org, linux-iio@...r.kernel.org,
linux-pwm@...r.kernel.org, linux-serial@...r.kernel.org,
linux-usb@...r.kernel.org, patches@...nsource.cirrus.com,
linux-sound@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-riscv@...ts.infradead.org
Subject: Re: [PATCH 00/20] Simplify of_property_for_each_u32()
Hello Rob,
On Wed, 3 Jul 2024 12:07:42 -0600
Rob Herring <robh@...nel.org> wrote:
> On Wed, Jul 03, 2024 at 12:36:44PM +0200, Luca Ceresoli wrote:
> > [Note: to reduce the noise I have trimmed the get_maintainers list
> > manually. Should you want to be removed, or someone else added, to future
> > versions, just tell me. Sorry for the noise.]
> >
> > This series aims at simplifying of_property_for_each_u32() as well as
> > making it more difficult to misuse it in the future.
> >
> > The long-term goal is changing this pattern:
> >
> > struct property *prop;
> > const __be32 *p;
> > u32 val;
> >
> > of_property_for_each_u32(np, "xyz", prop, p, val) { ... }
> >
> > to this:
> >
> > u32 val;
> >
> > of_property_for_each_u32(np, "xyz", val) { ... }
> >
> > So, removing the 3rd and 4th arguments which are typically meant to be
> > internal. Those two parameters used to be unavoidable until the kernel
> > moved to building with the C11 standard unconditionally. Since then, it is
> > now possible to get rid of them. However a few users of
> > of_property_for_each_u32() do actually use those arguments, which
> > complicates the transition. For this reason this series does the following:
> >
> > * Add of_property_for_each_u32_new(), which does not have those two
> > arguments (patch 1)
> > * Convert _almost_ every usage to of_property_for_each_u32_new()
> > * Rename of_property_for_each_u32() to of_property_for_each_u32_old() and
> > deprecate it, as a incentive to code not (yet) in mainline to upgrade
> > to the *_new() version (last patch)
>
> I don't really see the point of introducing the _old variant. Let's get
> this done in one step.
>
> >
> > The plan for the next series is to additionally:
> >
> > * Convert the few remaining of_property_for_each_u32_old() instantes to
> > of_property_for_each_u32_new()
> > * Remove of_property_for_each_u32_old()
> > * Rename of_property_for_each_u32_new() to of_property_for_each_u32()
>
> Honestly, I think there's few enough users we could just convert the
> whole thing in one patch. It's all got to go thru 1 tree anyways. If
> there's new cases in -next, then I'd be happy to send it to Linus at the
> end of the merge window.
Sure, make sense. I'll need to convert the few remaining users, then
I'm sending a squashed v2.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Powered by blists - more mailing lists