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@xxxxxxxxxxxxxxx/ 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@xxxxxxxx> 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 > > > > > > > > >
