Re: [PATCH v4 00/15] device property / IIO: Use cleanup.h magic for fwnode_handle_put() handling.

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

On Sat, 24 Feb 2024 11:49:12 +0000
Jonathan Cameron <jic23@kernel.org> wrote:

> On Mon, 19 Feb 2024 15:49:47 +0000
> Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> 
> > On Mon, 19 Feb 2024 13:49:22 +0200
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> >   
> > > On Sat, Feb 17, 2024 at 04:42:34PM +0000, Jonathan Cameron wrote:    
> > > > From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > > 
> > > > Sorry for the rapid resend, Andy noticed I'd messed up creating the v3 patch
> > > > set with some updates committed in the wrong patch.
> > > > 
> > > > Since v3: The updates to alignment of device_for_each_child_node_scopd() were
> > > >     in the wrong patch. Move them to patch 4 where they should always
> > > >     have been. (thanks Andy!)
> > > > 
> > > > Since v2: Thanks to Sakari and Andy for reviews.
> > > > - New first patch moving fwnode_handle_put() into property.h
> > > > - Tweak alignment in the loop macro
> > > > - Pick up tags.
> > > > - scopd -> scoped typo fix in some patch descriptions.
> > > > 
> > > > As can be seen by the examples from IIO that follow this can save
> > > > a reasonable amount of complexity and boiler plate code, often enabling
> > > > additional cleanups in related code such as use of
> > > > return dev_err_probe().
> > > > 
> > > > Given we are now fairly late in the cycle, I'd expect to take this
> > > > through the IIO tree and we can make use of it elsewhere next cycle.
> > > > 
> > > > Note I don't have the hardware so this is compile tested only.
> > > > Hence I'd appreciate some Tested-by tags if anyone can poke one of the
> > > > effected drivers.
> > > > 
> > > > Julia Lawal has posted some nice coccinelle magic for the DT equivalents.
> > > > Referenced from that cover letter.  Similar may help us convert more
> > > > drivers to use this new approach, but often hand tweaking can take
> > > > additional advantage of other cleanup.h based magic, or things like
> > > > return dev_err_probe().
> > > > https://lore.kernel.org/all/20240211174237.182947-1-jic23@kernel.org/      
> > > 
> > > It seems you are got all necessary tags to go.    
> > 
> > Light on the driver changes to use it, but seems that we have
> > reached convergence on the infrastructure.  
> 
> What I'll do in the short term is pick up the changes that have been
> reviewed and gained tags (so the infrastructure plus a few of the driver
> changes) and then send a v5 with the remainder. I suspect the driver
> changes have gotten lost in the deluge as IIO has been very busy this week.
> 
> Whilst I will occasionally pick up my own IIO changes with out review
> tags I normally only do that for trivial stuff like build fixes.
> These are simple but not simple enough!
> 
> So applied patches
> 1,2,4,5,12 and 15 to the togreg branch of iio.git which will be initially
> pushed out as testing for 0-day to look at it.

Linus is pushing back on some of the uses for cleanup.h for not being
sufficiently standard c like.

https://lore.kernel.org/linux-cxl/170905252721.2268463.6714121678946763402.stgit@dwillia2-xfh.jf.intel.com/T/#m336ba4087e4f963abbc654ba56eba6d61b77a14b

That's fair enough, but I think makes pull requests with them in higher
risk than normal.

As such, for the things I have queued in the IIO tree (beyond the pull
request GregKH already took which we can cross fingers on),
I'm going to shuffle the tree so that the remainder can be handled
in two separate pull requests:

1) Everything else
2) cleanup.h related including this series.

That should give Greg maximum flexibility to do what makes sense for
char-misc-next.

The scoped_cond_guard() stuff can be easily modified to be near what Linus is
proposing so hopefully we can do that next cycle.

Hopefully I can get this done later today.

Jonathan




> 
> Thanks,
> 
> Jonathan
> 
> > 
> > I'll let it sit until the end of the week though as I want to
> > get a pull request out anyway before taking this into my tree.
> > 
> >   
> > > I commented with some side notes that may be addressed later on.
> > > Up to you.    
> > Thanks. I'll catch up with those shortly. 
> > 
> > Jonathan
> >   
> > >     
> >   
> 
>