[PATCH 00/11] HID: iio: warning clean up and prefer kernel coding style

[PATCH 00/11] HID: iio: warning clean up and prefer kernel coding style

[Sanjay Chitroda]

Hi all,

This series updates HID IIO drivers to resolve checkpatch and
kernel coding style issue.

This improves readability and follow standard kernel coding style
No functional changes are introduced.

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

---
Sanjay Chitroda (11):
      iio: hid-sensors: add missing blank line after declarations
      iio: humidity: hid-sensor-humidity: align parenthesis for readability
      iio: gyro: hid-sensor-gyro-3d: align parenthesis for readability
      iio: magnetometer: hid-sensor-magn-3d: align parenthesis for readability
      iio: humidity: hid-sensor-humidity: use common device for devres
      iio: position: hid-sensor-custom-intel-hinge: use common device for devres
      iio: temperature: hid-sensor-temperature: use common device for devres
      iio: hid-sensor-magn-3d: use ! instead of explicit NULL check
      iio: hid-sensor-rotation: use ! instead of explicit NULL check
      iio: hid-sensor-incl-3d: use ! instead of explicit NULL check
      iio: hid-sensor-accel-3d: use ! instead of explicit NULL check

 drivers/iio/accel/hid-sensor-accel-3d.c            |  2 +-
 .../iio/common/hid-sensors/hid-sensor-trigger.c    |  3 +
 drivers/iio/gyro/hid-sensor-gyro-3d.c              | 58 ++++++++--------
 drivers/iio/humidity/hid-sensor-humidity.c         | 48 ++++++-------
 drivers/iio/magnetometer/hid-sensor-magn-3d.c      | 80 +++++++++++-----------
 drivers/iio/orientation/hid-sensor-incl-3d.c       |  2 +-
 drivers/iio/orientation/hid-sensor-rotation.c      |  2 +-
 .../iio/position/hid-sensor-custom-intel-hinge.c   |  2 +-
 drivers/iio/temperature/hid-sensor-temperature.c   |  4 +-
 9 files changed, 102 insertions(+), 99 deletions(-)
---
base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
change-id: 20260615-15-jun-hid-iio-alignment-46bba7279be3

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

[PATCH 01/11] iio: hid-sensors: add missing blank line after declarations

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

Add a blank line after variable declarations to improve
readability and align with kernel coding style.

Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
changes in v4:
- Rectify commit message with input from David
---
 drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
index 417c4ab8c1b2..c8ccf96f3d03 100644
--- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
@@ -314,7 +314,9 @@ static int __maybe_unused hid_sensor_resume(struct device *dev)
 {
 	struct iio_dev *indio_dev = dev_get_drvdata(dev);
 	struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
+
 	schedule_work(&attrb->work);
+
 	return 0;
 }
 
@@ -322,6 +324,7 @@ static int __maybe_unused hid_sensor_runtime_resume(struct device *dev)
 {
 	struct iio_dev *indio_dev = dev_get_drvdata(dev);
 	struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
+
 	return _hid_sensor_power_state(attrb, true);
 }
 

-- 
2.34.1

[PATCH 02/11] iio: humidity: hid-sensor-humidity: align parenthesis for readability

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

Adjust alignment of parentheses to improve readability and
maintain consistency with kernel coding style

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

diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
index be2338d5f407..6fed019f4099 100644
--- a/drivers/iio/humidity/hid-sensor-humidity.c
+++ b/drivers/iio/humidity/hid-sensor-humidity.c
@@ -45,7 +45,7 @@ static const struct iio_chan_spec humidity_channels[] = {
 
 /* Adjust channel real bits based on report descriptor */
 static void humidity_adjust_channel_bit_mask(struct iio_chan_spec *channels,
-					int channel, int size)
+					     int channel, int size)
 {
 	channels[channel].scan_type.sign = 's';
 	/* Real storage bits will change based on the report desc. */
@@ -55,8 +55,8 @@ static void humidity_adjust_channel_bit_mask(struct iio_chan_spec *channels,
 }
 
 static int humidity_read_raw(struct iio_dev *indio_dev,
-				struct iio_chan_spec const *chan,
-				int *val, int *val2, long mask)
+			     struct iio_chan_spec const *chan,
+			     int *val, int *val2, long mask)
 {
 	struct hid_humidity_state *humid_st = iio_priv(indio_dev);
 
@@ -101,8 +101,8 @@ static int humidity_read_raw(struct iio_dev *indio_dev,
 }
 
 static int humidity_write_raw(struct iio_dev *indio_dev,
-				struct iio_chan_spec const *chan,
-				int val, int val2, long mask)
+			      struct iio_chan_spec const *chan,
+			      int val, int val2, long mask)
 {
 	struct hid_humidity_state *humid_st = iio_priv(indio_dev);
 
@@ -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)
+			       unsigned int usage_id, void *pdev)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
 	struct hid_humidity_state *humid_st = iio_priv(indio_dev);
@@ -141,8 +141,8 @@ 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,
-				char *raw_data, void *pdev)
+				   unsigned int usage_id, size_t raw_len,
+				   char *raw_data, void *pdev)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
 	struct hid_humidity_state *humid_st = iio_priv(indio_dev);
@@ -159,17 +159,17 @@ static int humidity_capture_sample(struct hid_sensor_hub_device *hsdev,
 
 /* Parse report which is specific to an usage id */
 static int humidity_parse_report(struct platform_device *pdev,
-				struct hid_sensor_hub_device *hsdev,
-				struct iio_chan_spec *channels,
-				unsigned int usage_id,
-				struct hid_humidity_state *st)
+				 struct hid_sensor_hub_device *hsdev,
+				 struct iio_chan_spec *channels,
+				 unsigned int usage_id,
+				 struct hid_humidity_state *st)
 {
 	int ret;
 
 	ret = sensor_hub_input_get_attribute_info(hsdev, HID_INPUT_REPORT,
-					usage_id,
-					HID_USAGE_SENSOR_ATMOSPHERIC_HUMIDITY,
-					&st->humidity_attr);
+						  usage_id,
+						  HID_USAGE_SENSOR_ATMOSPHERIC_HUMIDITY,
+						  &st->humidity_attr);
 	if (ret < 0)
 		return ret;
 
