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

[David Lechner <dlechner@baylibre.com>]

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