[ludagoo]

Stop two SPI HID status mismatches on the MacBook Air M1 2020 (J313).

The keyboard, trackpad, and actuator share one controller, so each mismatch is one transfer. At boot, actuator probe sends feature report 0x21, which this descriptor does not have (input 0x3f and output 0x53 only). The controller answers 9c 17 e5 f8. Skip that report when it is absent. The part already powers up device-controlled.

On suspend, NumLock-off is queued on the non-freezable system workqueue and races controller power-off, so the late write reads 00 00 00 00. Flush the keyboard and trackpad LED workers while the controller is still up, refuse new transfers once it is down, and on resume wait for boot packet a0 80 00 00 before returning.

spi-hid-apple-of.c is unchanged. Any other bad status word still warns.

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

Two real s2idle cycles on this kernel showed no spi-hid status mismatch. malik-na's J313 runs of an earlier identical diff (38d4f0804ceb) logged neither the boot mismatch 9c 17 e5 f8 (0 of 8 boots) nor the suspend mismatch 00 00 00 00 (0 of 3). A real lid-close sleep had working keyboard, pointer, and trackpad click. The rebased head cb0f94f8429f was not re-tested.

[malik-na]

Tested on a J313 (M1 Air): removes both status mismatches, at boot and around suspend, and input works straight after a real wake. No regressions found.

	kernels without this PR	this PR
boots logging spi-hid-apple-of spi2.0: status message mismatch: 9c 17 e5 f8	14 of 30 (installed 7.2.11-6-1-ARCH and the other test kernels)	0 of 8
status message mismatch: 00 00 00 00 around suspend (devices + s2idle cycles)	7 of 16 boots that ran both cycles (baseline 1 of 4; the other PR kernels 6 of 12)	0 of 3
SPI HID controller resume incomplete / boot-packet timeout	–	none
device suspend phase, omarchy-m-test	pass	pass, 0 regressions

Real lid-close sleep (70 s, keypress wake): keyboard, pointer and trackpad click with haptic feedback all worked straight away. No mismatch or resume warnings were logged.

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