@@ -208,20 +208,20 @@ static int hid_humidity_probe(struct platform_device *pdev)
 	humid_st->common_attributes.pdev = pdev;
 
 	ret = hid_sensor_parse_common_attributes(hsdev,
-					HID_USAGE_SENSOR_HUMIDITY,
-					&humid_st->common_attributes,
-					humidity_sensitivity_addresses,
-					ARRAY_SIZE(humidity_sensitivity_addresses));
+						 HID_USAGE_SENSOR_HUMIDITY,
+						 &humid_st->common_attributes,
+						 humidity_sensitivity_addresses,
+						 ARRAY_SIZE(humidity_sensitivity_addresses));
 	if (ret)
 		return ret;
 
 	humid_chans = devm_kmemdup(&indio_dev->dev, humidity_channels,
-					sizeof(humidity_channels), GFP_KERNEL);
+				   sizeof(humidity_channels), GFP_KERNEL);
 	if (!humid_chans)
 		return -ENOMEM;
 
 	ret = humidity_parse_report(pdev, hsdev, humid_chans,
-				HID_USAGE_SENSOR_HUMIDITY, humid_st);
+				    HID_USAGE_SENSOR_HUMIDITY, humid_st);
 	if (ret)
 		return ret;
 
@@ -234,7 +234,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
 	atomic_set(&humid_st->common_attributes.data_ready, 0);
 
 	ret = hid_sensor_setup_trigger(indio_dev, name,
-				&humid_st->common_attributes);
+				       &humid_st->common_attributes);
 	if (ret)
 		return ret;
 
@@ -242,7 +242,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
 
 	humidity_callbacks.pdev = pdev;
 	ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_HUMIDITY,
-					&humidity_callbacks);
+					   &humidity_callbacks);
 	if (ret)
 		goto error_remove_trigger;
 

-- 
2.34.1

[PATCH 03/11] iio: gyro: hid-sensor-gyro-3d: align parenthesis for readability

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

Adjust alignment of parentheses to improve readability and
maintain consistency with kernel coding style

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

diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c b/drivers/iio/gyro/hid-sensor-gyro-3d.c
index bbca2111e79b..fa604cf26d06 100644
--- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
+++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
@@ -85,9 +85,9 @@ static const struct iio_chan_spec gyro_3d_channels[] = {
 
 /* Channel read_raw handler */
 static int gyro_3d_read_raw(struct iio_dev *indio_dev,
-			      struct iio_chan_spec const *chan,
-			      int *val, int *val2,
-			      long mask)
+			    struct iio_chan_spec const *chan,
+			    int *val, int *val2,
+			    long mask)
 {
 	struct gyro_3d_state *gyro_state = iio_priv(indio_dev);
 	int report_id = -1;
@@ -112,8 +112,7 @@ static int gyro_3d_read_raw(struct iio_dev *indio_dev,
 					min < 0);
 		else {
 			*val = 0;
-			hid_sensor_power_state(&gyro_state->common_attributes,
-						false);
+			hid_sensor_power_state(&gyro_state->common_attributes, false);
 			return -EINVAL;
 		}
 		hid_sensor_power_state(&gyro_state->common_attributes, false);
@@ -146,10 +145,10 @@ static int gyro_3d_read_raw(struct iio_dev *indio_dev,
 
 /* Channel write_raw handler */
 static int gyro_3d_write_raw(struct iio_dev *indio_dev,
-			       struct iio_chan_spec const *chan,
-			       int val,
-			       int val2,
-			       long mask)
+			     struct iio_chan_spec const *chan,
+			     int val,
+			     int val2,
+			     long mask)
 {
 	struct gyro_3d_state *gyro_state = iio_priv(indio_dev);
 	int ret = 0;
@@ -177,8 +176,8 @@ static const struct iio_info gyro_3d_info = {
 
 /* Callback handler to send event after all samples are received and captured */
 static int gyro_3d_proc_event(struct hid_sensor_hub_device *hsdev,
-				u32 usage_id,
-				void *priv)
+			      u32 usage_id,
+			      void *priv)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(priv);
 	struct gyro_3d_state *gyro_state = iio_priv(indio_dev);
@@ -199,9 +198,9 @@ static int gyro_3d_proc_event(struct hid_sensor_hub_device *hsdev,
 
 /* Capture samples in local storage */
 static int gyro_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
-				u32 usage_id,
-				size_t raw_len, char *raw_data,
-				void *priv)
+				  u32 usage_id,
+				  size_t raw_len, char *raw_data,
+				  void *priv)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(priv);
 	struct gyro_3d_state *gyro_state = iio_priv(indio_dev);
@@ -240,11 +239,12 @@ static int gyro_3d_parse_report(struct platform_device *pdev,
 	int ret;
 
 	for (unsigned int ch = CHANNEL_SCAN_INDEX_X; ch <= CHANNEL_SCAN_INDEX_Z; ch++) {
-		ret = sensor_hub_input_get_attribute_info(hsdev,
-				HID_INPUT_REPORT,
-				usage_id,
-				HID_USAGE_SENSOR_ANGL_VELOCITY_X_AXIS + ch,
-				&st->gyro[ch]);
+		ret = sensor_hub_input_get_attribute_info(
+			hsdev,
+			HID_INPUT_REPORT,
+			usage_id,
+			HID_USAGE_SENSOR_ANGL_VELOCITY_X_AXIS + ch,
+			&st->gyro[ch]);
 		if (ret < 0)
 			break;
 		channels[ch].scan_type = (struct iio_scan_type) {
@@ -254,10 +254,10 @@ static int gyro_3d_parse_report(struct platform_device *pdev,
 		};
 	}
 	dev_dbg(&pdev->dev, "gyro_3d %x:%x, %x:%x, %x:%x\n",
-			st->gyro[0].index,
-			st->gyro[0].report_id,
-			st->gyro[1].index, st->gyro[1].report_id,
-			st->gyro[2].index, st->gyro[2].report_id);
+		st->gyro[0].index,
+		st->gyro[0].report_id,
+		st->gyro[1].index, st->gyro[1].report_id,
+		st->gyro[2].index, st->gyro[2].report_id);
 
 	st->scale_precision = hid_sensor_format_scale(
 				HID_USAGE_SENSOR_GYRO_3D,
@@ -286,10 +286,10 @@ static int hid_gyro_3d_probe(struct platform_device *pdev)
 	gyro_state->common_attributes.pdev = pdev;
 
 	ret = hid_sensor_parse_common_attributes(hsdev,
-						HID_USAGE_SENSOR_GYRO_3D,
-						&gyro_state->common_attributes,
-						gyro_3d_sensitivity_addresses,
-						ARRAY_SIZE(gyro_3d_sensitivity_addresses));
+						 HID_USAGE_SENSOR_GYRO_3D,
+						 &gyro_state->common_attributes,
+						 gyro_3d_sensitivity_addresses,
+						 ARRAY_SIZE(gyro_3d_sensitivity_addresses));
 	if (ret) {
 		dev_err(&pdev->dev, "failed to setup common attributes\n");
 		return ret;
@@ -318,7 +318,7 @@ static int hid_gyro_3d_probe(struct platform_device *pdev)
 	atomic_set(&gyro_state->common_attributes.data_ready, 0);
 
 	ret = hid_sensor_setup_trigger(indio_dev, name,
-					&gyro_state->common_attributes);
+				       &gyro_state->common_attributes);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "trigger setup failed\n");
 		return ret;
@@ -334,7 +334,7 @@ static int hid_gyro_3d_probe(struct platform_device *pdev)
 	gyro_state->callbacks.capture_sample = gyro_3d_capture_sample;
 	gyro_state->callbacks.pdev = pdev;
 	ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_GYRO_3D,
-					&gyro_state->callbacks);
+					   &gyro_state->callbacks);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "callback reg failed\n");
 		goto error_iio_unreg;

