Re: [PATCH v2 4/7] iio: light: hid-sensor-prox: 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] Unaligned and endian-dependent memory access from raw HID report buffer
--

commit 15de0e06ef54de0333e9e716c38314e57230ae3f
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>

iio: light: hid-sensor-prox: use u32 instead of unsigned

This commit changes the type of the usage_id parameter from unsigned to u32
in the callback functions of the HID sensor proximity driver. This matches
the expected API and improves code clarity, with no functional changes
intended.

> diff --git a/drivers/iio/light/hid-sensor-prox.c b/drivers/iio/light/hid-sensor-prox.c
> index edc9274a2c076..9059f00f0cedf 100644
> --- a/drivers/iio/light/hid-sensor-prox.c
> +++ b/drivers/iio/light/hid-sensor-prox.c

[ ... ]

> @@ -183,7 +183,7 @@ static int prox_proc_event(struct hid_sensor_hub_device *hsdev,
>  
>  /* Capture samples in local storage */
>  static int prox_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 this function safely access the raw
data from the HID report?

Since raw_data points into a packed HID report buffer, the data might not be
naturally aligned for 16-bit or 32-bit boundaries. It looks like we cast
directly to u16* and u32* later in this function:

drivers/iio/light/hid-sensor-prox.c:prox_capture_sample() {
    ...
    case 2:
        prox_state->human_presence[chan] = *(u16 *)raw_data * multiplier;
        return 0;
    case 4:
        prox_state->human_presence[chan] = *(u32 *)raw_data * multiplier;
    ...
}

Could this trigger unaligned memory access faults on architectures that do
not support them in hardware? 

Also, since HID reports encode data in little-endian format, would using the
host's native byte order here cause incorrect sensor readings on big-endian
architectures?

Would it be safer to use get_unaligned_le16() and get_unaligned_le32()
instead of direct casting?

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