Hello Rob,
On Wed, 3 Jul 2024 12:07:42 -0600
Rob Herring <robh@xxxxxxxxxx> 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