-- 
2.34.1

[PATCH 04/11] iio: magnetometer: hid-sensor-magn-3d: align parenthesis for readability

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

Adjust alignment of parentheses to improve readability and
maintain consistency with kernel coding style

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

diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index 23884825eb00..82507297c55b 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -135,9 +135,9 @@ static const struct iio_chan_spec magn_3d_channels[] = {
 
 /* Channel read_raw handler */
 static int magn_3d_read_raw(struct iio_dev *indio_dev,
-			      struct iio_chan_spec const *chan,
-			      int *val, int *val2,
-			      long mask)
+			    struct iio_chan_spec const *chan,
+			    int *val, int *val2,
+			    long mask)
 {
 	struct magn_3d_state *magn_state = iio_priv(indio_dev);
 	int report_id = -1;
@@ -167,8 +167,7 @@ static int magn_3d_read_raw(struct iio_dev *indio_dev,
 				false);
 			return -EINVAL;
 		}
-		hid_sensor_power_state(&magn_state->magn_flux_attributes,
-					false);
+		hid_sensor_power_state(&magn_state->magn_flux_attributes, false);
 		ret_type = IIO_VAL_INT;
 		break;
 	case IIO_CHAN_INFO_SCALE:
@@ -229,10 +228,10 @@ static int magn_3d_read_raw(struct iio_dev *indio_dev,
 
 /* Channel write_raw handler */
 static int magn_3d_write_raw(struct iio_dev *indio_dev,
-			       struct iio_chan_spec const *chan,
-			       int val,
-			       int val2,
-			       long mask)
+			     struct iio_chan_spec const *chan,
+			     int val,
+			     int val2,
+			     long mask)
 {
 	struct magn_3d_state *magn_state = iio_priv(indio_dev);
 	int ret = 0;
@@ -270,8 +269,8 @@ static const struct iio_info magn_3d_info = {
 
 /* Callback handler to send event after all samples are received and captured */
 static int magn_3d_proc_event(struct hid_sensor_hub_device *hsdev,
-				u32 usage_id,
-				void *priv)
+			      u32 usage_id,
+			      void *priv)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(priv);
 	struct magn_3d_state *magn_state = iio_priv(indio_dev);
@@ -292,9 +291,9 @@ static int magn_3d_proc_event(struct hid_sensor_hub_device *hsdev,
 
 /* Capture samples in local storage */
 static int magn_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
-				u32 usage_id,
-				size_t raw_len, char *raw_data,
-				void *priv)
+				  u32 usage_id,
+				  size_t raw_len, char *raw_data,
+				  void *priv)
 {
 	struct iio_dev *indio_dev = platform_get_drvdata(priv);
 	struct magn_3d_state *magn_state = iio_priv(indio_dev);
@@ -353,11 +352,12 @@ static int magn_3d_parse_report(struct platform_device *pdev,
 		u32 address = magn_3d_addresses[i];
 
 		/* Check if usage attribute exists in the sensor hub device */
-		status = sensor_hub_input_get_attribute_info(hsdev,
-			HID_INPUT_REPORT,
-			usage_id,
-			address,
-			&(st->magn[i]));
+		status = sensor_hub_input_get_attribute_info(
+				hsdev,
+				HID_INPUT_REPORT,
+				usage_id,
+				address,
+				&(st->magn[i]));
 		if (!status)
 			attr_count++;
 	}
@@ -368,18 +368,17 @@ static int magn_3d_parse_report(struct platform_device *pdev,
 		return  -EINVAL;
 	}
 
-	dev_dbg(&pdev->dev, "magn_3d Found %d usage attributes\n",
-			attr_count);
+	dev_dbg(&pdev->dev, "magn_3d Found %d usage attributes\n", attr_count);
 	dev_dbg(&pdev->dev, "magn_3d X: %x:%x Y: %x:%x Z: %x:%x\n",
-			st->magn[0].index,
-			st->magn[0].report_id,
-			st->magn[1].index, st->magn[1].report_id,
-			st->magn[2].index, st->magn[2].report_id);
+		st->magn[0].index,
+		st->magn[0].report_id,
+		st->magn[1].index, st->magn[1].report_id,
+		st->magn[2].index, st->magn[2].report_id);
 
 	/* Setup IIO channel array */
 	_channels = devm_kcalloc(&pdev->dev, attr_count,
-				sizeof(struct iio_chan_spec),
-				GFP_KERNEL);
+				 sizeof(struct iio_chan_spec),
+				 GFP_KERNEL);
 	if (!_channels) {
 		dev_err(&pdev->dev,
 			"failed to allocate space for iio channels\n");
@@ -426,8 +425,7 @@ static int magn_3d_parse_report(struct platform_device *pdev,
 
 	*channels = _channels;
 
-	dev_dbg(&pdev->dev, "magn_3d Setup %d IIO channels\n",
-			*chan_count);
+	dev_dbg(&pdev->dev, "magn_3d Setup %d IIO channels\n", *chan_count);
 
 	st->magn_flux_attr.scale_precision = hid_sensor_format_scale(
 				HID_USAGE_SENSOR_COMPASS_3D,
@@ -442,7 +440,8 @@ static int magn_3d_parse_report(struct platform_device *pdev,
 			&st->rot_attr.scale_post_decml);
 
 	if (st->rot_attributes.sensitivity.index < 0) {
-		sensor_hub_input_get_attribute_info(hsdev,
+		sensor_hub_input_get_attribute_info(
+			hsdev,
 			HID_FEATURE_REPORT, usage_id,
 			HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS |
 			HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH,
@@ -477,11 +476,12 @@ static int hid_magn_3d_probe(struct platform_device *pdev)
 	magn_state->magn_flux_attributes.hsdev = hsdev;
 	magn_state->magn_flux_attributes.pdev = pdev;
 
-	ret = hid_sensor_parse_common_attributes(hsdev,
-				HID_USAGE_SENSOR_COMPASS_3D,
-				&magn_state->magn_flux_attributes,
-				magn_3d_sensitivity_addresses,
-				ARRAY_SIZE(magn_3d_sensitivity_addresses));
+	ret = hid_sensor_parse_common_attributes(
+		hsdev,
+		HID_USAGE_SENSOR_COMPASS_3D,
+		&magn_state->magn_flux_attributes,
+		magn_3d_sensitivity_addresses,
+		ARRAY_SIZE(magn_3d_sensitivity_addresses));
 	if (ret) {
 		dev_err(&pdev->dev, "failed to setup common attributes\n");
 		return ret;
@@ -491,8 +491,8 @@ static int hid_magn_3d_probe(struct platform_device *pdev)
 	magn_state->rot_attributes.sensitivity.index = -1;
 
 	ret = magn_3d_parse_report(pdev, hsdev,
-				&channels, &chan_count,
-				HID_USAGE_SENSOR_COMPASS_3D, magn_state);
+				   &channels, &chan_count,
+				   HID_USAGE_SENSOR_COMPASS_3D, magn_state);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to parse report\n");
 		return ret;
@@ -507,7 +507,7 @@ static int hid_magn_3d_probe(struct platform_device *pdev)
 	atomic_set(&magn_state->magn_flux_attributes.data_ready, 0);
 
 	ret = hid_sensor_setup_trigger(indio_dev, name,
-					&magn_state->magn_flux_attributes);
+				       &magn_state->magn_flux_attributes);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "trigger setup failed\n");
 		return ret;
@@ -523,7 +523,7 @@ static int hid_magn_3d_probe(struct platform_device *pdev)
 	magn_state->callbacks.capture_sample = magn_3d_capture_sample;
 	magn_state->callbacks.pdev = pdev;
 	ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_COMPASS_3D,
-					&magn_state->callbacks);
+					   &magn_state->callbacks);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "callback reg failed\n");
 		goto error_iio_unreg;

-- 
2.34.1

[PATCH 05/11] iio: humidity: hid-sensor-humidity: use common device for devres

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

kmemdup() is used for memory that is logically tied to the HID
platform device, even though the driver binds into the IIO framework.

Using &indio_dev->dev for devres allocations works functionally, but it
results in two separate devres ownership trees—one for the HID
platform device (pdev) and another for the IIO device (indio_dev).

The devres framework is intended to have a single, well-defined parent
device. Since the memory originates from HID sensor probing and is not
IIO-specific, &pdev->dev is the correct and logical owner.

Switch to using the platform device for devm_kmemdup() so that all
resources are released deterministically and consistently.

Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
Tested-by: Zhang Lixu <lixu.zhang@intel.com>
---
 drivers/iio/humidity/hid-sensor-humidity.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
index 6fed019f4099..73120b87d641 100644
--- a/drivers/iio/humidity/hid-sensor-humidity.c
+++ b/drivers/iio/humidity/hid-sensor-humidity.c
@@ -215,7 +215,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	humid_chans = devm_kmemdup(&indio_dev->dev, humidity_channels,
+	humid_chans = devm_kmemdup(&pdev->dev, humidity_channels,
 				   sizeof(humidity_channels), GFP_KERNEL);
 	if (!humid_chans)
 		return -ENOMEM;

-- 
2.34.1

[PATCH 06/11] iio: position: hid-sensor-custom-intel-hinge: use common device for devres

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

kmemdup() is used for memory that is logically tied to the HID
platform device, even though the driver binds into the IIO framework.

Using &indio_dev->dev for devres allocations works functionally, but it
results in two separate devres ownership trees—one for the HID
platform device (pdev) and another for the IIO device (indio_dev).

The devres framework is intended to have a single, well-defined parent
device. Since the memory originates from HID sensor probing and is not
IIO-specific, &pdev->dev is the correct and logical owner.

Switch to using the platform device for devm_kmemdup() so that all
resources are released deterministically and consistently.

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

diff --git a/drivers/iio/position/hid-sensor-custom-intel-hinge.c b/drivers/iio/position/hid-sensor-custom-intel-hinge.c
index a26d391661fd..0ba9d2d43913 100644
--- a/drivers/iio/position/hid-sensor-custom-intel-hinge.c
+++ b/drivers/iio/position/hid-sensor-custom-intel-hinge.c
@@ -292,7 +292,7 @@ static int hid_hinge_probe(struct platform_device *pdev)
 	}
 
 	indio_dev->num_channels = ARRAY_SIZE(hinge_channels);
-	indio_dev->channels = devm_kmemdup(&indio_dev->dev, hinge_channels,
+	indio_dev->channels = devm_kmemdup(&pdev->dev, hinge_channels,
 					   sizeof(hinge_channels), GFP_KERNEL);
 	if (!indio_dev->channels)
 		return -ENOMEM;

-- 
2.34.1

[PATCH 07/11] iio: temperature: hid-sensor-temperature: use common device for devres

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

kmemdup() is used for memory that is logically tied to the HID
platform device, even though the driver binds into the IIO framework.

Using &indio_dev->dev for devres allocations works functionally, but it
results in two separate devres ownership trees—one for the HID
platform device (pdev) and another for the IIO device (indio_dev).

The devres framework is intended to have a single, well-defined parent
device. Since the memory originates from HID sensor probing and is not
IIO-specific, &pdev->dev is the correct and logical owner.

Switch to using the platform device for devm_kmemdup() so that all
resources are released deterministically and consistently.

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

diff --git a/drivers/iio/temperature/hid-sensor-temperature.c b/drivers/iio/temperature/hid-sensor-temperature.c
index 9f628a8e5cfb..31ebfd1a1fe2 100644
--- a/drivers/iio/temperature/hid-sensor-temperature.c
+++ b/drivers/iio/temperature/hid-sensor-temperature.c
@@ -213,8 +213,8 @@ static int hid_temperature_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	temp_chans = devm_kmemdup(&indio_dev->dev, temperature_channels,
-				sizeof(temperature_channels), GFP_KERNEL);
+	temp_chans = devm_kmemdup(&pdev->dev, temperature_channels,
+				  sizeof(temperature_channels), GFP_KERNEL);
 	if (!temp_chans)
 		return -ENOMEM;
 

-- 
2.34.1

[PATCH 08/11] iio: hid-sensor-magn-3d: use ! instead of explicit NULL check

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

Replace 'if (indio_dev == NULL)' with 'if (!indio_dev)' in to follow
the preferred kernel style.

No functional change.

Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
 drivers/iio/magnetometer/hid-sensor-magn-3d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index 82507297c55b..8f7a0b2bd795 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -467,7 +467,7 @@ static int hid_magn_3d_probe(struct platform_device *pdev)
 
 	indio_dev = devm_iio_device_alloc(&pdev->dev,
 					  sizeof(struct magn_3d_state));
-	if (indio_dev == NULL)
+	if (!indio_dev)
 		return -ENOMEM;
 
 	platform_set_drvdata(pdev, indio_dev);

-- 
2.34.1

[PATCH 09/11] iio: hid-sensor-rotation: use ! instead of explicit NULL check

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

Replace 'if (indio_dev == NULL)' with 'if (!indio_dev)' in to follow
the preferred kernel style.

No functional change.

Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
 drivers/iio/orientation/hid-sensor-rotation.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/orientation/hid-sensor-rotation.c b/drivers/iio/orientation/hid-sensor-rotation.c
index 20563d8efaf6..fc925ec12d37 100644
--- a/drivers/iio/orientation/hid-sensor-rotation.c
+++ b/drivers/iio/orientation/hid-sensor-rotation.c
@@ -278,7 +278,7 @@ static int hid_dev_rot_probe(struct platform_device *pdev)
 
 	indio_dev = devm_iio_device_alloc(&pdev->dev,
 					  sizeof(struct dev_rot_state));
-	if (indio_dev == NULL)
+	if (!indio_dev)
 		return -ENOMEM;
 
 	platform_set_drvdata(pdev, indio_dev);

-- 
2.34.1

[PATCH 10/11] iio: hid-sensor-incl-3d: use ! instead of explicit NULL check

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

Replace 'if (indio_dev == NULL)' with 'if (!indio_dev)' in to follow
the preferred kernel style.

No functional change.

Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
 drivers/iio/orientation/hid-sensor-incl-3d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/orientation/hid-sensor-incl-3d.c b/drivers/iio/orientation/hid-sensor-incl-3d.c
index c7fbff498be7..4c4b0ef2e01c 100644
--- a/drivers/iio/orientation/hid-sensor-incl-3d.c
+++ b/drivers/iio/orientation/hid-sensor-incl-3d.c
@@ -307,7 +307,7 @@ static int hid_incl_3d_probe(struct platform_device *pdev)
 
 	indio_dev = devm_iio_device_alloc(&pdev->dev,
 					  sizeof(struct incl_3d_state));
-	if (indio_dev == NULL)
+	if (!indio_dev)
 		return -ENOMEM;
 
 	platform_set_drvdata(pdev, indio_dev);

-- 
2.34.1

Re: [PATCH 03/11] iio: gyro: hid-sensor-gyro-3d: align parenthesis for readability

[Andy Shevchenko]

On Tue, Jun 16, 2026 at 03:56:08PM +0530, Sanjay Chitroda wrote:

> Adjust alignment of parentheses to improve readability and
> maintain consistency with kernel coding style

Respect English grammar and punctuation.

...

>  /* Channel write_raw handler */
>  static int gyro_3d_write_raw(struct iio_dev *indio_dev,
> -			       struct iio_chan_spec const *chan,
> -			       int val,
> -			       int val2,
> -			       long mask)
> +			     struct iio_chan_spec const *chan,
> +			     int val,
> +			     int val2,
> +			     long mask)

In cases like this have a chance to (re-)split logically.

static int gyro_3d_write_raw(struct iio_dev *indio_dev,
			     struct iio_chan_spec const *chan,
			     int val, int val2, long mask)

...

These comments for the entire series.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 02/11] iio: humidity: hid-sensor-humidity: align parenthesis for readability

