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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Mar 9, 2024 at 10:33 AM Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>
> On Sun, 3 Mar 2024 11:56:33 +0000
> Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>
> > On Fri, 1 Mar 2024 16:39:42 -0600
> > Rob Herring <robh@xxxxxxxxxx> wrote:
> >
> > > On Sun, Feb 25, 2024 at 02:27:10PM +0000, Jonathan Cameron wrote:
> > > > From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
> > > >
> > > > Some discussion occured on previous posting.
> > > > https://lore.kernel.org/linux-iio/20240223124432.26443-1-Jonathan.Cameron@xxxxxxxxxx/
> > > >
> > > > 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@xxxxxxxxxx/
> > > >
> > > > 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@xxxxxxxxxx>
> > >
> > > 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.

Rob





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux