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

["Maxwell Doose" <maxwell@maxwelld.cc>]

On Sun Aug 16, 2026 at 9:54 PM CDT
Jonathan Cameron <jic23@kernel.org> wrote:

> On Fri, 14 Aug 2026 11:50:57 +0300
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
>> On Fri, Aug 14, 2026 at 10:25:32AM +0200, Joshua Crofts wrote:
>> > On Fri, 14 Aug 2026 at 10:16, Andy Shevchenko
>> > <andriy.shevchenko@linux.intel.com> wrote:  
>> > > On Thu, Aug 13, 2026 at 09:47:00PM -0500, Maxwell Doose wrote:  
>> > > > On Thu Aug 13, 2026 at 3:47 PM CDT
>> > > > Andy Shevchenko <andy.shevchenko@gmail.com> wrote:  
>> > > > > On Thu, Aug 13, 2026 at 8:52 PM Maxwell Doose <maxwell@maxwelld.cc> wrote:  
>> 
>> ...
>> 
>> > > > > Note, that kernel.h shouldn't be there at all, but that is definitely out
>> > > > > of scope here.  
>> > > >
>> > > > Makes sense. I wonder if it may be worth doing a patch series removing
>> > > > all of the kernel.h inclusions in IIO all at once (or maybe some drivers
>> > > > have a legitimate use for it, but that seems highly unlikely).  
>> > >
>> > > Yes, for sure! I have simply had no time to do it myself, but I have a low-prio
>> > > item in my always grown TODO list. So, if you do that, I will really appreciate!
>> > > But be careful, the actual patches should care about the whole bunch of the
>> > > inclusions, and not just about kernel.h. This means each driver should be
>> > > carefully inspected in accordance with the IWYU principles.  
>> > 
>> > This will be a gruelling task (implementing and reviewing), but perhaps it
>> > would be easier to do one sensor type at a time instead of the entire
>> > subsystem.  
> 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).

thanks,
max

>> 
>> I would start from the easy cases where kernel.h is just not used at all (not
>> even as a "proxy" header). Then continue with the rest.
>
> yeah - if there are cheap ones were we can just drop it and now do the
> rest of the work then I don't mind seeing those on their own.
>
> Jonathan
>> 
>> Joshua, note, it's only about the drivers that have explicit kernel.h
>> inclusion. In general the entire IIO needs to be revisited, indeed.
>> 
>> $ git grep -n -lw linux/kernel.h -- drivers/iio/ | wc -l
>> 234
>> 
>> $ git ls-files | grep ^drivers/iio/.*\.c$ | wc -l
>> 707
>>