On Tue, 12 Mar 2024 12:10:46 -0600 Rob Herring <robh@xxxxxxxxxx> wrote: > 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. Thanks Rob, that would be great. Jonathan > > Rob >
