[PATCH AUTOSEL 6.18-6.12] iio: hid-sensor: als: scale each channel individually
From: Sasha Levin
Date: Mon Oct 19 2026 - 10:31:58 EST
From: Daniel Schaefer <dhs@xxxxxxxxxx>
[ Upstream commit cad928dad9a4c26aa56b4223dc2a29bca517fb5f ]
Some sensors have multiple channels (not just brightness but color ALS
sensors) with different scaling factors.
Signed-off-by: Daniel Schaefer <dhs@xxxxxxxxxx>
Link: https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/merge_requests/413
Tested-by: Sven Vainküla <sven@xxxxxxxxxxxxxxxxxx> #Asus ProArt PX13 laptop.
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@xxxxxxxxxxxxxxx>
Signed-off-by: Jonathan Cameron <jonathan.cameron@xxxxxxxxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
LLM Generated explanations, may be completely bogus:
The local tree is **Linux 7.3-rc4** (mainline). Color ALS channels exist
here (since v6.9), and this is a small per-channel IIO scale correctness
fix with a real user report. Full phase walkthrough follows.
===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================
**Step 1.1: PARSE THE SUBJECT LINE**
Record: **[iio/hid-sensor-als] [scale] scale each ALS channel
individually rather than using one illuminance scale for every channel**
- Subsystem: `iio: hid-sensor: als`
- Verb: “scale” (correctness of IIO `in_*_scale`, not a refactor)
- Claimed intent: color ALS sensors have per-channel scaling factors;
the driver used a single shared scale
**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record: tags (ignoring pipeline `Signed-off-by: Sasha Levin` /
`[Upstream commit …]`):
- **Signed-off-by:** Daniel Schaefer `<dhs@xxxxxxxxxx>` (author,
Framework)
- **Link:** `https://gitlab.freedesktop.org/hadess/iio-sensor-
proxy/-/merge_requests/413`
- **Tested-by:** Sven Vainküla (Asus ProArt PX13)
- **Acked-by:** Srinivas Pandruvada (HID sensor hub maintainer)
- **Signed-off-by:** Jonathan Cameron (IIO maintainer)
- **No Fixes:** (expected for this review)
- **No Cc: stable:** (expected)
- **No Reported-by / syzbot / KASAN**
Notable: real hardware Tested-by, userspace (iio-sensor-proxy) link,
maintainer Ack.
**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- **Bug:** some HID ALS devices are color ALS (illuminance + color
temperature + chromaticity), not brightness-only, and those extra
channels have different HID unit/exponent than illuminance.
- **Symptom:** userspace (iio-sensor-proxy, compositors) applies the
illuminance scale to color-temp/chromaticity raw values → wrong
physical units (night light / color management broken or nonsense).
- **Version info:** none in the message. Color/chromaticity channels
themselves landed in v6.9.
- **Root cause:** `hid_sensor_format_scale()` was called only on
`als[CHANNEL_SCAN_INDEX_INTENSITY]` and that one scale was returned
for every channel.
**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: **Not a hidden cleanup.** It is an explicit correctness fix:
wrong IIO SCALE sysfs values for extra ALS channels. Same class as
`8b518cdb03f5f` (“iio: hid-sensor-prox: support multi-channel SCALE
calculation”), which had `Cc: stable` and `Fixes:`.
===============================================================
PHASE 2: DIFF ANALYSIS - LINE BY LINE
===============================================================
**Step 2.1: INVENTORY THE CHANGES**
Record:
- **File:** `drivers/iio/light/hid-sensor-als.c` only
- **Size:** 12 insertions, 10 deletions (net +2)
- **Functions:** `struct als_state`, `als_read_raw()`,
`als_parse_report()`
- **Scope:** single-file surgical driver fix
**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
1. **State:** `scale_pre_decml` / `scale_post_decml` / `scale_precision`
become arrays of `CHANNEL_SCAN_INDEX_MAX`.
2. **`als_read_raw` IIO_CHAN_INFO_SCALE:** used to return the one
illuminance scale for any channel; now indexes by `chan->scan_index`,
with a bounds check.
3. **`als_parse_report`:** scale is computed **inside** the per-usage
loop with `st->als[i]` (that channel’s units/exponent), instead of
once afterward from intensity only.
**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record: **[Logic / correctness]** IIO SCALE ABI wrong for color ALS.
`hid_sensor_format_scale()` (verified in `hid-sensor-attributes.c`)
matches `usage_id` (still the ALS sensor usage `0x200041`) **and**
`attr_info->units`, then applies `attr_info->unit_expo`. The per-channel
difference is those HID attribute fields. Intensity/illuminance share
`HID_USAGE_SENSOR_LIGHT_ILLUM`; color-temp and chromaticity have
different attributes, so they must not reuse intensity’s exponent.
Classic brightness-only ALS is unchanged: both intensity and illum still
use the same HID usage and therefore the same scale.
**Step 2.4: ASSESS THE FIX QUALITY**
Record:
- **Quality:** obviously correct; same pattern as hid-sensor-prox
(`scale_pre_decml[index]` + format_scale in the parse loop).
- **Minimal:** no unrelated edits.
- **Regression risk:** low. Traditional ALS behavior is preserved.
Color-temp/chromaticity SCALE sysfs values change from wrong to
correct (intended).
- **Known limitation (discussed on-list, not a NAK):**
`IIO_CHAN_INFO_SCALE` stays `info_mask_shared_by_type`, so
chromaticity X and Y share one sysfs scale. Jonathan Cameron: that
only matters if X and Y scales differ; the reported bug is illuminance
vs color-temp. Author: “in practice it's probably not needed and the
patch works as is.” No v2 was required; v1 was applied.
===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================
**Step 3.1: BLAME THE CHANGED LINES**
Record:
- Shared scale fields date to **`36783d09f1a5c`** (“iio: hid-sensors:
ALS: adjust scale and offset”, 2014) — correct when there was only
illuminance.
- Extra channels: **`3765d426fe864`** color temperature,
**`2ec17b1950bb8`** chromaticity, both **v6.9-rc1**. That is when one
scale became wrong.
- Dynamic channel assignment: **`f2a71ebdf2312`** (v6.9).
**Step 3.2: FOLLOW THE FIXES: TAG**
Record: **No Fixes: tag.** Closest introduction of the bug is the v6.9
color-temp/chromaticity additions. Those commits **are** ancestors of
this 7.3-rc4 tree (`git merge-base --is-ancestor` not required for each;
`git describe --contains` shows `v6.9-rc1`).
**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record: recent ALS history includes channel init refactor, timestamp
alignment, probe race fix. **No prerequisite series** for this patch
(standalone v1). **No follow-ups** on this file after `cad928dad9a4c`.
**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: Daniel Schaefer has this single IIO commit in-tree. Not the
subsystem maintainer. Weight comes from **Acked-by Srinivas Pandruvada**
and **SOB Jonathan Cameron**.
**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: needs existing `als[]` per-channel attribute array,
`CHANNEL_SCAN_INDEX_*`, and `hid_sensor_format_scale()` — all present
here since v6.9 / much earlier. **Applies standalone.** Prox analog
`8b518cdb03f5f` is a sibling pattern, not a dependency.
===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================
**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- **b4 dig:** https://patch.msgid.link/20260723-chromaticity-v1-1-
5ef5746ace2a@xxxxxxxxxx
- **Series:** v1 only (no v2/v3 despite author briefly offering a v2 for
`info_mask_separate`)
- **Jonathan Cameron (2026-07-26):** SCALE shared-by-type is OK unless
chromaticity X/Y differ; “the change here looks fine”; queued on
iio.git testing.
- **Srinivas Pandruvada:** Acked-by.
- **David Lechner:** explained testing-branch means accepted/applied.
- **No NAK.** No reviewer asked for Cc: stable.
- **Sashiko bot:** flagged shared-by-type (addressed in discussion) and
a **pre-existing** buffer-layout concern, not introduced by this
patch.
**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record: To/Cc included Jonathan Cameron, Srinivas Pandruvada, David
Lechner, Nuno Sá, Andy Shevchenko, linux-iio, linux-input. Right
maintainers were in the loop.
**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: GitLab iio-sensor-proxy MR 413 returned **HTTP 403** (UNVERIFIED
beyond the Link tag). Hardware evidence that **is** verified: Tested-by
on Asus ProArt PX13; Framework author; iio-sensor-proxy is the standard
userspace for laptop ALS.
**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: standalone, not N/M. Prox multi-channel SCALE (`8b518cdb03f5f`,
v6.15-rc6) is the same bug class and **was** `Cc: stable`.
**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: no “stable” in the lore mbox. UNVERIFIED whether linux-stable@
discussed it separately (no lore.kernel.org/stable hit via b4 thread).
===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================
**Step 5.1: IDENTIFY KEY FUNCTIONS**
Record: `als_read_raw`, `als_parse_report`; struct `als_state`. Probe
path: `hid_als_probe` → `als_parse_report`. Sysfs/read path: IIO core →
`als_info.read_raw` → `als_read_raw`.
**Step 5.2: TRACE CALLERS**
Record:
- `als_parse_report`: only from `hid_als_probe` (HID-SENSOR-200041 /
LISS-0041 platform devices).
- `als_read_raw`: IIO `read_raw` for sysfs (`in_illuminance_scale`,
`in_colortemp_scale`, `in_chromaticity_x_scale`, etc.) and buffered
metadata. **Userspace-reachable**, not IRQ-hot.
**Step 5.3: TRACE CALLEES**
Record: `hid_sensor_format_scale()` → unit table +
`adjust_exponent_nano()`; `sensor_hub_input_get_attribute_info()` fills
per-channel `units`/`unit_expo`.
**Step 5.4: FOLLOW THE CALL CHAIN**
Record: unprivileged users can read IIO sysfs on a system with this HID
ALS. Color ALS on recent AMD/laptop HID sensor hubs (v6.9+ channels).
**Reachable from userspace.**
**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: hid-sensor-prox already uses per-channel scale arrays. Other
hid-sensor drivers (accel, gyro, press, temp) still use a single scale
because they are not mixed-unit multi-channel in the same way. ALS was
the leftover mismatch after v6.9 extra channels.
===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================
**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Record:
- **Tree:** `git describe HEAD` = `v7.3-rc4-27-gf0100363d8c37`; `make
kernelversion` = **7.3.0-rc4** (Linus mainline, not an LTS branch).
- Color ALS channels **are** in `hid-sensor-als.c`.
- Commit **`cad928dad9a4c` is already an ancestor of HEAD** (working
tree already has per-channel arrays). That is the mainline landing of
this fix during 7.3, **not** a reason to reject it on technical merit
(pipeline “already selected” markers ignored).
- Bug introduced **v6.9** (2024), long before this tree.
**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: against **this** 7.3 tree the change is already applied / would
apply cleanly. Context in the submitted v1 still used
`als_adjust_channel_bit_mask`; this tree uses `iio_scan_type`
initializer (`cded217233845`). For **this** checkout that is already
resolved. No extra commits required for the logic of the fix.
**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: this exact commit is in HEAD. No later revert or competing fix.
No other ALS scale fix in `git log cad928dad9a4c..HEAD --
drivers/iio/light/hid-sensor-als.c`.
===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================
**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: **IIO light / HID sensor hub ALS** — **PERIPHERAL to IMPORTANT**
depending on hardware. Laptop ambient/color light (Framework, Asus
ProArt, HID sensor hubs). Not mm/net/fs core, but commonly used on
notebooks via iio-sensor-proxy.
**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: mature driver (2012), still getting channel and race fixes.
Color ALS is several years old (v6.9), not brand-new staging code.
===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================
**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: **driver-specific / config-specific** (`CONFIG_HID_SENSOR_ALS`).
Users of HID color ALS (not every illuminance-only ALS). Confirmed: Asus
ProArt PX13; likely other color-ALS HID laptops.
**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: **Every read of IIO SCALE** for color-temp/chromaticity, and
every userspace conversion of those raw values. Not a race. Unprivileged
users with IIO device node/sysfs access can observe it. Common on
affected laptops at session start (iio-sensor-proxy).
**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: **Wrong sensor physical values** (color temperature /
chromaticity), not oops/UAF/deadlock. Userspace brightness for classic
ALS is unaffected (same HID usage). Compositor color/night-light using
color ALS can be wrong. **Severity: MEDIUM** — real, user-visible, “oh
that’s not good,” not CRITICAL.
**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- **Benefit:** correct IIO scale on color ALS; unbreaks iio-sensor-
proxy/hardware that already exists in this lineage.
- **Risk:** very low (≈20-line, one file, no locking/API).
- **Ratio:** favorable. Same class already taken for stable in prox.
===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================
**Step 9.1: COMPILE THE EVIDENCE**
**FOR backporting**
- Real userspace-visible bug: mixed-unit color ALS channels reused
illuminance scale.
- Hit on real hardware (Asus ProArt PX13 Tested-by); iio-sensor-proxy MR
linked.
- Small, obviously correct, acked by HID-sensor maintainer, applied by
IIO maintainer.
- Identical prox bug was explicitly `Cc: stable`.
- This tree **has** the v6.9 color/chromaticity channels, so the bug
class exists in this lineage.
- Traditional ALS unchanged; only extra channels’ SCALE change.
- Fits documented stable bar: “real bug that bothers people” / “oh,
that’s not good.”
**AGAINST**
- Not a crash, UAF, deadlock, or security issue.
- No Fixes:/Cc: stable (not a negative per review rules).
- SCALE still shared-by-type for chromaticity X/Y (accepted by
maintainer as OK for the reported bug).
- Peripheral driver, not core kernel.
- GitLab MR body UNVERIFIED (403).
**UNRESOLVED**
- Exact HID unit/exponent values on the PX13 (not in-tree).
- Whether chromaticity X vs Y ever differ on some firmware (maintainers
assumed no).
**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — Tested-by, Acked-by, IIO
maintainer queued v1.
2. Fixes a real bug that affects users? **PASS** — wrong IIO scale on
color ALS; userspace conversion broken.
3. Important issue? **PASS** (medium “oh that’s not good,” not CRITICAL
crash) — wrong physical units for sensors userspace actually uses.
4. Small and contained? **PASS** — one file, +12/−10.
5. No new features or APIs? **PASS** — corrects SCALE for channels that
already exist; no new sysfs ABI.
6. Can apply to the local tree? **PASS** — affected code is in 7.3-rc4;
change is already the current code here.
**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: not a device-ID/quirk/DT/build/docs exception. Ordinary driver
correctness fix.
**Step 9.4: MAKE YOUR DECISION**
This tree’s ALS driver includes color-temperature and chromaticity
channels added in v6.9 but, until this change, advertised a single
illuminance-derived IIO scale for all of them. That is a real, tested
userspace bug (wrong color ALS readings via iio-sensor-proxy), not a
feature or cleanup. The patch is small, matches the already-stable-
worthy prox multi-channel SCALE fix, and does not change classic
illuminance ALS. Benefit outweighs the low regression risk.
### What the commit solves and why it matters here
Color HID ALS devices expose extra channels with different HID
units/exponents. The driver formatted scale only from the intensity
attribute, so `in_colortemp_scale` / chromaticity scale were wrong. On
this 7.3-rc4 tree those channels exist, so the fix is applicable and is
the right stable-style correctness change for that hardware.
### Risk vs benefit
Benefit: correct sensor units for color ALS on laptops that already use
this driver. Risk: a few array/index changes on the sysfs read path;
illuminance-only devices keep the same scale.
### Concerns
No crash-level severity; chromaticity X/Y still share type-wide scale
(explicitly accepted). Neither blocks backport of this contained fix.
Verification:
- [Phase 1] Parsed tags: Tested-by Sven Vainküla (Asus ProArt PX13);
Acked-by Srinivas Pandruvada; SOB Jonathan Cameron; Link to iio-
sensor-proxy MR 413; no Fixes/Cc:stable
- [Phase 2] Diff: 12+/10- in hid-sensor-als.c; scalar scale → per-
scan_index arrays; format_scale moved into parse loop over
`st->als[i]`
- [Phase 2] Verified `hid_sensor_format_scale()` uses `attr_info->units`
and `unit_expo`; ALS unit table only has ALS+0 and ALS+LUX
- [Phase 3] `git describe HEAD` = v7.3-rc4-27-gf0100363d8c37;
kernelversion 7.3.0-rc4
- [Phase 3] `git merge-base --is-ancestor cad928dad9a4c HEAD` → already
in this tree (mainline landing)
- [Phase 3] Color temp `3765d426fe864` and chromaticity `2ec17b1950bb8`
contained in v6.9-rc1
- [Phase 3] Prox analog `8b518cdb03f5f` had Cc: stable + Fixes
- [Phase 3] No follow-up commits on hid-sensor-als.c after cad928dad9a4c
- [Phase 4] `b4 dig -c cad928dad9a4c`: lore https://patch.msgid.link/202
60723-chromaticity-v1-1-5ef5746ace2a@xxxxxxxxxx
- [Phase 4] `b4 dig -a`: v1 only
- [Phase 4] `b4 dig -w`: IIO + HID-sensor maintainers on To/Cc
- [Phase 4] mbox: Jonathan OK with shared-by-type; Srinivas Ack; no NAK;
no stable nomination in thread
- [Phase 4] GitLab MR fetch: 403, body UNVERIFIED
- [Phase 5] semcode: not available; grep shows als_read_raw only from
als_info; hid_als_probe only caller of als_parse_report
- [Phase 6] Working tree already has per-channel scale arrays at lines
36–38 and 332–334
- [Phase 8] Failure mode: wrong IIO SCALE for color ALS → incorrect
userspace conversion; severity MEDIUM
- UNVERIFIED: exact PX13 HID unit/exponent values; linux-stable@
discussion outside this thread
**YES**
drivers/iio/light/hid-sensor-als.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
index 384572844162c..232cb58e0a9ff 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -33,9 +33,9 @@ struct als_state {
u32 illum[CHANNEL_SCAN_INDEX_MAX];
aligned_s64 timestamp;
} scan;
- int scale_pre_decml;
- int scale_post_decml;
- int scale_precision;
+ int scale_pre_decml[CHANNEL_SCAN_INDEX_MAX];
+ int scale_post_decml[CHANNEL_SCAN_INDEX_MAX];
+ int scale_precision[CHANNEL_SCAN_INDEX_MAX];
int value_offset;
int num_channels;
s64 timestamp;
@@ -186,9 +186,11 @@ static int als_read_raw(struct iio_dev *indio_dev,
ret_type = IIO_VAL_INT;
break;
case IIO_CHAN_INFO_SCALE:
- *val = als_state->scale_pre_decml;
- *val2 = als_state->scale_post_decml;
- ret_type = als_state->scale_precision;
+ if (chan->scan_index >= CHANNEL_SCAN_INDEX_MAX)
+ return -EINVAL;
+ *val = als_state->scale_pre_decml[chan->scan_index];
+ *val2 = als_state->scale_post_decml[chan->scan_index];
+ ret_type = als_state->scale_precision[chan->scan_index];
break;
case IIO_CHAN_INFO_OFFSET:
*val = als_state->value_offset;
@@ -338,6 +340,10 @@ static int als_parse_report(struct platform_device *pdev,
als_adjust_channel_bit_mask(channels, index, st->als[i].size);
++index;
+ st->scale_precision[i] = hid_sensor_format_scale(usage_id,
+ &st->als[i], &st->scale_pre_decml[i],
+ &st->scale_post_decml[i]);
+
dev_dbg(&pdev->dev, "als %x:%x\n", st->als[i].index,
st->als[i].report_id);
}
@@ -347,10 +353,6 @@ static int als_parse_report(struct platform_device *pdev,
if (index)
ret = 0;
- st->scale_precision = hid_sensor_format_scale(usage_id,
- &st->als[CHANNEL_SCAN_INDEX_INTENSITY],
- &st->scale_pre_decml, &st->scale_post_decml);
-
return ret;
}
--
2.53.0