Re: [PATCH v5 2/4] iio: adc: ad4691: add initial driver for AD4691 family

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Tue, Mar 31, 2026 at 08:36:42AM +0000, Sabau, Radu bogdan wrote:
> > -----Original Message-----
> > From: Andy Shevchenko <andy.shevchenko@gmail.com>
> > Sent: Monday, March 30, 2026 8:24 PM

...

> > > > > +#include <linux/bitfield.h>
> > > > > +#include <linux/bitops.h>
> > > > > +#include <linux/cleanup.h>
> > > > > +#include <linux/delay.h>
> > > > > +#include <linux/device.h>
> > > >
> > > > Hmm... Is it used? Or perhaps you need only
> > > > dev_printk.h
> > > > device/devres.h
> > > > ?
> > 
> > > I have checked this out and it seems device.h doesn't actually need
> > > to be included anyway since spi.h directly includes device.h, and since
> > > this is a SPI driver that's never going away, it's covered. Will drop it!
> > 
> > No, this is the wrong justification. IWYU principle is about exact
> > match between what is used and included in a file (module). spi.h is
> > not dev_*() provider and may not be considered for that.
> > 
> 
> You are right, my justification was incorrect. Under IWYU, relying on
> spi.h's transitive pull of device.h is not valid. However, I think device.h
> is still needed in this case since struct device is used directly in the code
> both as local variables and in the regmap callbacks.

Really? I can't see that.
(Hint: use of the data type and use of its pointer is a huge difference.)

> Also dev_err_probe() is called directly and lives in device.h.

No, as I started with my replies. The proper header that provides it is
dev_printk.h.

> What's your take on this?

-- 
With Best Regards,
Andy Shevchenko