No need to include the entire kernel.h when the only thing needed
is the ARRAY_SIZE macro.

Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
 drivers/iio/adc/ad9467.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c
index 5840bef795daae88518b23ca0dec4da0c5fef07f..e1a89806713835ba73acaa5029de9df481399e5c 100644
--- a/drivers/iio/adc/ad9467.c
+++ b/drivers/iio/adc/ad9467.c
@@ -12,7 +12,7 @@
 #include <linux/module.h>
 #include <linux/mutex.h>
 #include <linux/device.h>
-#include <linux/kernel.h>
+#include <linux/array_size.h>
 #include <linux/slab.h>
 #include <linux/spi/spi.h>
 #include <linux/seq_file.h>

-- 
2.47.3

On Mon, Dec 08, 2025 at 12:30:59PM +0000, Tomas Melin wrote:
> No need to include the entire kernel.h when the only thing needed
> is the ARRAY_SIZE macro.

ARRAY_SIZE().

...


> --- a/drivers/iio/adc/ad9467.c
> +++ b/drivers/iio/adc/ad9467.c
> @@ -12,7 +12,7 @@
>  #include <linux/module.h>
>  #include <linux/mutex.h>
>  #include <linux/device.h>
> -#include <linux/kernel.h>
> +#include <linux/array_size.h>
>  #include <linux/slab.h>
>  #include <linux/spi/spi.h>
>  #include <linux/seq_file.h>

Please, keep them sorted.

...

