Re: [PATCH] iio: accel: kionix-kx022a: Apply approximate iwyu principles to includes

[Matti Vaittinen <mazziesaccount@gmail.com>]

On 06/07/2025 20:13, Jonathan Cameron wrote:
> On Mon, 30 Jun 2025 13:40:32 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> 
>> On Sun, Jun 29, 2025 at 07:36:49PM +0100, Jonathan Cameron wrote:
>>> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>>
>>> Motivated by the W=1 warning about export.h that was introduced this cycle
>>> this is an attempt to apply an approximation of the principles of including
>>> whatever is used in the file directly.
>>>
>>> Helped by the include-what-you-use tool.
>>>
>>> Reasoning:
>>> - Drop linux/moduleparam.h as completely unused.
>>> - linux/array_size.h for ARRAY_SIZE()
>>> - linux/bitmap.h for for_each_set_bit
>>> - linux/errno.h for error codes.
>>> - linux/export.h for EXPORT_SYMBOL*()
>>> - linux/math64.h for do_div - alternative would be asm/div64.h
>>> - linux/minmax.h for min()
>>> - linux/sysfs.h for sysfs_emit()
>>> - linux/time64.h for USEC_PER_MSEC
>>> - linux/iio/buffer.h for iio_push_to_buffers_with_timestamp()
>>> - asm/byteorder.h for le16_to_cpu()
>>>
>>> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>>> ---
>>>
>>> I picked this one fairly randomly as an example but longer term I'd like
>>> to look through at least all new drivers with this in mind + all the ones
>>> that are currently messing up my W=1 build logs.
>>>
>>> Note I've been very descriptive in this patch to allow people to suggest
>>> better alternatives for some of the ones that aren't entirely obvious.
>>
>> Thanks for trying it again, very much appreciated!
>>
>> What we actually miss is the database (in any text-based format, even *.d would
>> work I suppose) for the guarantees. For example, if code uses ERR_PTR() and at
>> the same time (very likely) uses something like -EINVAL, the errno.h is implied
>> (and guaranteed!) by err.h. Explicit errno.h is in two cases: 1) nothing is used
>> from err.h, but errno.h; 2) Linux special error codes are in use, e.g. EPROBE_DEFER.
>>
>> Next, what I would really start with is the kernel.h. this is the beast that is
>> happening in many files and old snippets all over the internet, it would be nice
>> to clean it sooner than later. Especially if it's in the headers (should not be
>> as written at the top of that file). So, hence just a priority for these cleanups
>> first.
>>
> Those W=1 warnings are driving me mad, so I'll drive this from point of view
> of cleaning those up.  Will sweep around doing others later.
> 
> Speaking of which lots of discussion about how to do this - anyone fancy
> giving me a review for this actual patch? :)
> 

Sorry, it has been the holiday season for me ;) And still is - until 
August. Well, it's already applied - but still wanted to say it looks 
very good to me!

Yours,
	-- Matti