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

[Javier Carrasco]

On Tue Jun 2, 2026 at 1:12 PM CEST, Andy Shevchenko wrote:
> 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.
>

Thanks, I'll take a look at it in case it finds some more missing
headers.

>> >> +#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%?
>

Yes, that is possible. I'll add it to V5.

>> >> +	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.

I will provide the link to the message where I explained this instead of
copying the explanation to keep the discussion in one place. The mail
belongs to the discussion thread for [2/4] (this patch) anyway:

https://lore.kernel.org/all/20260531-veml6031x00-v4-0-e64f7fdce38d@xxxxxxxxx/

Best regards,
Javier