[PATCH 0/3] HID: iio: callback API signature match for usage_id

[PATCH 0/3] HID: iio: callback API signature match for usage_id

[Sanjay Chitroda]

Hi all,

Most of HID IIO driver has correct 'u32' type of usage_id with
https://lore.kernel.org/all/20260610-6-june-hid-iio-correct-usage-id-v2-0-c3c5f0720493@gmail.com/
series which is applied on iio/testing branch.

On top of the same, this series updates remaining HID IIO drivers
to use 'u32' for the usage_id parameter.

Pending list of HID IIO drivers are extracted with command line:
find drivers/iio/ -type f -name "*hid*" | xargs grep -A 5 static | \
    grep -E -A 5 "_proc_event\(|_capture_sample\(|_parse_report\(" --color | \
    grep usage_id

This matches expected callback API type as HID usage IDs are
defined as 32-bit values.

No functional changes are introduced.

Testing:
  - Compiled with W=1 for each patch in the series

Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
Sanjay Chitroda (3):
      iio: hid-sensor-temperature: use u32 instead of unsigned int
      iio: hid-sensor-humidity: use u32 instead of unsigned int
      iio: hid-sensor-custom-intel-hinge: use u32 instead of unsigned int

 drivers/iio/humidity/hid-sensor-humidity.c           | 6 +++---
 drivers/iio/position/hid-sensor-custom-intel-hinge.c | 6 +++---
 drivers/iio/temperature/hid-sensor-temperature.c     | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)
---
base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
change-id: 20260616-16-jun-hid-iio-u32-api-type-180e8f0b2c37

Best regards,
--  
Sanjay Chitroda <sanjayembeddedse@gmail.com>

[PATCH 1/3] iio: hid-sensor-temperature: use u32 instead of unsigned int

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

Prefer 'u32' instead of 'unsigned int' for usage_id variable.
This matches expected callback API type and improves code clarity.

No functional change.

Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
 drivers/iio/temperature/hid-sensor-temperature.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/temperature/hid-sensor-temperature.c b/drivers/iio/temperature/hid-sensor-temperature.c
index 9f628a8e5cfb..a8d3a15f9c53 100644
--- a/drivers/iio/temperature/hid-sensor-temperature.c
+++ b/drivers/iio/temperature/hid-sensor-temperature.c
@@ -125,7 +125,7 @@ static const struct iio_info temperature_info = {
 
 /* Callback handler to send event after all samples are received and captured */
 static int temperature_proc_event(struct hid_sensor_hub_device *hsdev,
-				unsigned int usage_id, void *pdev)
+				u32 usage_id, void *pdev)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
 	struct temperature_state *temp_st = iio_priv(indio_dev);
