| Message ID | 20230919081054.2050714-1-Basavaraj.Natikar@amd.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Support light color temperature and chromaticity | expand |
On Tue, 19 Sep 2023, Basavaraj Natikar wrote: > This series adds support for light color temperature and chromaticity. > > v1->v2: > *Rename the series. > *Rename als_illum to als channel as it supports other channels. > *Update patch description to include same reading for the two existing > channels to use channel index to support more hub attributes. > *Keep line length under 80chars in hid-sensor-als. > *Add new channel type IIO_COLORTEMP. > *Update patch description and its subject to add channel type for > 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 > > Documentation/ABI/testing/sysfs-bus-iio | 15 ++ > .../hid_descriptor/amd_sfh_hid_desc.c | 7 + > .../hid_descriptor/amd_sfh_hid_desc.h | 3 + > .../hid_descriptor/amd_sfh_hid_report_desc.h | 21 +++ > drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c | 9 ++ > .../amd-sfh-hid/sfh1_1/amd_sfh_interface.h | 15 ++ > drivers/iio/industrialio-core.c | 2 + > drivers/iio/light/hid-sensor-als.c | 130 +++++++++++++++--- > include/linux/hid-sensor-ids.h | 4 + > include/uapi/linux/iio/types.h | 2 + > tools/iio/iio_event_monitor.c | 3 + > 11 files changed, 195 insertions(+), 16 deletions(-) I believe this should go through Jonathan's tree as a whole, right? Thanks,
On 9/20/2023 7:43 PM, Jiri Kosina wrote: > On Tue, 19 Sep 2023, Basavaraj Natikar wrote: > >> This series adds support for light color temperature and chromaticity. >> >> v1->v2: >> *Rename the series. >> *Rename als_illum to als channel as it supports other channels. >> *Update patch description to include same reading for the two existing >> channels to use channel index to support more hub attributes. >> *Keep line length under 80chars in hid-sensor-als. >> *Add new channel type IIO_COLORTEMP. >> *Update patch description and its subject to add channel type for >> 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 >> >> Documentation/ABI/testing/sysfs-bus-iio | 15 ++ >> .../hid_descriptor/amd_sfh_hid_desc.c | 7 + >> .../hid_descriptor/amd_sfh_hid_desc.h | 3 + >> .../hid_descriptor/amd_sfh_hid_report_desc.h | 21 +++ >> drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c | 9 ++ >> .../amd-sfh-hid/sfh1_1/amd_sfh_interface.h | 15 ++ >> drivers/iio/industrialio-core.c | 2 + >> drivers/iio/light/hid-sensor-als.c | 130 +++++++++++++++--- >> include/linux/hid-sensor-ids.h | 4 + >> include/uapi/linux/iio/types.h | 2 + >> tools/iio/iio_event_monitor.c | 3 + >> 11 files changed, 195 insertions(+), 16 deletions(-) > I believe this should go through Jonathan's tree as a whole, right? Yes, this should go through Jonathan's tree as a whole. If you don't have concerns, can you please ack HID amd_sfh changes? Thanks, -- Basavaraj
On Wed, 20 Sep 2023 20:53:33 +0530 Basavaraj Natikar <bnatikar@amd.com> wrote: > On 9/20/2023 7:43 PM, Jiri Kosina wrote: > > On Tue, 19 Sep 2023, Basavaraj Natikar wrote: > > > >> This series adds support for light color temperature and chromaticity. > >> > >> v1->v2: > >> *Rename the series. > >> *Rename als_illum to als channel as it supports other channels. > >> *Update patch description to include same reading for the two existing > >> channels to use channel index to support more hub attributes. > >> *Keep line length under 80chars in hid-sensor-als. > >> *Add new channel type IIO_COLORTEMP. > >> *Update patch description and its subject to add channel type for > >> 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 > >> > >> Documentation/ABI/testing/sysfs-bus-iio | 15 ++ > >> .../hid_descriptor/amd_sfh_hid_desc.c | 7 + > >> .../hid_descriptor/amd_sfh_hid_desc.h | 3 + > >> .../hid_descriptor/amd_sfh_hid_report_desc.h | 21 +++ > >> drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c | 9 ++ > >> .../amd-sfh-hid/sfh1_1/amd_sfh_interface.h | 15 ++ > >> drivers/iio/industrialio-core.c | 2 + > >> drivers/iio/light/hid-sensor-als.c | 130 +++++++++++++++--- > >> include/linux/hid-sensor-ids.h | 4 + > >> include/uapi/linux/iio/types.h | 2 + > >> tools/iio/iio_event_monitor.c | 3 + > >> 11 files changed, 195 insertions(+), 16 deletions(-) > > I believe this should go through Jonathan's tree as a whole, right? > > Yes, this should go through Jonathan's tree as a whole. > If you don't have concerns, can you please ack HID amd_sfh changes? I'll do an immutable branch in case this needs pulling into the hid tree later in the cycle. In short that means I'll create a branch with just this series on top of v6.6-rc1 and push that out as ib-iio-hid-sensors-v6.6-rc1. I'll then merge that into the IIO tree before I do a pull request. The advantage of this being that it can be pulled into other trees as necessary and keep the same git IDs etc so that git can cleanly unwind the splitting and merging of the history to cover the different paths. However, note this will be messy as the merge into IIO isn't clean. I'll fix it up but please take a quick look at the testing branch of iio.git on kernel.org where the results of that merge will be. Some other channel types were added recently. So the fix was obvious. So applied to the branch ib-iio-hid-sensors-6.6-rc1. I'll merge that into the IIO tree. That will get pushed out as testing for the build bots to see if they can find anything we missed before I push this out as togreg which is what linux-next picks up. Note the IB branch might be rebased if any test issues show up. Thanks, Jonathan > > Thanks, > -- > Basavaraj >
On 9/24/2023 6:12 PM, Jonathan Cameron wrote: > On Wed, 20 Sep 2023 20:53:33 +0530 > Basavaraj Natikar <bnatikar@amd.com> wrote: > >> On 9/20/2023 7:43 PM, Jiri Kosina wrote: >>> On Tue, 19 Sep 2023, Basavaraj Natikar wrote: >>> >>>> This series adds support for light color temperature and chromaticity. >>>> >>>> v1->v2: >>>> *Rename the series. >>>> *Rename als_illum to als channel as it supports other channels. >>>> *Update patch description to include same reading for the two existing >>>> channels to use channel index to support more hub attributes. >>>> *Keep line length under 80chars in hid-sensor-als. >>>> *Add new channel type IIO_COLORTEMP. >>>> *Update patch description and its subject to add channel type for >>>> 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 >>>> >>>> Documentation/ABI/testing/sysfs-bus-iio | 15 ++ >>>> .../hid_descriptor/amd_sfh_hid_desc.c | 7 + >>>> .../hid_descriptor/amd_sfh_hid_desc.h | 3 + >>>> .../hid_descriptor/amd_sfh_hid_report_desc.h | 21 +++ >>>> drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c | 9 ++ >>>> .../amd-sfh-hid/sfh1_1/amd_sfh_interface.h | 15 ++ >>>> drivers/iio/industrialio-core.c | 2 + >>>> drivers/iio/light/hid-sensor-als.c | 130 +++++++++++++++--- >>>> include/linux/hid-sensor-ids.h | 4 + >>>> include/uapi/linux/iio/types.h | 2 + >>>> tools/iio/iio_event_monitor.c | 3 + >>>> 11 files changed, 195 insertions(+), 16 deletions(-) >>> I believe this should go through Jonathan's tree as a whole, right? >> Yes, this should go through Jonathan's tree as a whole. >> If you don't have concerns, can you please ack HID amd_sfh changes? > I'll do an immutable branch in case this needs pulling into the hid tree > later in the cycle. > > In short that means I'll create a branch with just this series on top of v6.6-rc1 > and push that out as ib-iio-hid-sensors-v6.6-rc1. > I'll then merge that into the IIO tree before I do a pull request. > The advantage of this being that it can be pulled into other trees as necessary > and keep the same git IDs etc so that git can cleanly unwind the splitting and > merging of the history to cover the different paths. > > However, note this will be messy as the merge into IIO isn't clean. I'll fix it > up but please take a quick look at the testing branch of iio.git on kernel.org > where the results of that merge will be. Some other channel types were added > recently. So the fix was obvious. > > So applied to the branch ib-iio-hid-sensors-6.6-rc1. I'll merge that into the > IIO tree. That will get pushed out as testing for the build bots to see if they can > find anything we missed before I push this out as togreg which is what > linux-next picks up. > > Note the IB branch might be rebased if any test issues show up. Sure I will check testing branch, Thank you Jonathan. Thanks, -- Basavaraj
Hi everybody, On 2023-09-19 13:40:45+0530, Basavaraj Natikar wrote: > This series adds support for light color temperature and chromaticity. > > v1->v2: > *Rename the series. > *Rename als_illum to als channel as it supports other channels. > *Update patch description to include same reading for the two existing > channels to use channel index to support more hub attributes. > *Keep line length under 80chars in hid-sensor-als. > *Add new channel type IIO_COLORTEMP. > *Update patch description and its subject to add channel type for > 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. 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. 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 #regzbot introduced: 5f05285df691b1e82108eead7165feae238c95ef #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=218223
On Thu, 7 Dec 2023 00:39:28 +0100 Thomas Weißschuh <thomas@t-8ch.de> wrote: > Hi everybody, > > On 2023-09-19 13:40:45+0530, Basavaraj Natikar wrote: > > This series adds support for light color temperature and chromaticity. > > > > v1->v2: > > *Rename the series. > > *Rename als_illum to als channel as it supports other channels. > > *Update patch description to include same reading for the two existing > > channels to use channel index to support more hub attributes. > > *Keep line length under 80chars in hid-sensor-als. > > *Add new channel type IIO_COLORTEMP. > > *Update patch description and its subject to add channel type for > > 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 >
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? 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 >> > > >
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 > > > > > > > > >
[TLDR: This mail in primarily relevant for Linux regression tracking. A change or fix related to the regression discussed in this thread was posted or applied, but it did not use a Closes: tag to point to the report, as Linus and the documentation call for. Things happen, no worries -- but now the regression tracking bot needs to be told manually about the fix. See link in footer if these mails annoy you.] On 07.12.23 00:39, Thomas Weißschuh wrote: > On 2023-09-19 13:40:45+0530, Basavaraj Natikar wrote: > [...] > This series is breaking probing of hid-sensor-als on Framework 13 AMD > laptops [0]. > [...] > #regzbot introduced: 5f05285df691b1e82108eead7165feae238c95ef > #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=218223 #regzbot fix: d4005431673929 #regzbot ignore-activity Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.