[ludagoo]

The CT720 (FireFish2) report already carries four channel counts and a correlated color temperature beside the lux float. The shared helper stored one reading and registered one IIO channel, so those fields never reached sysfs.

Publish red, green, blue, and clear counts plus color temperature on aop-sensors-als when the part is the CT720. Color is accepted only when both integration-time copies match, are non-zero, and are at most 10000000. A report that fails that gate still publishes lux and clears a stale color sample. VD6286, CT817, and the lid-angle sensor stay on their single channel through the default decode path.

The helper publishes the slots with a seqlock. A reader that keeps colliding with the writer returns EAGAIN instead of spinning on the same CPU.

Checked against three captured J313 reports with an offline mirror of the integer conversion.

Session build, Monday 26 Oct 2026 05:02 PM -03: linux-aurora 7.2.11-6-2-ARCH (package 7.2.11.aurora6-2), branch local/j313-test at 7638df0. makepkg exited 0. rustc 1.85.0, LLVM/clang 18.1.8. This machine is running that kernel. The stacked commit compiled in was f368523. This pull request's earlier head was 2e02efd, which is not the commit that was built.

Channels were read on 7.2.11-6-2-ARCH: uncovered red 6, green 5, blue 1, clear 14; covered clear 11; flashlight red 482, green 784, blue 507, clear 1786.

Follow-up, not hardware-tested

9c4c6c83dd21 publishes color temperature only when the clear count is at least 12. Below that it returns -ENODATA for CCT and still publishes red, green, blue, and clear. Covered clear 11 is below the threshold; uncovered clear 14 is not. The near-darkness temperatures this is meant to drop are 788 K, 1288 K, 2904 K, and 6781 K.

The valid mask is replaced by each report, not OR-ed. A CT720 report that fails the layout check contributes only the lux bit, so the previous color sample reads back as ENODATA. A zero mask never reaches that store, so a report with no reading keeps the last sample. That replace was checked and left as designed.

The clear-count threshold is not hardware-tested.

[malik-na]

Tested on a J313 (M1 Air): works, no regressions found. aop-sensors-als now publishes the CT720 colour channels:

	baseline (19f4965180f4)	this PR
IIO channels	in_illuminance_input	in_illuminance_input, in_colortemp_input, in_intensity_{red,green,blue,clear}_raw
readings (room light)	12.0 lux	11.0 lux, 5489 K, R/G/B/C = 17 / 26 / 13 / 55

That matches the description in the code comment: about 5460 K, green > red > blue, clear largest. All lab tests passed, including the device suspend phase and omarchy-m-test with no regressions.

Two notes:

• The PR description is a copy of leds: pwm: do not force the LED off when period readback is zero #219's (leds-pwm zero period). It should describe the CT720 colour channels.
• process_fakehid_report() stores valid as just this report's mask. A report that carries lux but fails the CT720 layout check (integration-time copies disagree) clears the colour channels' valid bits, so they read ENODATA until the next full report. If that's not intended, OR the mask into valid instead of replacing it. I didn't see this happen in this run.

How this was tested

• Hardware: MacBook Air (M1, 2020), J313, BCM4378 (brcmfmac4378b1-pcie), DCP 13.5, booted through U-Boot → Limine.
• Kernels: this PR's head and its parent 19f4965180f4 (the baseline), built with the Air's own /proc/config.gz and booted once each as a one-shot test entry. The Mac returns to its installed 7.2.11-6-1-ARCH after every run.
• Each boot ran:
  • a device-phase suspend test (pm_test=devices through systemctl suspend)
  • omarchy-m-test, compared with a run on the installed kernel
  • a check script that reads dmesg counters, writes the keyboard and panel backlight (420, 419, 189, then back), lists ALS IIO channels, re-associates Wi-Fi twice with nmcli con up, and does one pm_test=platform s2idle cycle (noirq + resume_early, auto-wakes after 5 s)
• Not covered: a real s2idle with a keypress wake, Touch ID enrollment/verify with a finger, and how brightness looks.

[malik-na]

Follow-up from a hands-on run (phone torch, sensor covered, dark room):

condition	lux	colortemp	R / G / B / clear
torch on	320	5523 K	607 / 735 / 472 / 1782
torch held steady	~131	~5600 K	249 / 302 / 196 / 733
dark / covered	0.13–0.23	ENODATA	0 / 0–1 / 0 / 0

All channels track the light together, and a white LED reading ~5500 K is plausible. One thing to consider: at near-zero counts (clear ≤ 11) in_colortemp_input sometimes reads 788 K, 1288 K, 2904 K or 6781 K instead of ENODATA, because the firmware's CCT-valid byte is set on noise. A minimum count (on clear, say) before publishing CCT would keep those out of userspace.

How this was tested

• MacBook Air (M1, 2020), J313, DCP 13.5, BCM4378, booted through U-Boot → Limine.
• This PR's head and its parent 19f4965180f4 (the baseline), built with the Air's own /proc/config.gz and booted as one-shot test entries. The Mac returns to its installed 7.2.11-6-1-ARCH after every run.
• Automated boots: device-phase suspend (pm_test=devices), omarchy-m-test, and a check script (dmesg counters, keyboard and panel backlight writes, ALS channels, two nmcli con up re-associations, one pm_test=platform s2idle cycle).
• Hands-on boots: a person at the Mac doing a real lid-close sleep and keypress wake, using the brightness keys, and covering or lighting the ALS, while the kernel's state was logged every 2 s.
• Tested commit: 86ce068d8d6b on 19f4965180f4. The PR has since been rebased to 2e02efda819c on 937b727ef9a3 with an identical diff; the new base wasn't re-tested.