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

[Jonathan Cameron]

On Wed, 21 Oct 2026 16:23:07 +0300
Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> wrote:

> On Wed, Oct 21, 2026 at 03:09:43PM +0200, Jan Remes wrote:
> > 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.  
> 
> Actually not really. The manual binding relies on i2c ID table and
> the OF ID table is a fallback.
> 
> > 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.  
> 
> Yes, better to send a new version with better wording in the commit message.

Given we are in merge window and my base tree will be rebased shortly anyway
I don't mind the noise of dropping these.

Hence done so and will wait for v3.

Thanks,

Jonathan

> 
> > Thanks for getting me to learn a bit more.  
> 
> You're welcome!
>