0006-t2.patch appears to route non-T2 `MacBookAir6,2` onto the ACPI `applesmc` path and breaks keyboard backlight

Hello, I have run into what feels like an unintended non-T2 regression from the `applesmc` changes in `6.19/0006-t2.patch` (possibly earlier; I have not bisected when this started and only noticed it with these kernels). Hardware: - Apple `MacBookAir6,2` - non-T2 machine Observed behavior: - On Arch `6.18.13-arch1-1`, keyboard backlight works normally. - On `linux-cachyos 6.19.3-2`, the keyboard backlight does not visibly change. - On the failing kernel, writes to `/sys/class/leds/smc::kbd_backlight/brightness` succeed and read back correctly, but the physical keyboard backlight does not visibly respond. Important runtime difference: - Working Arch kernel: - `smc::kbd_backlight` is under the legacy/platform `applesmc` path - modalias/path shows `platform:applesmc` - Failing `linux-cachyos 6.19.3-2` kernel: - `smc::kbd_backlight` is under ACPI `APP0001:00` - driver path is `/sys/bus/acpi/drivers/applesmc` From source inspection, `6.19/0006-t2.patch` rewrites `drivers/hwmon/applesmc.c` from the legacy platform-driver model to an ACPI `APP0001` model and adds the new resource/MMIO path. It still appears to keep the broad Apple DMI whitelist, including older non-T2 Macs like `MacBookAir`. That makes me suspect the rewritten `applesmc` path is being applied too broadly on non-T2 hardware. In particular, it looks like `MacBookAir6,2` is getting routed onto the new ACPI/T2-style `applesmc` path when it should likely stay on the old legacy/platform path. related: https://discuss.cachyos.org/t/macbook-air-keyboard-backlight-not-working/5388/15