Re: [PATCH v2 3/7] iio: light: hid-sensor-als: use u32 instead of unsigned

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Directly casting the `raw_data` byte array to `u32*` and `s64*` in capture callbacks causes unaligned memory accesses, incorrect endianness handling, and potential out-of-bounds reads.
--

commit 8c6bb48eb0d753aea033d76922dc45a105550e60
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>

iio: light: hid-sensor-als: use u32 instead of unsigned
    
Prefer 'u32' instead of bare 'unsigned' for usage_id variable.
This matches expected callback API type and improves code clarity.

> diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
> index d72e260b82668..ae2fda8dc500a 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c

[ ... ]

> @@ -263,7 +263,7 @@ static int als_proc_event(struct hid_sensor_hub_device *hsdev,
>  
>  /* Capture samples in local storage */
>  static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
> -				unsigned usage_id,
> +				u32 usage_id,
>  				size_t raw_len, char *raw_data,
>  				void *priv)
>  {

[Severity: High]
This is a pre-existing issue, but does the direct cast in this function cause
unaligned memory accesses or endianness issues?

Just a few lines down in als_capture_sample(), raw_data is cast directly:

	int ret = -EINVAL;
	u32 sample_data = *(u32 *)raw_data;

The HID sensor hub core passes a byte pointer raw_data which points directly
into the raw HID report. In sensor_hub_report(), the pointer is incremented
by 1 to skip the report ID, making it immediately unaligned.

Dereferencing this unaligned pointer directly via *(u32 *) or *(s64 *) can
cause unaligned memory access faults on architectures that do not support
them. 

Additionally, since HID reports are strictly little-endian, a direct
cast on a big-endian host might result in corrupted sensor data.

Should this code use get_unaligned_le32() and get_unaligned_le64() instead,
and also validate that raw_len is sufficient to prevent out-of-bounds reads?

The same direct cast pattern appears to be present in other HID sensors,
such as accel_3d_capture_sample() and gyro_3d_capture_sample().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com?part=3