[Andy Shevchenko]

On Tue, Jun 16, 2026 at 03:56:07PM +0530, Sanjay Chitroda wrote:

> Adjust alignment of parentheses to improve readability and
> maintain consistency with kernel coding style

Same comment about punctuation.

...

>  /* 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)
> +			       unsigned int usage_id, void *pdev)

Shouldn't usage_id be u32 to begin with? Can you check what's going on there?
(It used to be a change to implement that, maybe it was not comprehensive one and
 needs a part 2?)

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 08/11] iio: hid-sensor-magn-3d: use ! instead of explicit NULL check

[Joshua Crofts]

On Tue, 16 Jun 2026 15:56:13 +0530
Sanjay Chitroda <sanjayembeddedse@gmail.com> wrote:

> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> 
> Replace 'if (indio_dev == NULL)' with 'if (!indio_dev)' in to follow
> the preferred kernel style.
> 
> No functional change.
> 
> Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> ---

Couldn't all of these null check patches be squashed into one,
considering these are all the same logical change and affect
HID drivers? Surely this is code churn a bit.

Same goes for the parentheses alignment patches.

--
Kind regards

CJD

[PATCH 11/11] iio: hid-sensor-accel-3d: use ! instead of explicit NULL check

[Sanjay Chitroda]

From: Sanjay Chitroda <sanjayembeddedse@gmail.com>

Replace 'if (indio_dev == NULL)' with 'if (!indio_dev)' in to follow
the preferred kernel style.

No functional change.

Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
---
 drivers/iio/accel/hid-sensor-accel-3d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
index 42c4259bf209..0999f7dbf434 100644
--- a/drivers/iio/accel/hid-sensor-accel-3d.c
+++ b/drivers/iio/accel/hid-sensor-accel-3d.c
@@ -329,7 +329,7 @@ static int hid_accel_3d_probe(struct platform_device *pdev)
 
 	indio_dev = devm_iio_device_alloc(&pdev->dev,
 					  sizeof(struct accel_3d_state));
-	if (indio_dev == NULL)
+	if (!indio_dev)
 		return -ENOMEM;
 
 	platform_set_drvdata(pdev, indio_dev);

-- 
2.34.1

Re: [PATCH 04/11] iio: magnetometer: hid-sensor-magn-3d: align parenthesis for readability

[sashiko-bot]

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

Pre-existing issues:
- [High] Blindly reading 32 or 64 bits from `raw_data` without verifying `raw_len` can lead to slab-out-of-bounds reads.
--

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

iio: magnetometer: hid-sensor-magn-3d: align parenthesis for readability

This commit adjusts the alignment of parentheses across multiple functions in
the hid-sensor-magn-3d driver. This improves readability and maintains
consistency with the kernel coding style.

> diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> index 23884825eb00f..82507297c55bb 100644
> --- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> +++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c

[ ... ]

> @@ -292,9 +291,9 @@ static int magn_3d_proc_event(struct hid_sensor_hub_device *hsdev,
>  
>  /* Capture samples in local storage */
>  static int magn_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
> -				u32 usage_id,
> -				size_t raw_len, char *raw_data,
> -				void *priv)
> +				  u32 usage_id,
> +				  size_t raw_len, char *raw_data,
> +				  void *priv)
>  {
>  	struct iio_dev *indio_dev = platform_get_drvdata(priv);
>  	struct magn_3d_state *magn_state = iio_priv(indio_dev);

[Severity: High]
This is a pre-existing issue, but since this patch touches the signature of
magn_3d_capture_sample(), could we be at risk of a slab out-of-bounds read
further down in the function?

If a device presents a crafted HID report descriptor that defines the
HID_USAGE_SENSOR_TIME_TIMESTAMP field with a smaller size, it could result in
raw_len being less than 8.  Reading 8 bytes from raw_data in this case:

	case HID_USAGE_SENSOR_TIME_TIMESTAMP:
		magn_state->timestamp =
			hid_sensor_convert_timestamp(&magn_state->magn_flux_attributes,
						     *(s64 *)raw_data);

would read past the end of the buffer.

A similar dereference happens later in the function for the magnetic axes
where 4 bytes are read:

	iio_val = magn_state->magn_val_addr[offset];

	if (iio_val != NULL)
		*iio_val = *((u32 *)raw_data);

Could this also trigger an out-of-bounds read if raw_len is smaller than 4?
Should we verify the size of raw_len before making these casts?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com?part=4

Re: [PATCH 01/11] iio: hid-sensors: add missing blank line after declarations

[sashiko-bot]

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

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but pending asynchronous suspend work is cancelled during device removal, leaving hardware powered on indefinitely.
--

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

iio: hid-sensors: add missing blank line after declarations

Add a blank line after variable declarations to improve
readability and align with kernel coding style.

> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> index 417c4ab8c1b27..c8ccf96f3d035 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> @@ -314,7 +314,9 @@ static int __maybe_unused hid_sensor_resume(struct device *dev)
>  {
>  	struct iio_dev *indio_dev = dev_get_drvdata(dev);
>  	struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
> +
>  	schedule_work(&attrb->work);
> +
>  	return 0;
>  }

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem where
pending asynchronous suspend work might be cancelled during device removal,
leaving the hardware powered on indefinitely.

During driver removal, iio_device_unregister() disables active iio buffers,
triggering buffer_predisable(). This calls hid_sensor_power_state() with
state false, which queues an asynchronous suspend:

hid_sensor_power_state() {
	...
	} else {
		atomic_dec(&st->user_requested_state);
		pm_runtime_use_autosuspend(&st->pdev->dev);
		ret = pm_runtime_put_autosuspend(&st->pdev->dev);
	}
	...
}