@@ -140,7 +140,7 @@ static int temperature_proc_event(struct hid_sensor_hub_device *hsdev,
 
 /* Capture samples in local storage */
 static int temperature_capture_sample(struct hid_sensor_hub_device *hsdev,
-				unsigned int usage_id, size_t raw_len,
+				u32 usage_id, size_t raw_len,
 				char *raw_data, void *pdev)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
@@ -159,7 +159,7 @@ static int temperature_capture_sample(struct hid_sensor_hub_device *hsdev,
 static int temperature_parse_report(struct platform_device *pdev,
 				struct hid_sensor_hub_device *hsdev,
 				struct iio_chan_spec *channels,
-				unsigned int usage_id,
+				u32 usage_id,
 				struct temperature_state *st)
 {
 	int ret;

-- 
2.34.1

Re: [PATCH 1/3] iio: hid-sensor-temperature: use u32 instead of unsigned int

[sashiko-bot]

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

Pre-existing issues:
- [High] Tear-down Order Inversion / Use-After-Free
--

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

iio: hid-sensor-temperature: use u32 instead of unsigned int
    
This commit updates the type of the usage_id variable from unsigned int
to u32 in the callback API. This improves code clarity and matches the
expected callback API type.

> diff --git a/drivers/iio/temperature/hid-sensor-temperature.c b/drivers/iio/temperature/hid-sensor-temperature.c
> index 9f628a8e5cfbe..a8d3a15f9c531 100644
> --- a/drivers/iio/temperature/hid-sensor-temperature.c
> +++ b/drivers/iio/temperature/hid-sensor-temperature.c

[ ... ]

> @@ -159,7 +159,7 @@ static int temperature_capture_sample(struct hid_sensor_hub_device *hsdev,
>  static int temperature_parse_report(struct platform_device *pdev,
>  				struct hid_sensor_hub_device *hsdev,
>  				struct iio_chan_spec *channels,
> -				unsigned int usage_id,
> +				u32 usage_id,
>  				struct temperature_state *st)
>  {
>  	int ret;

[Severity: High]
This is a pre-existing issue, but does hid_temperature_remove() tear down
the trigger and callback too early?

Because the driver uses devm_iio_device_register(), the IIO device will not
be unregistered until after the driver's remove function returns.

However, hid_temperature_remove() manually unregisters the trigger and
callbacks before that:

drivers/iio/temperature/hid-sensor-temperature.c:hid_temperature_remove() {
	...
	sensor_hub_remove_callback(hsdev, HID_USAGE_SENSOR_TEMPERATURE);
	hid_sensor_remove_trigger(indio_dev, &temp_st->common_attributes);
}

Could this leave a race condition window where the IIO device and its
sysfs/char interfaces are still fully accessible to userspace, but its
backing trigger and callbacks have already been destroyed?

Can concurrent access from userspace during this window lead to a
use-after-free?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-16-jun-hid-iio-u32-api-type-v1-0-952c74195f46@gmail.com?part=1

[PATCH 2/3] iio: hid-sensor-humidity: use u32 instead of unsigned int

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

Prefer 'u32' instead of 'unsigned int' for usage_id variable.
This matches expected callback API type and improves code clarity.

No functional change.

Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
 drivers/iio/humidity/hid-sensor-humidity.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
index be2338d5f407..c376a247b137 100644
--- a/drivers/iio/humidity/hid-sensor-humidity.c
+++ b/drivers/iio/humidity/hid-sensor-humidity.c
@@ -127,7 +127,7 @@ static const struct iio_info humidity_info = {
 
 /* Callback handler to send event after all samples are received and captured */
 static int humidity_proc_event(struct hid_sensor_hub_device *hsdev,
-				unsigned int usage_id, void *pdev)
+				u32 usage_id, void *pdev)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
 	struct hid_humidity_state *humid_st = iio_priv(indio_dev);
@@ -141,7 +141,7 @@ static int humidity_proc_event(struct hid_sensor_hub_device *hsdev,
 
 /* Capture samples in local storage */
 static int humidity_capture_sample(struct hid_sensor_hub_device *hsdev,
-				unsigned int usage_id, size_t raw_len,
+				u32 usage_id, size_t raw_len,
 				char *raw_data, void *pdev)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
@@ -161,7 +161,7 @@ static int humidity_capture_sample(struct hid_sensor_hub_device *hsdev,
 static int humidity_parse_report(struct platform_device *pdev,
 				struct hid_sensor_hub_device *hsdev,
 				struct iio_chan_spec *channels,
-				unsigned int usage_id,
+				u32 usage_id,
 				struct hid_humidity_state *st)
 {
 	int ret;

-- 
2.34.1

Re: [PATCH 2/3] iio: hid-sensor-humidity: use u32 instead of unsigned int

[sashiko-bot]

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

Pre-existing issues:
- [High] Directly dereferencing the `raw_data` pointer as an `s32` can cause unaligned access faults on architectures that strictly enforce alignment.
- [High] The driver unconditionally dereferences `raw_data` as a 32-bit integer, ignoring the `raw_len` parameter, leading to potential out-of-bounds memory reads and corrupted sensor data.
- [High] The `humidity_callbacks` structure is statically allocated but its `pdev` field is modified during `probe`. If multiple humidity sensors are probed, the last probed device overwrites `pdev`, causing callbacks for all instances to be routed to the last bound device's state.
--

commit 90e5b3ef32381e14224dfd5cf7711e2aa3c588a2
Author: Sanjay Chitroda <sanjayembeddedse@gmail.com>

iio: hid-sensor-humidity: use u32 instead of unsigned int

This commit updates the usage_id parameter type from unsigned int to u32
in callback functions to match the expected API. It is intended to improve
code clarity with no functional changes.

> diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
> index be2338d5f4070..c376a247b1372 100644
> --- a/drivers/iio/humidity/hid-sensor-humidity.c
> +++ b/drivers/iio/humidity/hid-sensor-humidity.c

[ ... ]

> @@ -141,7 +141,7 @@ static int humidity_proc_event(struct hid_sensor_hub_device *hsdev,
>  
>  /* Capture samples in local storage */
>  static int humidity_capture_sample(struct hid_sensor_hub_device *hsdev,
> -				unsigned int usage_id, size_t raw_len,
> +				u32 usage_id, size_t raw_len,
>  				char *raw_data, void *pdev)
>  {

[Severity: High]
This is a pre-existing issue, but does casting the raw_data pointer directly to
an s32 pointer cause unaligned access faults on architectures that strictly
enforce alignment?

drivers/iio/humidity/hid-sensor-humidity.c:humidity_capture_sample() {
	switch (usage_id) {
	case HID_USAGE_SENSOR_ATMOSPHERIC_HUMIDITY:
		humid_st->scan.humidity_data = *(s32 *)raw_data;
...
}

The raw_data pointer points directly into the packed HID report byte stream,
which may be unaligned.

Could casting it directly to an s32 pointer and dereferencing it trigger
alignment faults on architectures that do not support hardware unaligned
accesses?

[Severity: High]
This is also a pre-existing issue, but does this function unconditionally read 4
bytes from raw_data, ignoring the raw_len parameter?

drivers/iio/humidity/hid-sensor-humidity.c:humidity_capture_sample() {
	switch (usage_id) {
	case HID_USAGE_SENSOR_ATMOSPHERIC_HUMIDITY:
		humid_st->scan.humidity_data = *(s32 *)raw_data;
...
}

By indiscriminately reading 4 bytes, the driver might access out-of-bounds
memory when raw_len is smaller than 4.

Could this trigger memory access faults near page boundaries and leak kernel
heap data to userspace if the upper bits contain adjacent memory garbage?

>  	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> @@ -161,7 +161,7 @@ static int humidity_capture_sample(struct hid_sensor_hub_device *hsdev,
>  static int humidity_parse_report(struct platform_device *pdev,
>  				struct hid_sensor_hub_device *hsdev,
>  				struct iio_chan_spec *channels,
> -				unsigned int usage_id,
> +				u32 usage_id,
>  				struct hid_humidity_state *st)
>  {
>  	int ret;

[Severity: High]
This is a pre-existing issue, but does the shared static humidity_callbacks
structure get overwritten during probe?

drivers/iio/humidity/hid-sensor-humidity.c:
static struct hid_sensor_hub_callbacks humidity_callbacks = {
	.send_event = &humidity_proc_event,
	.capture_sample = &humidity_capture_sample,
};

drivers/iio/humidity/hid-sensor-humidity.c:hid_humidity_probe() {
...
	humidity_callbacks.pdev = pdev;
...
}

If multiple humidity sensors are probed, the last probed device overwrites pdev.

When sensor_hub_raw_event() receives data, it invokes callback->capture_sample
with the overwritten pdev.

Could this cause platform_get_drvdata(pdev) to return the wrong IIO device,
corrupting its state and dropping data for all previously bound sensors?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-16-jun-hid-iio-u32-api-type-v1-0-952c74195f46@gmail.com?part=2

[PATCH 3/3] iio: hid-sensor-custom-intel-hinge: use u32 instead of unsigned int

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

Prefer 'u32' instead of 'unsigned int' for usage_id variable.
This matches expected callback API type and improves code clarity.

No functional change.

Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
 drivers/iio/position/hid-sensor-custom-intel-hinge.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/position/hid-sensor-custom-intel-hinge.c b/drivers/iio/position/hid-sensor-custom-intel-hinge.c
index a26d391661fd..2139ddb670c4 100644
--- a/drivers/iio/position/hid-sensor-custom-intel-hinge.c
+++ b/drivers/iio/position/hid-sensor-custom-intel-hinge.c
@@ -190,7 +190,7 @@ static const struct iio_info hinge_info = {
  * and captured.
  */
 static int hinge_proc_event(struct hid_sensor_hub_device *hsdev,
-			    unsigned int usage_id, void *priv)
+			    u32 usage_id, void *priv)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(priv);
 	struct hinge_state *st = iio_priv(indio_dev);
@@ -209,7 +209,7 @@ static int hinge_proc_event(struct hid_sensor_hub_device *hsdev,
 
 /* Capture samples in local storage */
 static int hinge_capture_sample(struct hid_sensor_hub_device *hsdev,
-				unsigned int usage_id, size_t raw_len,
+				u32 usage_id, size_t raw_len,
 				char *raw_data, void *priv)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(priv);
@@ -236,7 +236,7 @@ static int hinge_capture_sample(struct hid_sensor_hub_device *hsdev,
 static int hinge_parse_report(struct platform_device *pdev,
 			      struct hid_sensor_hub_device *hsdev,
 			      struct iio_chan_spec *channels,
-			      unsigned int usage_id, struct hinge_state *st)
+			      u32 usage_id, struct hinge_state *st)
 {
 	int ret;
 	int i;

-- 
2.34.1