As promised, I'm sending my IWYU mapping file, based on Jonathan's
version with a few additional tweaks by me.

Other than adding support for more assembly file business, I've also
experimented with individual symbol definition (see BIT() and GENMASK()
in the following file) - this is to prevent issues such as the tool
wanting you to include <linux/bits.h> when you already have
<linux/bitops.h> in the source file (I agree, doing this symbol by
symbol is tedious, but BIT() and GENMASK() are symbols that especially
do this, and they're included in most, if not all drivers).

Feel free to improve this file and pass it on. I wouldn't really fully
rely on IWYU as even with the mapping file the results can be weird,
but it definitely serves as a good starting point when doing driver
cleanup.

I'm making this patch an RFC - this is not intended for merging.

Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com>
---
 tools/iio/iio.imp | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 tools/iio/iio.imp

diff --git a/tools/iio/iio.imp b/tools/iio/iio.imp
new file mode 100644
index 000000000000..c8e9c509bb93
--- /dev/null
+++ b/tools/iio/iio.imp
@@ -0,0 +1,46 @@
+[
+    { "include": ["\"linux/bitops.h\"", "private", "<linux/bitops.h>", "public"] },
+    { "include": ["\"linux/bits.h\"", "private", "<linux/bits.h>", "public"] },
+    { "include": ["\"linux/byteorder/generic.h\"", "private", "<asm/byteorder.h>", "public"] },
+    { "include": ["\"linux/device.h\"", "private", "<linux/device.h>", "public"] },
+    { "include": ["\"linux/ktime.h\"", "private", "<linux/ktime.h>", "public"] },
+    { "include": ["\"linux/limits.h\"", "private", "<linux/limits.h>", "public"] },
+    { "include": ["\"linux/mod_devicetable.h\"", "private", "<linux/mod_devicetable.h>", "public"] },
+    { "include": ["\"linux/mutex_types.h\"", "private", "<linux/mutex.h>", "public"] },
+    { "include": ["\"linux/pm.h\"", "private", "<linux/pm.h>", "public"] },
+    { "include": ["\"linux/sched.h\"", "private", "<linux/sched.h>", "public"] },
+    { "include": ["\"linux/sizes.h\"", "private", "<linux/sizes.h>", "public"] },
+    { "include": ["\"linux/slab.h\"", "private", "<linux/slab.h>", "public"] },
+    { "include": ["\"linux/spi/spi.h\"", "private", "<linux/spi/spi.h>", "public"] },
+    { "include": ["\"linux/spinlock_types.h\"", "private", "<linux/spinlock.h>", "public"] },
+    { "include": ["\"linux/spinlock.h\"", "private", "<linux/spinlock.h>", "public"] },
+    { "include": ["\"linux/stat.h\"", "private", "<linux/stat.h>", "public"] },
+    { "include": ["\"linux/stdarg.h\"", "private", "<linux/stdarg.h>", "public"] },
+    { "include": ["\"linux/stddef.h\"", "private", "<linux/stddef.h>", "public"] },
+    { "include": ["\"linux/string.h\"", "private", "<linux/string.h>", "public"] },
+    { "include": ["\"linux/stringify.h\"", "private", "<linux/stringify.h>", "public"] },
+    { "include": ["\"linux/sysfs.h\"", "private", "<linux/sysfs.h>", "public"] },
+    { "include": ["\"linux/time.h\"", "private", "<linux/time.h>", "public"] },
+    { "include": ["\"linux/timer.h\"", "private", "<linux/timer.h>", "public"] },
+    { "include": ["\"linux/types.h\"", "private", "<linux/types.h>", "public"] },
+    { "include": ["\"linux/uuid.h\"", "private", "<linux/uuid.h>", "public"] },
+    { "include": ["\"linux/wait.h\"", "private", "<linux/wait.h>", "public"] },
+    { "include": ["\"linux/workqueue.h\"", "private", "<linux/workqueue.h>", "public"] },
+
+    { "include": ["\"vdso/bits.h\"", "private", "<linux/bits.h>", "public"] },
+    { "include": ["\"vdso/ktime.h\"", "private", "<linux/ktime.h>", "public"] },
+    { "include": ["\"vdso/limits.h\"", "private", "<linux/limits.h>", "public"] },
+    { "include": ["\"vdso/time64.h\"", "private", "<linux/time64.h>", "public"] },
+    
+    { "include": ["\"asm-generic/div64.h\"", "private", "<linux/math64.h>", "public"] },
+    { "include": ["\"asm-generic/errno.h\"", "private", "<linux/errno.h>", "public"] },
+    { "include": ["\"asm-generic/errno-base.h\"", "private", "<linux/errno.h>", "public"] },
+    { "include": ["\"asm-generic/int-ll64.h\"", "private", "<linux/types.h>", "public"] },
+
+    { "include": ["\"linux/iio/types.h\"", "private", "<linux/iio/iio.h>", "public"] },
+
+    { "symbol": ["BIT", "private", "<linux/bits.h>", "public"] },
+    { "symbol": ["BIT", "private", "<linux/bitops.h>", "public"] },
+    { "symbol": ["GENMASK", "private", "<linux/bits.h>", "public"] },
+    { "symbol": ["GENMASK", "private", "<linux/bitops.h>", "public"] }
+]
-- 
2.47.3

On 5/12/26 2:35 AM, Joshua Crofts wrote:
> As promised, I'm sending my IWYU mapping file, based on Jonathan's
> version with a few additional tweaks by me.
> 
> Other than adding support for more assembly file business, I've also
> experimented with individual symbol definition (see BIT() and GENMASK()
> in the following file) - this is to prevent issues such as the tool
> wanting you to include <linux/bits.h> when you already have
> <linux/bitops.h> in the source file (I agree, doing this symbol by
> symbol is tedious, but BIT() and GENMASK() are symbols that especially
> do this, and they're included in most, if not all drivers).

TBH, I would favor rules that are easy for machines over rules that
follow existing human conventions. Is there really anything terribly
wrong with including both bits.h and bitops.h other than "convention"?

> 
> Feel free to improve this file and pass it on. I wouldn't really fully
> rely on IWYU as even with the mapping file the results can be weird,
> but it definitely serves as a good starting point when doing driver
> cleanup.
> 
> I'm making this patch an RFC - this is not intended for merging.
> 
Sharing it is nice. Automating it would be amazing.

Not sure what the best way to do this would be though. I've considered
the idea of having an IIO linting service that could run iwyu and some
other checkers that catch common issues, like spaces in { }, where and
where not to use trailing commas, etc.

At first, it could just post the results on a public page (like sashisko).
And if it ends up working well, it could eventually automatically reply
to patch emails.

The hardest part would be finding someone willing to host and maintain it.

On Tue, 12 May 2026 10:36:00 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On 5/12/26 2:35 AM, Joshua Crofts wrote:
> > As promised, I'm sending my IWYU mapping file, based on Jonathan's
> > version with a few additional tweaks by me.
> > 
> > Other than adding support for more assembly file business, I've also
> > experimented with individual symbol definition (see BIT() and GENMASK()
> > in the following file) - this is to prevent issues such as the tool
> > wanting you to include <linux/bits.h> when you already have
> > <linux/bitops.h> in the source file (I agree, doing this symbol by
> > symbol is tedious, but BIT() and GENMASK() are symbols that especially
> > do this, and they're included in most, if not all drivers).  
> 
> TBH, I would favor rules that are easy for machines over rules that
> follow existing human conventions. Is there really anything terribly
> wrong with including both bits.h and bitops.h other than "convention"?

If we do want to obey these conventions maybe a wrapper script rather
than making IWYU do all the work?

> 
> > 
> > Feel free to improve this file and pass it on. I wouldn't really fully
> > rely on IWYU as even with the mapping file the results can be weird,
> > but it definitely serves as a good starting point when doing driver
> > cleanup.
> > 
> > I'm making this patch an RFC - this is not intended for merging.
> >   
> Sharing it is nice. Automating it would be amazing.
> 
> Not sure what the best way to do this would be though. I've considered
> the idea of having an IIO linting service that could run iwyu and some
> other checkers that catch common issues, like spaces in { }, where and
> where not to use trailing commas, etc.
> 
> At first, it could just post the results on a public page (like sashisko).
> And if it ends up working well, it could eventually automatically reply
> to patch emails.
> 
> The hardest part would be finding someone willing to host and maintain it.

Absolutely :(  
>

On Tue, May 12, 2026 at 10:36:00AM -0500, David Lechner wrote:
> On 5/12/26 2:35 AM, Joshua Crofts wrote:
> > As promised, I'm sending my IWYU mapping file, based on Jonathan's
> > version with a few additional tweaks by me.
> > 
> > Other than adding support for more assembly file business, I've also
> > experimented with individual symbol definition (see BIT() and GENMASK()
> > in the following file) - this is to prevent issues such as the tool
> > wanting you to include <linux/bits.h> when you already have
> > <linux/bitops.h> in the source file (I agree, doing this symbol by
> > symbol is tedious, but BIT() and GENMASK() are symbols that especially
> > do this, and they're included in most, if not all drivers).
> 
> TBH, I would favor rules that are easy for machines over rules that
> follow existing human conventions. Is there really anything terribly
> wrong with including both bits.h and bitops.h other than "convention"?

But why? When one needs bitops APIs it includes BIT() and GENMASK() for bonus.
Same with (and especially) bitmap.h. The latter is rather a heavy header.
I do not see any point of having all three and even two out of the three
bits.h, bitops.h, bitmap.h. Also this is a type of unification that helps
scripting any further header reshuffling / cleanups / ... If we ever do
something with bits.h, let's do it on the files that really use only it.

So, all that being said, I prefer to follow guarantees and change them
if required once for all stakeholders, the mixing makes it harder to achieve.
Bonus is the compilation time (maybe negligible, though).


> > Feel free to improve this file and pass it on. I wouldn't really fully
> > rely on IWYU as even with the mapping file the results can be weird,
> > but it definitely serves as a good starting point when doing driver
> > cleanup.
> > 
> > I'm making this patch an RFC - this is not intended for merging.
> > 
> Sharing it is nice. Automating it would be amazing.
> 
> Not sure what the best way to do this would be though. I've considered
> the idea of having an IIO linting service that could run iwyu and some
> other checkers that catch common issues, like spaces in { }, where and
> where not to use trailing commas, etc.
> 
> At first, it could just post the results on a public page (like sashisko).
> And if it ends up working well, it could eventually automatically reply
> to patch emails.
> 
> The hardest part would be finding someone willing to host and maintain it.

Hmm... Where the media subsystem does that? They have their own validation.
Also VFS and maybe others (Ah, yes, net and bpf are also using their bots).

-- 
With Best Regards,
Andy Shevchenko

On 5/12/26 10:51 AM, Andy Shevchenko wrote:
> On Tue, May 12, 2026 at 10:36:00AM -0500, David Lechner wrote:
>> On 5/12/26 2:35 AM, Joshua Crofts wrote:
>>> As promised, I'm sending my IWYU mapping file, based on Jonathan's
>>> version with a few additional tweaks by me.
>>>
>>> Other than adding support for more assembly file business, I've also
>>> experimented with individual symbol definition (see BIT() and GENMASK()
>>> in the following file) - this is to prevent issues such as the tool
>>> wanting you to include <linux/bits.h> when you already have
>>> <linux/bitops.h> in the source file (I agree, doing this symbol by
>>> symbol is tedious, but BIT() and GENMASK() are symbols that especially
>>> do this, and they're included in most, if not all drivers).
>>
>> TBH, I would favor rules that are easy for machines over rules that
>> follow existing human conventions. Is there really anything terribly
>> wrong with including both bits.h and bitops.h other than "convention"?
> 
> But why? When one needs bitops APIs it includes BIT() and GENMASK() for bonus.
> Same with (and especially) bitmap.h. The latter is rather a heavy header.
> I do not see any point of having all three and even two out of the three
> bits.h, bitops.h, bitmap.h. Also this is a type of unification that helps
> scripting any further header reshuffling / cleanups / ... If we ever do
> something with bits.h, let's do it on the files that really use only it.

Because that is human thinking. :-)

I don't particularly care what the end result is as long as we can
automate it. It means one less thing I have to think about.

> 
> So, all that being said, I prefer to follow guarantees and change them
> if required once for all stakeholders, the mixing makes it harder to achieve.
> Bonus is the compilation time (maybe negligible, though).
>

On Tue, 12 May 2026 at 17:57, David Lechner <dlechner@baylibre.com> wrote:
>
> On 5/12/26 10:51 AM, Andy Shevchenko wrote:
> > On Tue, May 12, 2026 at 10:36:00AM -0500, David Lechner wrote:
> >> On 5/12/26 2:35 AM, Joshua Crofts wrote:
> >>> As promised, I'm sending my IWYU mapping file, based on Jonathan's
> >>> version with a few additional tweaks by me.
> >>>
> >>> Other than adding support for more assembly file business, I've also
> >>> experimented with individual symbol definition (see BIT() and GENMASK()
> >>> in the following file) - this is to prevent issues such as the tool
> >>> wanting you to include <linux/bits.h> when you already have
> >>> <linux/bitops.h> in the source file (I agree, doing this symbol by
> >>> symbol is tedious, but BIT() and GENMASK() are symbols that especially
> >>> do this, and they're included in most, if not all drivers).
> >>
> >> TBH, I would favor rules that are easy for machines over rules that
> >> follow existing human conventions. Is there really anything terribly
> >> wrong with including both bits.h and bitops.h other than "convention"?
> >
> > But why? When one needs bitops APIs it includes BIT() and GENMASK() for bonus.
> > Same with (and especially) bitmap.h. The latter is rather a heavy header.
> > I do not see any point of having all three and even two out of the three
> > bits.h, bitops.h, bitmap.h. Also this is a type of unification that helps
> > scripting any further header reshuffling / cleanups / ... If we ever do
> > something with bits.h, let's do it on the files that really use only it.
>
> Because that is human thinking. :-)

IMO human thinking would be to simplify trivial include cases such as
bitops.h and bits.h in one file.

-- 
Kind regards

CJD

On Tue, May 12, 2026 at 07:35:05AM +0000, Joshua Crofts wrote:
> As promised, I'm sending my IWYU mapping file, based on Jonathan's
> version with a few additional tweaks by me.

Please, also add a link to Jonathan's version.

> Other than adding support for more assembly file business, I've also
> experimented with individual symbol definition (see BIT() and GENMASK()
> in the following file) - this is to prevent issues such as the tool
> wanting you to include <linux/bits.h> when you already have
> <linux/bitops.h> in the source file (I agree, doing this symbol by
> symbol is tedious, but BIT() and GENMASK() are symbols that especially
> do this, and they're included in most, if not all drivers).
> 
> Feel free to improve this file and pass it on. I wouldn't really fully
> rely on IWYU as even with the mapping file the results can be weird,
> but it definitely serves as a good starting point when doing driver
> cleanup.
> 
> I'm making this patch an RFC - this is not intended for merging.

...


> +    { "include": ["\"vdso/bits.h\"", "private", "<linux/bits.h>", "public"] },
> +    { "include": ["\"vdso/ktime.h\"", "private", "<linux/ktime.h>", "public"] },
> +    { "include": ["\"vdso/limits.h\"", "private", "<linux/limits.h>", "public"] },
> +    { "include": ["\"vdso/time64.h\"", "private", "<linux/time64.h>", "public"] },

> +    

Trailing whitespaces.

> +    { "include": ["\"asm-generic/div64.h\"", "private", "<linux/math64.h>", "public"] },
> +    { "include": ["\"asm-generic/errno.h\"", "private", "<linux/errno.h>", "public"] },
> +    { "include": ["\"asm-generic/errno-base.h\"", "private", "<linux/errno.h>", "public"] },
> +    { "include": ["\"asm-generic/int-ll64.h\"", "private", "<linux/types.h>", "public"] },

-- 
With Best Regards,
Andy Shevchenko

On Tue, 12 May 2026 at 10:00, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Tue, May 12, 2026 at 07:35:05AM +0000, Joshua Crofts wrote:
> > As promised, I'm sending my IWYU mapping file, based on Jonathan's
> > version with a few additional tweaks by me.
>
> Please, also add a link to Jonathan's version.

Good point, forgot to do that.

>
> > Other than adding support for more assembly file business, I've also
> > experimented with individual symbol definition (see BIT() and GENMASK()
> > in the following file) - this is to prevent issues such as the tool
> > wanting you to include <linux/bits.h> when you already have
> > <linux/bitops.h> in the source file (I agree, doing this symbol by
> > symbol is tedious, but BIT() and GENMASK() are symbols that especially
> > do this, and they're included in most, if not all drivers).
> >
> > Feel free to improve this file and pass it on. I wouldn't really fully
> > rely on IWYU as even with the mapping file the results can be weird,
> > but it definitely serves as a good starting point when doing driver
> > cleanup.
> >
> > I'm making this patch an RFC - this is not intended for merging.
>
> ...
>
>
> > +    { "include": ["\"vdso/bits.h\"", "private", "<linux/bits.h>", "public"] },
> > +    { "include": ["\"vdso/ktime.h\"", "private", "<linux/ktime.h>", "public"] },
> > +    { "include": ["\"vdso/limits.h\"", "private", "<linux/limits.h>", "public"] },
> > +    { "include": ["\"vdso/time64.h\"", "private", "<linux/time64.h>", "public"] },
>
> > +
>
> Trailing whitespaces.

Well, considering this is not intended to be an actual patch...

-- 
Kind regards

CJD

On Tue, May 12, 2026 at 10:04:51AM +0200, Joshua Crofts wrote:
> On Tue, 12 May 2026 at 10:00, Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> >
> > On Tue, May 12, 2026 at 07:35:05AM +0000, Joshua Crofts wrote:
> > > As promised, I'm sending my IWYU mapping file, based on Jonathan's
> > > version with a few additional tweaks by me.
> >
> > Please, also add a link to Jonathan's version.
> 
> Good point, forgot to do that.

> > > Other than adding support for more assembly file business, I've also
> > > experimented with individual symbol definition (see BIT() and GENMASK()
> > > in the following file) - this is to prevent issues such as the tool
> > > wanting you to include <linux/bits.h> when you already have
> > > <linux/bitops.h> in the source file (I agree, doing this symbol by
> > > symbol is tedious, but BIT() and GENMASK() are symbols that especially
> > > do this, and they're included in most, if not all drivers).
> > >
> > > Feel free to improve this file and pass it on. I wouldn't really fully
> > > rely on IWYU as even with the mapping file the results can be weird,
> > > but it definitely serves as a good starting point when doing driver
> > > cleanup.
> > >
> > > I'm making this patch an RFC - this is not intended for merging.

...

> > > +    { "include": ["\"vdso/bits.h\"", "private", "<linux/bits.h>", "public"] },
> > > +    { "include": ["\"vdso/ktime.h\"", "private", "<linux/ktime.h>", "public"] },
> > > +    { "include": ["\"vdso/limits.h\"", "private", "<linux/limits.h>", "public"] },
> > > +    { "include": ["\"vdso/time64.h\"", "private", "<linux/time64.h>", "public"] },
> >
> > > +
> >
> > Trailing whitespaces.
> 
> Well, considering this is not intended to be an actual patch...

Still better to follow the common style.

-- 
With Best Regards,
Andy Shevchenko

On Tue, 12 May 2026 at 10:07, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
> > > Trailing whitespaces.
> >
> > Well, considering this is not intended to be an actual patch...
>
> Still better to follow the common style.

No exceptions :)

-- 
Kind regards

CJD

On Tue, 12 May 2026 at 09:35, Joshua Crofts <joshua.crofts1@gmail.com> wrote:
>
> As promised, I'm sending my IWYU mapping file, based on Jonathan's
> version with a few additional tweaks by me.
>
> Other than adding support for more assembly file business, I've also
> experimented with individual symbol definition (see BIT() and GENMASK()
> in the following file) - this is to prevent issues such as the tool
> wanting you to include <linux/bits.h> when you already have
> <linux/bitops.h> in the source file (I agree, doing this symbol by
> symbol is tedious, but BIT() and GENMASK() are symbols that especially
> do this, and they're included in most, if not all drivers).
>
> Feel free to improve this file and pass it on. I wouldn't really fully
> rely on IWYU as even with the mapping file the results can be weird,
> but it definitely serves as a good starting point when doing driver
> cleanup.
>
> I'm making this patch an RFC - this is not intended for merging.

Annnd I forgot to add the RFC tag... Either way, the above still stands.

-- 
Kind regards

CJD

On Tue, May 12, 2026 at 09:36:57AM +0200, Joshua Crofts wrote:
> On Tue, 12 May 2026 at 09:35, Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> >
> > As promised, I'm sending my IWYU mapping file, based on Jonathan's
> > version with a few additional tweaks by me.
> >
> > Other than adding support for more assembly file business, I've also
> > experimented with individual symbol definition (see BIT() and GENMASK()
> > in the following file) - this is to prevent issues such as the tool
> > wanting you to include <linux/bits.h> when you already have
> > <linux/bitops.h> in the source file (I agree, doing this symbol by
> > symbol is tedious, but BIT() and GENMASK() are symbols that especially
> > do this, and they're included in most, if not all drivers).
> >
> > Feel free to improve this file and pass it on. I wouldn't really fully
> > rely on IWYU as even with the mapping file the results can be weird,
> > but it definitely serves as a good starting point when doing driver
> > cleanup.
> >
> > I'm making this patch an RFC - this is not intended for merging.
> 
> Annnd I forgot to add the RFC tag... Either way, the above still stands.

Thanks for sharing anyways!

-- 
With Best Regards,
Andy Shevchenko