Immediately after, hid_sensor_remove_trigger() is called:

hid_sensor_remove_trigger() {
	if (atomic_read(&attrb->runtime_pm_enable))
		pm_runtime_disable(&attrb->pdev->dev);

	pm_runtime_set_suspended(&attrb->pdev->dev);
	...
}

Because pm_runtime_disable() cancels any pending asynchronous idle/suspend
work, is it possible the autosuspend work gets cancelled before execution?

If the work is cancelled, pm_runtime_set_suspended() would only update the
software pm state, leaving the actual physical hardware permanently powered
on. Does the driver need a synchronous suspend in the removal path before
disabling runtime pm?

>  
> @@ -322,6 +324,7 @@ static int __maybe_unused hid_sensor_runtime_resume(struct device *dev)
>  {
>  	struct iio_dev *indio_dev = dev_get_drvdata(dev);
>  	struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
> +
>  	return _hid_sensor_power_state(attrb, true);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com?part=1

Re: [PATCH 02/11] iio: humidity: hid-sensor-humidity: align parenthesis for readability

[sashiko-bot]

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

Pre-existing issues:
- [High] Global state corruption due to shared static `humidity_callbacks` struct
- [High] Out-of-bounds read and unaligned memory access in `humidity_capture_sample()`
- [High] Possible list corruption and use-after-free during device removal
--

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

iio: humidity: hid-sensor-humidity: align parenthesis for readability

Adjust alignment of parentheses to improve readability and
maintain consistency with kernel coding style

> diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
> index be2338d5f4070..6fed019f4099f 100644
> --- a/drivers/iio/humidity/hid-sensor-humidity.c
> +++ b/drivers/iio/humidity/hid-sensor-humidity.c
[ ... ]
> @@ -141,8 +141,8 @@ 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,
> -				char *raw_data, void *pdev)
> +				   unsigned int usage_id, size_t raw_len,
> +				   char *raw_data, void *pdev)

