From: Jonathan Cameron <jic23@kernel.org>
To: rafasales@usp.br
Cc: andy@kernel.org, dlechner@baylibre.com, nuno.sa@analog.com,
"Gustavo C. Arakaki" <gustavo.arakaki@usp.br>,
linux-iio@vger.kernel.org
Subject: Re: [PATCH v2 1/2] iio: light: ltr501: update header inclusions
Date: Tue, 21 Apr 2026 11:19:19 +0100 [thread overview]
Message-ID: <20260421111919.5ad809fb@jic23-huawei> (raw)
In-Reply-To: <20260421021023.563290-2-rafasales@usp.br>
On Mon, 20 Apr 2026 23:10:00 -0300
rafasales@usp.br wrote:
> From: "Rafael B. Sales" <rafasales@usp.br>
>
> Update header inclusions to follow IWYU (Include What You Use)
> principle
>
> Signed-off-by: Rafael B. Sales <rafasales@usp.br>
> Co-developed-by: Gustavo C. Arakaki <gustavo.arakaki@usp.br>
> Signed-off-by: Gustavo C. Arakaki <gustavo.arakaki@usp.br>
Hi,
One of the issues with the kernel view of IWYU is it's a bit fuzzy
(and not well documented yet).
That means there are some headers we assume will always include
certain others. So if you need the 'outer' header the inner one
is not normally included as well.
So the comments below are very much my opinion on what should
and should not be there. Others may have different views and
it is always a little flexible for some of them.
> ---
> drivers/iio/light/ltr501.c | 36 +++++++++++++++++++++++++++---------
> 1 file changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
> index 4d99ae336f61..75a49fd9bce0 100644
> --- a/drivers/iio/light/ltr501.c
> +++ b/drivers/iio/light/ltr501.c
> @@ -9,20 +9,38 @@
> * TODO: IR LED characteristics
> */
>
> -#include <linux/module.h>
> -#include <linux/mod_devicetable.h>
> -#include <linux/i2c.h>
> -#include <linux/err.h>
> +#include <asm/page.h>
asm headers if they are needed are always in a separate block
after all the linux/ ones
However, it is very rare to see asm/page.h in a driver. Why do
you need it here?
I'm going to guess it is for PAGE_SIZE?
That bit of code needs a rework to use sysfs_emit_at()
instead. If you have time please could you make that change as well
as a precursor to this patch and then we won't need this one.
Alternative would be to convert to using read_avail().
That would be even better but is a more complex change.
> +#include <linux/array_size.h>
> +#include <linux/bitops.h>
I think it is always safe to assume bitops.h will include bits.h
> +#include <linux/bits.h>
> +#include <linux/byteorder/generic.h>
> +#include <linux/cleanup.h>
Is this used at this point? I think this might want to be in the following patch.
> #include <linux/delay.h>
> -#include <linux/regmap.h>
> -#include <linux/regulator/consumer.h>
> -
> -#include <linux/iio/iio.h>
> +#include <linux/dev_printk.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
It's a bit indirect but I think we can always assume err.h will include
errno.h
> +#include <linux/i2c.h>
> +#include <linux/iio/buffer.h>
> #include <linux/iio/events.h>
> +#include <linux/iio/iio.h>
> #include <linux/iio/sysfs.h>
> #include <linux/iio/trigger_consumer.h>
> -#include <linux/iio/buffer.h>
> #include <linux/iio/triggered_buffer.h>
> +#include <linux/iio/types.h>
Common practice (as this driver was previously doing) is to keep the
iio headers in a separate block at the end. I don't tend to enforce this
but given the driver was already doing so, I think keeping it that way makes sense.
> +#include <linux/interrupt.h>
> +#include <linux/irqreturn.h>
interrupt.h will always include irqreturn.h so don't need
irqreturn.h
> +#include <linux/math.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/pm.h>
> +#include <linux/property.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/sprintf.h>
> +#include <linux/sysfs.h>
> +#include <linux/types.h>
>
> #define LTR501_ALS_CONTR 0x80 /* ALS operation mode, SW reset */
> #define LTR501_PS_CONTR 0x81 /* PS operation mode */
next prev parent reply other threads:[~2026-04-21 10:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 2:09 [PATCH v2 0/2] iio: light: ltr501: cleanup locking and headers rafasales
2026-04-21 2:10 ` [PATCH v2 1/2] iio: light: ltr501: update header inclusions rafasales
2026-04-21 10:19 ` Jonathan Cameron [this message]
2026-04-21 12:49 ` Andy Shevchenko
2026-04-21 12:52 ` Andy Shevchenko
2026-04-21 2:10 ` [PATCH v2 2/2] iio: light: ltr501: use automatic cleanup of locks rafasales
2026-04-21 10:29 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260421111919.5ad809fb@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=gustavo.arakaki@usp.br \
--cc=linux-iio@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=rafasales@usp.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox