Re: [PATCH v2 0/4] iio: light: tsl2591: fix lux calculation and precision, add I2C ID table, report saturation

From: Jan Remes

Date: Wed Oct 21 2026 - 09:15:07 EST


On Wed, 21 Oct 2026 11:00:56 +0300, Andy Shevchenko wrote:
>
> On Tue, Oct 20, 2026 at 01:31:51PM +0200, Jan Remes wrote:
> > On Mon, 19 Oct 2026 11:50:10 +0300, Andy Shevchenko wrote:
> > > On Mon, Oct 19, 2026 at 10:17:08AM +0200, Jan Remes wrote:
> > > > On Sat, 17 Oct 2026 03:14:11 +0100, Jonathan Cameron wrote:
>
> ...
>
> > > > FWIW, I don't think it to be very urgent, as people probably don't use
> > > > it on x86-64 (seeing both as it had only DT probe support and that
> > > > impacted users are likely to have noticed the oops).
> > >
> > > What do you mean by the second part of the sentence? It's as easy to use on
> > > ACPI platforms as on DT, we have so nice trick called PRP0001, which allows to
> > > enumerate "OF-only" drivers on ACPI platforms via SSDT overlays (or other means
> > > of DSDT/SSDT provisioning).
>
> > I did not know about the PRP0001 (thanks), so please disregard that
> > argument. Still, I believe x86 users to be few if any, since the oops is
> > quite easy to trigger
>
> True.
>
> > and AFAIK most x86 distro kernels ship without CONFIG_OF.
>
> How is this relevant? This driver doesn't use any #ifdef CONFIG_OF or alike,
> so most likely the driver is available for x86 as well.

I thought that CONFIG_OF was needed in order to be able to probe a
device using the driver's OF table. TIL that missing CONFIG_OF prevents
only manual probing (`echo "tsl2519 0x29" > .../new_device`) but not the
ACPI mechanism.

So:
1. Please ignore that argument
2. The wording of my Patch 2 commit message is not correct ("cannot
be probed on a kernel with CONFIG_OF disabled"), I can send a v3
if that's preferable.

Thanks for getting me to learn a bit more.

Best regards,
Jan Remes