[Severity: High]
This is a pre-existing issue, but is there a potential out-of-bounds read
and unaligned memory access here?

The HID sensor hub core invokes humidity_capture_sample() with raw_data
pointing to a field within a raw byte report buffer, and raw_len specifying
its exact byte size:

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

		return 0;
    ...
}

The driver unconditionally casts raw_data to a 32-bit integer pointer and
performs a 4-byte read. If raw_len is less than 4 (e.g., 1 or 2 bytes) and
the field resides at the end of the report buffer, does this result in an
out-of-bounds memory read?

Additionally, since HID reports are byte-packed, raw_data is not guaranteed
to be 32-bit aligned. Could an unaligned 32-bit read trigger a kernel panic
on architectures that strictly enforce alignment (e.g., ARMv5, SPARC)?

>  {
>  	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>  	struct hid_humidity_state *humid_st = iio_priv(indio_dev);
[ ... ]
> @@ -234,7 +234,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
>  	atomic_set(&humid_st->common_attributes.data_ready, 0);
>  
>  	ret = hid_sensor_setup_trigger(indio_dev, name,
> -				&humid_st->common_attributes);
> +				       &humid_st->common_attributes);
>  	if (ret)
>  		return ret;
>  
> @@ -242,7 +242,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
>  
>  	humidity_callbacks.pdev = pdev;
>  	ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_HUMIDITY,
> -					&humidity_callbacks);

