Re: [PATCH v2 0/9] Support light color temperature and chromaticity

[srinivas pandruvada <srinivas.pandruvada@linux.intel.com>]

On Fri, 2023-12-15 at 11:04 +0100, Linux regression tracking (Thorsten
Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
> 
> Thomas, Jonathan, was any progress made to resolve below regression?

A patch is posted
https://patchwork.kernel.org/project/linux-iio/patch/20231215160159.648963-1-srinivas.pandruvada@linux.intel.com/

Thanks,
Srinivas

> 
> Side note: vormally I would not prod you at this time of the cycle,
> but
> with the festive season coming up I thought it would be wise to ask a
> bit earlier for a status update.
> 
> Ciao, Thorsten
> 
> On 10.12.23 12:07, Jonathan Cameron wrote:
> > On Thu, 7 Dec 2023 00:39:28 +0100
> > Thomas Weißschuh <thomas@t-8ch.de> wrote:
> > > On 2023-09-19 13:40:45+0530, Basavaraj Natikar wrote:
> > > > This series adds support for light color temperature and
> > > > chromaticity.
> > [...]
> > > > Basavaraj Natikar (9):
> > > >   iio: hid-sensor-als: Use channel index to support more hub
> > > > attributes
> > > >   iio: Add channel type light color temperature
> > > >   iio: hid-sensor-als: Add light color temperature support
> > > >   HID: amd_sfh: Add support for light color temperature
> > > >   HID: amd_sfh: Add support for SFH1.1 light color temperature
> > > >   iio: Add channel type for chromaticity
> > > >   iio: hid-sensor-als: Add light chromaticity support
> > > >   HID: amd_sfh: Add light chromaticity support
> > > >   HID: amd_sfh: Add light chromaticity for SFH1.1  
> > > 
> > > This series is breaking probing of hid-sensor-als on Framework 13
> > > AMD
> > > laptops [0].
> > > The problem is that the patches require hid-sensors-als sensors
> > > to also
> > > report chromaticity and color temparature which they don't.
> > Gah.  Missed that in review.  Sorry about that and thanks for
> > digging into
> > this.
> > > 
> > > When I remove the 'if (ret < 0) return ret;' checks in
> > > als_parse_report() probing works and the illuminance/intensity
> > > channels
> > > that show up behave as expected.
> > > Unfortunately this still leaves behind a bunch of unusable
> > > channels.
> > > A nice fix would be to have something like sysfs/hwmon
> > > .is_visible()
> > > callback but that's not supported by IIO.
> > 
> > It's tricky to do because there is no simple association between
> > what is registered as channels and the resulting attribute.  We
> > could probably
> > make it work, but not a simple thing to do.
> > 
> > > 
> > > One aproach would be to detect the usable channels in
> > > als_parse_report()
> > > and then adapt the indio_dev->channels based on that information.
> > > 
> > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=218223
> > 
> > Agreed that adapting the channels is the way to go.
> > Easiest option probably to set the relevant masks to 0 if the
> > chromacity and
> > temp channels aren't there + set their scan index values to -1.
> > That 'should' suppress any attributes being created.
> > Having a gap in scan indexes is common anyway so any userspace
> > should cope
> > with the timestamp being after a gap.
> > 
> > Alternatives would be to rebuild the chan_spec array to not have
> > the entries,
> > or pass in and fill in two copies of the array, picking the
> > relevant one only
> > on discovering if the temp and chromacity channels are present.
> > 
> > Jonathan
> > 
> > > 
> > > #regzbot introduced: 5f05285df691b1e82108eead7165feae238c95ef
> > > #regzbot monitor:
> > > https://bugzilla.kernel.org/show_bug.cgi?id=218223
> > > 
> > 
> > 
> >