Re: [PATCH v4 2/4] iio: light: add support for veml6031x00 ALS series

[Andy Shevchenko]

On Tue, Jun 02, 2026 at 12:45:35PM +0200, Javier Carrasco wrote:
> On Tue Jun 2, 2026 at 12:01 PM CEST, Andy Shevchenko wrote:
> > On Sun, May 31, 2026 at 09:58:22PM +0200, Javier Carrasco wrote:

...

> > + array_size.h
> >
> >> +#include <linux/bitfield.h>
> >> +#include <linux/bits.h>
> >> +#include <linux/i2c.h>
> >
> >> +#include <linux/module.h>
> >> +#include <linux/mod_devicetable.h>
> >
> > In C locale it seems wrong order.
> >
> >> +#include <linux/mutex.h>
> >> +#include <linux/pm_runtime.h>
> >> +#include <linux/regmap.h>
> >
> > + types.h
> 
> Do you know any tool to automate this beyond asking an AI? Manual
> auditing is not very reliablo and it is not that difficult to miss a
> header that has been indirectly included. Building with W=1 and similar
> stuff did not help.

`iwyu`, but it needs a custom configuration. Even with that it's quite far from ideal.
The custom config had been shared in the linux-iio@ mailing list this year.

> >> +#include <linux/units.h>

...

> >> +	/* integration time + 10 % to ensure completion */
> >
> > fsleep() adds up to 25%, isn't it enough?
> 
> The problem is that it adds UP to 25%, but that is not guaranteed. If
> almost no extra delay is added, it will be below the margin I added,
> which was necessary when I tested this delay with real hardware.

Noted. Can it_usec be precalculated already to include that 10%?

> >> +	fsleep(it_usec + (it_usec / 10));

...

> >> +	pm_runtime_put_autosuspend(dev);
> >
> > Hmm... But why? Wouldn't this be problematic with reference count on the failed
> > devm_iio_device_register() below?
> 
> I could move this a bit further down after devm_iio_device_register(),
> but as I replied to a Sashiko complaint, the reference count will never
> underflow in this configuration.

Please, add a comment elaborating on that, it's not clear at glance.

-- 
With Best Regards,
Andy Shevchenko