Re: [RFC] GSoC 2026: Transitioning IIO to guard() and scoped_guard()

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 11 Mar 2026 22:18:07 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Wed, Mar 11, 2026 at 9:46 PM Ethan Tidmore <ethantidmore06@gmail.com> wrote:
> >
> > Hi Jonathan, Andy,
> >
> > I'm proposing converting the entire IIO tree to use guard() and
> > scoped_guard() instead of manual locking. This would greatly reduce
> > boilerplate, the possibility of lock leaks and modernize the entire IIO
> > tree to current kernel API standards.
> >
> > $ grep -rn "mutex_lock" drivers/iio | wc -l
> > 874
> >
> > This would have to be a "Large" project according to GsoC due to the scale
> > of the IIO tree. If this is wanted, I would like to know how these changes
> > should be submitted to make this easier to review. I was thinking per
> > directory per vendor.
> >
> > Looking forward to hear your feedback.  
> 
> Most of the cases can be automated with coccinelle, so you can even
> create a script in one day and estimate the real number of corner
> cases (id est that require manual work). That said, it's not a big
> project from amount of drivers point of view. It might be still big
> depending on corner cases and if you wish to target them as well.

Hi Ethan

I'm not keen on a mass cleanup like this without taking a closer look at
the drivers. I would say (based on gut feeling rather than actually
having checked the stats) that perhaps 25% of these patches result in
feedback on the surrounding code or follow on improvements that are
enabled. I don't mind people doing this sort of stuff as a 'first few
patches' thing but not seeing the benefit from a mass conversion. In
particular it would absorb a huge amount of reviewer time. Improving
readability of old drivers that aren't touched that much isn't a big
priority for me at least.  This particular guard() pattern thing
isn't universal. Sometimes it's not the right tool to use or much
more comprehensive restructuring is needed to make it useful

As to the your question on how this 'might' be done, it would need to be
1 patch per driver because this will cause chaos for backports of later
fixes due to significant churn.

There are ABI changes that we want to push through the tree such
as iio_push_to_buffers_with_ts() but that's because the new ABI
is inherently safer and I want to get rid of the old one.
Some of those cases are easy, others much less so.

Jonathan



>