Re: [PATCH v1 1/4] iio: light: Unshadow error codes in ->store()

[Jonathan Cameron]

On Tue, 18 Aug 2026 16:11:15 +0200
Joshua Crofts <joshua.crofts1@xxxxxxxxx> wrote:

> On Mon, 17 Aug 2026 14:12:56 -0500
> "Maxwell Doose" <maxwell@xxxxxxxxxxx> wrote:
> 
> ...
> 
> > > Absolutely. One patch per driver for this and not more than 10 ish
> > > drivers in a series or out for review at a tiem.  This stuff is still quite
> > > tricky to review, even with details on why each header change below the ---
> > >
> > > Also precursor patches for any significant reordering to put them in alphabetical
> > > + block for IIO headers just to make it easier to read the patch that cleans
> > > up what is included.
> > >
> > > I've done some of these as have many others. It's worthy work but slow to
> > > do!  I'd suggest we leave it as a newbie task, but it requires more understanding
> > > than typical for one of those - so if you want to take it on (probably take
> > > a year or more to finish given review bandwidth!) then that would be most
> > > welcome.
> > >    
> > 
> > What we ought to do is start by removing all of the kernel.h inclusions
> > and then we can go into each individual driver and do IWYU on them. Not
> > sure if we want all of the IWYU stuff (including kernel.h removal)
> > rolled up into one patch per driver or if we want to split patches into
> > kernel.h removal and then IWYU (hopefully this time I can get iwyu-tool
> > setup so it won't be *as* gruelling). Or in the case of we leave it as a
> > newbie task maybe we just add it to the TODO (since this is probably one
> > of those things that happens over time when we revisit drivers).  
> 
> Well, removing kernel.h is essentially IWYU, as we have to include the actual
> used headers we were pulling in transitively. It should definitely be a task
> for newcomers, nevertheless as Jonathan says it's not exactly easy to do from
> the get go (and automating it with iwyu-tool can also be a headache). Also,
> I've had a pretty good experience with AI when it comes to verifying headers.
> 
> I'll probably send a series removing it from some sensor type subdirectory,
> just to get the ball rolling?

Definitely need to include the kernel.h removal as part of iwyu, otherwise
we may well run into random build issues.

Yes, a series - one per driver for a specific sensor type directory would be
a good starting point.  Split the bigger ones up into multiple series to
keep the numbers manageable.

Jonathan

>