Re: [PATCH] iio: mapping file for include-what-you-use tool

[Joshua Crofts]

On Tue, 12 May 2026 at 17:57, David Lechner <dlechner@xxxxxxxxxxxx> 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