[Severity: High]
This isn't a bug introduced by this patch, but could this cause global state
corruption?

The humidity_callbacks struct is defined statically at the file scope. Here,
during hid_humidity_probe(), its pdev field is overwritten with the
instance-specific pdev.

The HID core (sensor_hub_register_callback()) stores the pointer to this
shared struct rather than copying its contents. If multiple humidity sensors
are probed, the global pdev will be overwritten by the last probed instance.

When sensor_hub_raw_event() processes an event, does it access callback->pdev
and erroneously route events from all connected sensors to the IIO device of
the last probed sensor, potentially causing data corruption or a
Use-After-Free if that device is later unbound?

> +					   &humidity_callbacks);
>  	if (ret)
>  		goto error_remove_trigger;
>  

[Severity: High]
This is a pre-existing issue, but is there a possible list corruption and
use-after-free during device removal?

In hid_humidity_remove(), iio_device_unregister() is called before
sensor_hub_remove_callback(). This allows the HID sensor hub to continue
dispatching hardware events via the active callback while the IIO device is
being concurrently torn down.

When an event arrives, humidity_proc_event() checks the data_ready atomic
variable. Since this is an unlocked Time-Of-Check to Time-Of-Use race,
could data_ready be read as non-zero right before iio_device_unregister()
disables the trigger and clears it?

humidity_proc_event() then calls iio_push_to_buffers_with_timestamp(),
which iterates over the IIO buffer_list without taking locks.

