Re: [PATCH 2/2] HID: apple: use the standard keyboard backlight LED name

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing endianness conversion for USB HID report u16 fields.
--

--- Patch [2]: [PATCH 2/2] HID: apple: use the standard keyboard backlight LED name ---
commit fe5b7459cd5f35bce672b51255250e2d12f88cf4
Author: Andre Eikmeyer <dev@deq.rocks>

HID: apple: use the standard keyboard backlight LED name

This commit changes the exposed LED name for the T2-attached butterfly
keyboard backlight from apple::kbd_backlight to the standard
:white:kbd_backlight naming convention. This allows userspace to discover
and handle both the butterfly models and the Magic Keyboards using the same
name without special casing.

> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> --- a/drivers/hid/hid-apple.c
> +++ b/drivers/hid/hid-apple.c
> @@ -860,8 +860,8 @@ static int apple_backlight_init(struct hid_device *hdev)
>  	}
>  
>  	asc->backlight->hdev = hdev;
> -	asc->backlight->cdev.name = "apple::kbd_backlight";
> +	asc->backlight->cdev.name = ":white:" LED_FUNCTION_KBD_BACKLIGHT;
>  	asc->backlight->cdev.max_brightness = rep->backlight_on_max;

[Severity: High]
This is a pre-existing issue and was not introduced by this patch, but does
this code lack endianness conversion for the USB HID report fields?

According to the USB HID standard, multi-byte fields are little-endian.
Since rep->backlight_on_max is a u16 read directly from the raw device
report in apple_backlight_init(), could this result in byte-swapped values
on big-endian architectures and cause an out-of-bounds max_brightness?

A similar issue seems to be present in apple_backlight_set() where native
u16 values for rep->backlight and rep->rate are written into the report
struct without CPU to little-endian conversion before transmission.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260718121527.15924-1-dev@deq.rocks?part=2