[ludagoo]

leds-pwm treated a zero PWM period readback, with default-state "keep", as a failed read and then applied duty 0. On Apple FPWM that readback is the reset value (ON_CYCLES and OFF_CYCLES both zero). The period from the pwms cell is already in pwm->args.

When the hardware period is 0 and the args period is not, keep that period for later brightness updates and leave the output unchanged. Apply off only when there is still no period to use.

This is the keyboard backlight on a MacBook Air M1 2020 (J313): fpwm1 channel 0, pwms period 40000 ns, default-state = "keep". Probe was logging "failed to read period for kbd_backlight, default to off" and forcing the LED off before systemd-backlight restored the saved level.

The fpwm1 suspend power-state failure is a separate bug and is not changed here.

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 066a421. This pull request's head is 7cd67b0, which is not the commit that was built.

The new probe message appears at boot. malik-na confirmed the keyboard backlight lit early in boot and stayed lit.

[chriskearney]

Reviewed 70c122ce2677885e8ae3d44aa1fe84b7fcd55fa2. The fallback obtains period/polarity from the PWM arguments while retaining KEEP, so probe still skips the call that would apply zero duty. I found no source blocker in that change. The reported brightness can remain zero until userspace writes a value; that differs from turning the hardware output off.

Native ARM64 package build passes for this head and the base control with the same recipe/toolchain. I independently checked the as-built pin and packaged config: CONFIG_LEDS_PWM=y, so the changed driver is compiled in.

No J313 boot test yet. The remaining hardware check is output retention through probe followed by normal brightness control; suspend restoration is a separate change in #221.

[chriskearney]

Tested 70c122ce2677885e8ae3d44aa1fe84b7fcd55fa2 on an M1 MacBook Air (J313), using a native aarch64 build with CONFIG_LEDS_PWM=y (7.2.11-6-219.1-ARCH). One-shot boot, desktop smoke test and keyboard LED sysfs checks passed. Brightness accepted/read back 1 and 63 of 255, then restored its original value of 0.

The tester reported 38 pass, 9 fail and 26 skip, with no functional regressions against the installed-kernel reference. Two additional lab-only failures are the expected installed-package/boot-chain checks for a temporary kernel. The remaining failures were already present. This verifies the brightness interface and readback; it does not measure physical light output or demonstrate a previously failing probe condition. No suspend/resume test ran.

The machine returned to its installed 7.2.11-6-1-ARCH kernel. Protected boot/kernel files and tester files match their pre-test hashes; Wi-Fi, internal/external display operation and GL/Vulkan pixel checks passed after restoration, with no new matched GPU/DART/kernel faults. Receipt: job j1025-172103-d46f; kernel artifact SHA256 1f45ed8686c794a3943267c994568af8fa6108c17f99eef694473a174b7342ca.

[malik-na]

Tested on a J313 (M1 Air): works, no regressions found.

	baseline (19f4965180f4)	this PR
failed to read period for kbd_backlight, default to off at probe	1	0
kbd_backlight brightness after boot	219	219
set 128 → read back	128	128
after the s2idle cycle, set 200 → read back	200	200

All lab tests passed, including the device suspend phase and omarchy-m-test with no regressions against the installed kernel. The PS fpwm1: Failed to reach power state 0xf (… now: 0xa4f) after the s2idle cycle is unchanged, which is expected: that's #221's bug.

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: confirmed by eye on the Mac. Watching the keyboard during boot, the backlight went dark only while the Mac was powered off. It lit early in boot and didn't go dark again; dmesg shows no PWM period read back for kbd_backlight; using 40000 ns and leaving the output unchanged. On every baseline boot (4 of 4) the same probe logs failed to read period … default to off.

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: 70c122ce2677 on 19f4965180f4. The PR has since been rebased to 7cd67b0b4db4 on 937b727ef9a3 with an identical diff; the new base wasn't re-tested.