Re: [RESEND PATCH v2 0/4] of: automate of_node_put() - new approach to loops.

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Tue, 12 Mar 2024 12:10:46 -0600
Rob Herring <robh@kernel.org> wrote:

> On Sat, Mar 9, 2024 at 10:33 AM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Sun, 3 Mar 2024 11:56:33 +0000
> > Jonathan Cameron <jic23@kernel.org> wrote:
> >  
> > > On Fri, 1 Mar 2024 16:39:42 -0600
> > > Rob Herring <robh@kernel.org> wrote:
> > >  
> > > > On Sun, Feb 25, 2024 at 02:27:10PM +0000, Jonathan Cameron wrote:  
> > > > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > > >
> > > > > Some discussion occured on previous posting.
> > > > > https://lore.kernel.org/linux-iio/20240223124432.26443-1-Jonathan.Cameron@huawei.com/
> > > > >
> > > > > Summary:
> > > > > * fwnode conversions should be considered when applying this
> > > > >   infrastructure to a driver. Perhaps better to move directly to
> > > > >   the generic FW property handling rather than improve existing
> > > > >   of specific code.
> > > > > * There are lots of potential places to use this based on detections
> > > > >   from Julia's coccinelle scripts linked below.
> > > > >
> > > > > The equivalent device_for_each_child_node_scoped() series for
> > > > > fwnode will be queued up in IIO for the merge window shortly as
> > > > > it has gathered sufficient tags. Hopefully the precdent set there
> > > > > for the approach will reassure people that instantiating the
> > > > > child variable inside the macro definition is the best approach.
> > > > > https://lore.kernel.org/linux-iio/20240217164249.921878-1-jic23@kernel.org/
> > > > >
> > > > > v2: Andy suggested most of the original converted set should move to
> > > > >     generic fwnode / property.h handling.  Within IIO that was
> > > > >     a reasonable observation given we've been trying to move away from
> > > > >     firmware specific handling for some time. Patches making that change
> > > > >     to appropriate drivers posted.
> > > > >     As we discussed there are cases which are not suitable for such
> > > > >     conversion and this infrastructure still provides clear benefits
> > > > >     for them.
> > > > >
> > > > > Ideally it would be good if this introductory series adding the
> > > > > infrastructure makes the 6.9 merge window. There are no dependencies
> > > > > on work queued in the IIO tree, so this can go via devicetree
> > > > > if the maintainers would prefer. I've had some off list messages
> > > > > asking when this would be merged, as there is interest in building
> > > > > on it next cycle for other parts of the kernel (where conversion to
> > > > > fwnode handling may be less appropriate).  
> > > >
> > > > I'll let you take it. For the series:
> > > >
> > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > >
> > > > I've got some drivers/of/ conversions too, but they are probably next
> > > > cycle at this point.
> > > >
> > > > Rob  
> > >
> > > Thanks Rob,
> > >
> > > Whether this makes it for this cycle is probably dependent on whether
> > > Linus does decide to do got to rc8 as hinted at as a possibility
> > > + whether Greg feels comfortable taking these through his tree
> > > (char-misc is the normal path for IIO).  I know various people
> > > are hoping this series makes it, but if doesn't we can do an immutable
> > > tree early next cycle (though obviously that may reduce speed of adoption).
> > >
> > > We are discussing the equivalent pull request for the fwnode version here:
> > >
> > > https://lore.kernel.org/linux-iio/2024030239-gift-cabdriver-266b@gregkh/T/#m87e7208820ebf6416a77a2973773b65a087b4796
> > >
> > > I've optimistically applied this series to my togreg-cleanup branch
> > > and merged that into the togreg branch of iio.git for linux-next to pick up.
> > >  
> >
> > Greg, would you consider a last minute pull request for these, or picking them up
> > directly?  It would be helpful for Rob's follow ups and the work Julia is doing
> > with coccinelle and automating of locating cases to apply this approach.
> >
> > If the device_for_each_child_node_scoped() series is fine this is almostly
> > exactly the same thing for the device tree specific case. Not sure what your
> > plans are for that pull request so I might be jumping the gun.
> >
> > If not (and assuming the generic property version does make it in) I'll do
> > an immutable branch based on rc1 so that others can build on this via that.
> > Fiddlier solution for everyone but given how late we are, perhaps the wiser
> > one.  
> 
> I'm happy to pick up the first 3 patches for 6.9 if you want.

Thanks Rob, that would be great.

Jonathan

> 
> Rob
>