Concurrently, iio_device_unregister() calls iio_disable_all_buffers()
which calls list_del_init() on the buffers. Does traversing a list
concurrently while elements are being removed and reinitialized cause
infinite loops or Use-After-Free crashes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com?part=2

Re: [PATCH 07/11] iio: temperature: hid-sensor-temperature: use common device for devres

[sashiko-bot]

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

Pre-existing issues:
- [High] Use-After-Free of IIO channels array when in-kernel consumers hold references past driver unbind.
- [High] State corruption due to overwriting a static global callbacks structure during probe.
--

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

iio: temperature: hid-sensor-temperature: use common device for devres

This commit updates hid-sensor-temperature to allocate memory using the
platform device instead of the IIO device. This unifies devres ownership
under the platform device for deterministic resource release.

> diff --git a/drivers/iio/temperature/hid-sensor-temperature.c b/drivers/iio/temperature/hid-sensor-temperature.c
> index 9f628a8e5cfbe..31ebfd1a1fe2c 100644
> --- a/drivers/iio/temperature/hid-sensor-temperature.c
> +++ b/drivers/iio/temperature/hid-sensor-temperature.c
> @@ -213,8 +213,8 @@ static int hid_temperature_probe(struct platform_device *pdev)
>  	if (ret)
>  		return ret;
>  
> -	temp_chans = devm_kmemdup(&indio_dev->dev, temperature_channels,
> -				sizeof(temperature_channels), GFP_KERNEL);
> +	temp_chans = devm_kmemdup(&pdev->dev, temperature_channels,
> +				  sizeof(temperature_channels), GFP_KERNEL);

[Severity: High]
This isn't a bug introduced by this patch, but does using devm_kmemdup()
for the IIO channels array tie its lifecycle to driver unbind rather than
the IIO device's reference-counted lifecycle?

If an in-kernel consumer holds a reference to the IIO device after the
provider driver unbinds, the consumer might access the freed channels array
through its cached iio_channel pointer (e.g., via
iio_read_channel_ext_info(), which does not check if indio_dev->info was
cleared).

Could this lead to a use-after-free? Would it be safer to make the
channels array part of the iio_priv structure so it lives as long as the
indio_dev itself?

>  	if (!temp_chans)
>  		return -ENOMEM;

[Severity: High]
This is a pre-existing issue, but looking further down in
hid_temperature_probe(), is it safe to assign pdev to a global static
callbacks structure?

hid_temperature_probe() {
    ...
    temperature_callbacks.pdev = pdev;
    ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_TEMPERATURE,
                    &temperature_callbacks);
    ...
}

If a system contains multiple HID temperature sensors, would probing a
second sensor overwrite the pdev pointer with the new device instance?

When the sensor hub receives an event for the first sensor, it might fire
the callback using the pdev of the second sensor, pushing data into the
wrong device's buffer.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com?part=7

Re: [PATCH 05/11] iio: humidity: hid-sensor-humidity: use common device for devres

[sashiko-bot]

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

New issues:
- [High] Changing the devm allocation parent from the IIO device to the platform device creates a dangling pointer, as the IIO device can outlive the platform device.

Pre-existing issues:
- [High] The driver shares a single static global `struct hid_sensor_hub_callbacks humidity_callbacks` which is overwritten by each probed device, causing data corruption and Use-After-Free.
--

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

iio: humidity: hid-sensor-humidity: use common device for devres

This patch changes the devres allocation parent for the humidity channels
array. It moves the ownership from the IIO device to the HID platform
device to consolidate the devres ownership tree.

> diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
> index 6fed019f4099f..73120b87d641d 100644
> --- a/drivers/iio/humidity/hid-sensor-humidity.c
> +++ b/drivers/iio/humidity/hid-sensor-humidity.c
> @@ -215,7 +215,7 @@ static int hid_humidity_probe(struct platform_device *pdev)
>  	if (ret)
>  		return ret;
>  
> -	humid_chans = devm_kmemdup(&indio_dev->dev, humidity_channels,
> +	humid_chans = devm_kmemdup(&pdev->dev, humidity_channels,
>  				   sizeof(humidity_channels), GFP_KERNEL);

[Severity: High]
Does changing the devm allocation parent to the platform device create a
dangling pointer here?

In the IIO subsystem, the iio_dev object is reference-counted and can outlive
the platform device if userspace holds open file descriptors (for example,
/dev/iio:deviceX). Devres resources attached to pdev->dev are freed
unconditionally when the driver unbinds, but resources attached to
indio_dev->dev live until the iio_dev reference count drops to zero.

By moving the allocation of humidity_channels to pdev->dev, won't
indio_dev->channels point to freed memory immediately after unbind, leading
to a use-after-free if the IIO core or userspace continues to interact with
the still-alive iio_dev?

>  	if (!humid_chans)
>  		return -ENOMEM;

[ ... ]

While looking at hid_humidity_probe(), I noticed another detail:

drivers/iio/humidity/hid-sensor-humidity.c:hid_humidity_probe() {
	...
	humidity_callbacks.pdev = pdev;
	ret = sensor_hub_register_callback(hsdev, HID_USAGE_SENSOR_HUMIDITY,
					   &humidity_callbacks);
	...
}

[Severity: High]
This is a pre-existing issue, but does assigning the local platform device to
the globally shared humidity_callbacks structure cause state corruption?

If a system has multiple humidity sensors probed, it appears the pdev of the
last probed sensor overwrites the pointer for all previous instances.

When sensor_hub_raw_event() dispatches an event for an earlier sensor, it
calls callback->capture_sample() with the overwritten pdev. Could this
corrupt the state of the newer sensor, or cause a use-after-free if the
newer sensor is unbound while the older one remains active?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-15-jun-hid-iio-alignment-v1-0-0cd544286575@gmail.com?part=5