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

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

[Ethan Tidmore]

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.

Thanks,

ET

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

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

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

[Jonathan Cameron]

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



> 

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

[Ethan Tidmore]

On Sat Mar 14, 2026 at 6:07 AM CDT, Jonathan Cameron wrote:
> On Wed, 11 Mar 2026 22:18:07 +0200

...

>
> 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. 

That makes sense. That would be a ton of time spent on reviewing this.

...

> 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.

Yeah, that kills the idea entirely. I was hoping it could be done per
vendor per dir but, I understand why that wouldn't work.

>
> 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.

If a tree wide conversion to iio_push_to_buffers_with_ts() would be
wanted I'd be glad to do that. There is much less volume for this
project and if completed then a deprecated function could be removed.

$ grep -rn "iio_push_to_buffers_with_timestamp" drivers/iio/ | wc -l
73

And this would be much more manageable to review. Would this be a viable
proposal for GsoC?

Thanks,

ET

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

[David Lechner]

On 3/14/26 1:08 PM, Ethan Tidmore wrote:
> On Sat Mar 14, 2026 at 6:07 AM CDT, Jonathan Cameron wrote:
>> On Wed, 11 Mar 2026 22:18:07 +0200
> 
> ...
> 
>>
>> 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. 
> 
> That makes sense. That would be a ton of time spent on reviewing this.
> 
> ...
> 
>> 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.
> 
> Yeah, that kills the idea entirely. I was hoping it could be done per
> vendor per dir but, I understand why that wouldn't work.
> 
>>
>> 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.
> 
> If a tree wide conversion to iio_push_to_buffers_with_ts() would be
> wanted I'd be glad to do that. There is much less volume for this
> project and if completed then a deprecated function could be removed.
> 
> $ grep -rn "iio_push_to_buffers_with_timestamp" drivers/iio/ | wc -l
> 73
> 
> And this would be much more manageable to review. Would this be a viable
> proposal for GsoC?
> 
> Thanks,
> 
> ET
> 

I think most of the same advice still applies. It would still take
significant review time because there are usually other issues lurking
under the surface. We could probably handle 3 drivers a week or so.

Getting them all done would be difficult, but not impossible. :-)

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

[Jonathan Cameron]

On Sat, 14 Mar 2026 13:08:04 -0500
"Ethan Tidmore" <ethantidmore06@gmail.com> wrote:

> On Sat Mar 14, 2026 at 6:07 AM CDT, Jonathan Cameron wrote:
> > On Wed, 11 Mar 2026 22:18:07 +0200  
> 
> ...
> 
> >
> > 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.   
> 
> That makes sense. That would be a ton of time spent on reviewing this.
> 
> ...
> 
> > 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.  
> 
> Yeah, that kills the idea entirely. I was hoping it could be done per
> vendor per dir but, I understand why that wouldn't work.
> 
> >
> > 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.  
> 
> If a tree wide conversion to iio_push_to_buffers_with_ts() would be
> wanted I'd be glad to do that. There is much less volume for this
> project and if completed then a deprecated function could be removed.
> 
> $ grep -rn "iio_push_to_buffers_with_timestamp" drivers/iio/ | wc -l
> 73

It's definitely wanted.

> 
> And this would be much more manageable to review. Would this be a viable
> proposal for GsoC?

Perhaps not on it's own - I'm not sure as I've never been actively involved
in GSOC.  One to discuss with the folk running the kernel projects.
I don't know how open they are to this sort of (mostly) mechanical
cleanup.

There are a bunch of other bits of historical stuff we'd like to get rid of.
Converting drivers to read_avail() to cut down on hand crafting attr or
using the macros in iio/sysfs.h that mostly should go away.

I also have been thinking it would be nice to figure out a cleaner
solution for hardware fifo related attributes which are a case the core doesn't handle
at all today. That was fine when those drivers were rare, but they are getting
more and more common and that stuff certainly looks ugly.

Jonathan

> 
> Thanks,
> 
> ET

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

[Jonathan Cameron]

On Sun, 15 Mar 2026 13:34:12 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On 3/14/26 1:08 PM, Ethan Tidmore wrote:
> > On Sat Mar 14, 2026 at 6:07 AM CDT, Jonathan Cameron wrote:  
> >> On Wed, 11 Mar 2026 22:18:07 +0200  
> > 
> > ...
> >   
> >>
> >> 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.   
> > 
> > That makes sense. That would be a ton of time spent on reviewing this.
> > 
> > ...
> >   
> >> 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.  
> > 
> > Yeah, that kills the idea entirely. I was hoping it could be done per
> > vendor per dir but, I understand why that wouldn't work.
> >   
> >>
> >> 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.  
> > 
> > If a tree wide conversion to iio_push_to_buffers_with_ts() would be
> > wanted I'd be glad to do that. There is much less volume for this
> > project and if completed then a deprecated function could be removed.
> > 
> > $ grep -rn "iio_push_to_buffers_with_timestamp" drivers/iio/ | wc -l
> > 73
> > 
> > And this would be much more manageable to review. Would this be a viable
> > proposal for GsoC?
> > 
> > Thanks,
> > 
> > ET
> >   
> 
> I think most of the same advice still applies. It would still take
> significant review time because there are usually other issues lurking
> under the surface. We could probably handle 3 drivers a week or so.
> 
> Getting them all done would be difficult, but not impossible. :-)
This one I see as more worthwhie (and many are really simple like-for-like
with the buffer locally visible) so I'd make time to review
these in say groups of 10 simple ones, or smaller number of the corner
cases. Trick will be get the simple ones out the way first so we can
focus effort on the harder ones which will take real review time.

I don't like have that old interface around and if someone else will
do the work to get rid of it, all the better!

Jonathan

> 
> 
> 
> 

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

[Ethan Tidmore]

On Sun Mar 15, 2026 at 1:41 PM CDT, Jonathan Cameron wrote:
> On Sat, 14 Mar 2026 13:08:04 -0500
> "Ethan Tidmore" <ethantidmore06@gmail.com> wrote:

...

>
> There are a bunch of other bits of historical stuff we'd like to get rid of.
> Converting drivers to read_avail() to cut down on hand crafting attr or
> using the macros in iio/sysfs.h that mostly should go away.

Thoughts on doing a broader "Historical ABI cleanup"? Including the
conversion of iio_push_to_buffers_with_timestamp() and read_avail() and
the macros you mentioned. And if there are others please let me know.

Also, as David Lechner said, "there are usually other issues lurking
under the surface", so including that + edge cases I believe this
wouldn't be just a mechanical process and would fit the requirements of
a "Large" GSoC project.

>
> I also have been thinking it would be nice to figure out a cleaner
> solution for hardware fifo related attributes which are a case the core doesn't handle
> at all today. That was fine when those drivers were rare, but they are getting
> more and more common and that stuff certainly looks ugly.

Honestly, this is above my experience level, but this is the kind of
work I want to be able to do in the future.

Thanks,

ET

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

[Ethan Tidmore]

On Sun Mar 15, 2026 at 8:11 PM CDT, Ethan Tidmore wrote:
> On Sun Mar 15, 2026 at 1:41 PM CDT, Jonathan Cameron wrote:
>> On Sat, 14 Mar 2026 13:08:04 -0500
>> "Ethan Tidmore" <ethantidmore06@gmail.com> wrote:

Just found out that the IIO Group isn't doing GSoC this year. Will look
into Device Tree Bindings instead.

Thanks,

ET