While this change is almost (*) okay per se, I think we can address more
while at it.
- Make the header inclusions ordered (also fix the location of clk.h)
- drop other proxy (device.h) or unneeded headers (bitops.h as it's implied by bitmap.h)
- add missing ones (dev_printk.h, device/devres.h, ...)

(*) no, kernel.h provides more for this driver, for example, your patch
misses types.h.

-- 
With Best Regards,
Andy Shevchenko

Hi,

On 08/12/2025 15:20, Andy Shevchenko wrote:
> On Mon, Dec 08, 2025 at 12:30:59PM +0000, Tomas Melin wrote:
>> No need to include the entire kernel.h when the only thing needed
>> is the ARRAY_SIZE macro.
> 
> ARRAY_SIZE().
> 
> ...
> 
> 
>> --- a/drivers/iio/adc/ad9467.c
>> +++ b/drivers/iio/adc/ad9467.c
>> @@ -12,7 +12,7 @@
>>  #include <linux/module.h>
>>  #include <linux/mutex.h>
>>  #include <linux/device.h>
>> -#include <linux/kernel.h>
>> +#include <linux/array_size.h>
>>  #include <linux/slab.h>
>>  #include <linux/spi/spi.h>
>>  #include <linux/seq_file.h>
> 
> Please, keep them sorted.
These were unfortunately not sorted to start with.

> 
> ...
> 
> While this change is almost (*) okay per se, I think we can address more
> while at it.
> - Make the header inclusions ordered (also fix the location of clk.h)
> - drop other proxy (device.h) or unneeded headers (bitops.h as it's implied by bitmap.h)
> - add missing ones (dev_printk.h, device/devres.h, ...)

As this change (kernel.h) does not seem at all as straightforward as I
envisoned based on your initial request, I will likely change this patch
to instead just sort the headers. Reworking the includes is separate
topic from the intent of this patch series.

Thanks,
Tomas




> 
> (*) no, kernel.h provides more for this driver, for example, your patch
> misses types.h.
>

On Mon, Dec 08, 2025 at 05:41:20PM +0200, Tomas Melin wrote:
> On 08/12/2025 15:20, Andy Shevchenko wrote:
> > On Mon, Dec 08, 2025 at 12:30:59PM +0000, Tomas Melin wrote:
> >> No need to include the entire kernel.h when the only thing needed
> >> is the ARRAY_SIZE macro.
> > 
> > ARRAY_SIZE().

Please, remove context you are agree with.

...

> >>  #include <linux/module.h>
> >>  #include <linux/mutex.h>
> >>  #include <linux/device.h>
> >> -#include <linux/kernel.h>
> >> +#include <linux/array_size.h>
> >>  #include <linux/slab.h>
> >>  #include <linux/spi/spi.h>
> >>  #include <linux/seq_file.h>
> > 
> > Please, keep them sorted.
> These were unfortunately not sorted to start with.

But your patch makes situation even worse. That's what I meant by the comment.
Since there is no a* header, it may be put to the proper location from day 1.

...

> > While this change is almost (*) okay per se, I think we can address more
> > while at it.
> > - Make the header inclusions ordered (also fix the location of clk.h)
> > - drop other proxy (device.h) or unneeded headers (bitops.h as it's implied by bitmap.h)
> > - add missing ones (dev_printk.h, device/devres.h, ...)
> 
> As this change (kernel.h) does not seem at all as straightforward as I
> envisoned based on your initial request, I will likely change this patch
> to instead just sort the headers. Reworking the includes is separate
> topic from the intent of this patch series.

If you don't feel going that deep, than it's a (small) problem.

As the author of a driver feature one should understand slightly more about
this (yeah, currently mess) header stuff. So, your first patch should add
missed headers, if any, that's required to your changes, this one can be
omitted after all.

But on some day you will still need to understand a bit more about headers...

TL;DR: make sure you have all needed headers for your changes in the previous
patch and drop this one.

> > (*) no, kernel.h provides more for this driver, for example, your patch
> > misses types.h.

-- 
With Best Regards,
Andy Shevchenko

Hi,

On 08/12/2025 17:58, Andy Shevchenko wrote:
> On Mon, Dec 08, 2025 at 05:41:20PM +0200, Tomas Melin wrote:
>> On 08/12/2025 15:20, Andy Shevchenko wrote:
>>> On Mon, Dec 08, 2025 at 12:30:59PM +0000, Tomas Melin wrote:
>>>> No need to include the entire kernel.h when the only thing needed
>>>> is the ARRAY_SIZE macro.

>>> While this change is almost (*) okay per se, I think we can address more
>>> while at it.
>>> - Make the header inclusions ordered (also fix the location of clk.h)
>>> - drop other proxy (device.h) or unneeded headers (bitops.h as it's implied by bitmap.h)
>>> - add missing ones (dev_printk.h, device/devres.h, ...)
>>
>> As this change (kernel.h) does not seem at all as straightforward as I
>> envisoned based on your initial request, I will likely change this patch
>> to instead just sort the headers. Reworking the includes is separate
>> topic from the intent of this patch series.
> 
> If you don't feel going that deep, than it's a (small) problem.
> 
> As the author of a driver feature one should understand slightly more about
> this (yeah, currently mess) header stuff. So, your first patch should add
> missed headers, if any, that's required to your changes, this one can be
> omitted after all.
Well, I think reworking the headers is a sane idea, but it is not the
topic of this series.

> 
> But on some day you will still need to understand a bit more about headers...
> 
> TL;DR: make sure you have all needed headers for your changes in the previous
> patch and drop this one.

Hope we mean the same thing, I was thinking more like
   1. sort current headers
   2. add feature which adds the new header in correct location


Thanks,
Tomas


> 
>>> (*) no, kernel.h provides more for this driver, for example, your patch
>>> misses types.h.
>

On Mon, Dec 08, 2025 at 06:21:25PM +0200, Tomas Melin wrote:
> On 08/12/2025 17:58, Andy Shevchenko wrote:
> > On Mon, Dec 08, 2025 at 05:41:20PM +0200, Tomas Melin wrote:
> >> On 08/12/2025 15:20, Andy Shevchenko wrote:
> >>> On Mon, Dec 08, 2025 at 12:30:59PM +0000, Tomas Melin wrote:

...

> > If you don't feel going that deep, than it's a (small) problem.
> > 
> > As the author of a driver feature one should understand slightly more about
> > this (yeah, currently mess) header stuff. So, your first patch should add
> > missed headers, if any, that's required to your changes, this one can be
> > omitted after all.
> Well, I think reworking the headers is a sane idea, but it is not the
> topic of this series.
> 
> > But on some day you will still need to understand a bit more about headers...
> > 
> > TL;DR: make sure you have all needed headers for your changes in the previous
> > patch and drop this one.
> 
> Hope we mean the same thing, I was thinking more like
>    1. sort current headers
>    2. add feature which adds the new header in correct location

Sure, it's even better!

-- 
With Best Regards,
Andy Shevchenko