Re: [PATCH v2 4/7] iio: light: hid-sensor-prox: use u32 instead of unsigned
From: sashiko-bot@kernel.org
Date: 2026-06-10 15:47:33
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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
[ ... ]
quoted hunk ↗ jump to hunk
@@ -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