* Re: [PATCH v4 1/6] iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
From: sashiko-bot @ 2026-05-20 0:04 UTC (permalink / raw)
To: Natália Salvino André; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260519234752.23911-2-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces a compilation error by using a non-existent field `.format` instead of `.sign` in the initialization of `struct iio_scan_type`.
--
commit 5d0645bc673099b585d567599624c53910242efc
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
Clean up the channel initialization loop and replace the local
accel_3d_adjust_channel_bit_mask() function with a compound literal
to improve code readability.
> diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
> index 2ff591b3458f7..2bf05ab5235ef 100644
> --- a/drivers/iio/accel/hid-sensor-accel-3d.c
> +++ b/drivers/iio/accel/hid-sensor-accel-3d.c
[ ... ]
> @@ -297,19 +287,20 @@ static int accel_3d_parse_report(struct platform_device *pdev,
> struct accel_3d_state *st)
> {
> int ret;
> - int i;
>
> - for (i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
> + 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_ACCEL_X_AXIS + i,
> - &st->accel[CHANNEL_SCAN_INDEX_X + i]);
> + HID_USAGE_SENSOR_ACCEL_X_AXIS + ch,
> + &st->accel[ch]);
> if (ret < 0)
> break;
> - accel_3d_adjust_channel_bit_mask(channels,
> - CHANNEL_SCAN_INDEX_X + i,
> - st->accel[CHANNEL_SCAN_INDEX_X + i].size);
> + channels[ch].scan_type = (struct iio_scan_type) {
> + .format = 's',
[Severity: Low]
Does this code result in a compilation error? Looking at struct iio_scan_type
defined in include/linux/iio/iio.h, it contains a sign member but no format
member. Should this be .sign = 's' instead?
> + .realbits = BYTES_TO_BITS(st->accel[ch].size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260519234752.23911-1-natalia.andre@ime.usp.br?part=1
^ permalink raw reply
* [PATCH v4 6/6] iio: pressure: HID: hid-sensor-press: Refactor channel initialization
From: Natália Salvino André @ 2026-05-19 23:40 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260519234752.23911-1-natalia.andre@ime.usp.br>
Replace the local press_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/pressure/hid-sensor-press.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/pressure/hid-sensor-press.c b/drivers/iio/pressure/hid-sensor-press.c
index 5f1d6abda3e4..a039b99d9851 100644
--- a/drivers/iio/pressure/hid-sensor-press.c
+++ b/drivers/iio/pressure/hid-sensor-press.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2014, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -53,17 +54,6 @@ static const struct iio_chan_spec press_channels[] = {
};
-/* Adjust channel real bits based on report descriptor */
-static void press_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int press_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -225,8 +215,11 @@ static int press_parse_report(struct platform_device *pdev,
&st->press_attr);
if (ret < 0)
return ret;
- press_adjust_channel_bit_mask(channels, CHANNEL_SCAN_INDEX_PRESSURE,
- st->press_attr.size);
+ channels[CHANNEL_SCAN_INDEX_PRESSURE].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->press_attr.size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
dev_dbg(&pdev->dev, "press %x:%x\n", st->press_attr.index,
st->press_attr.report_id);
--
2.51.0
^ permalink raw reply related
* [PATCH v4 5/6] iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel initialization
From: Natália Salvino André @ 2026-05-19 23:40 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260519234752.23911-1-natalia.andre@ime.usp.br>
Replace the local magn_3d_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 20 ++++++-------------
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index c673f9323e47..3b26dc41dd4c 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -132,17 +133,6 @@ static const struct iio_chan_spec magn_3d_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(7)
};
-/* Adjust channel real bits based on report descriptor */
-static void magn_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int magn_3d_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -418,9 +408,11 @@ static int magn_3d_parse_report(struct platform_device *pdev,
if (i != CHANNEL_SCAN_INDEX_TIMESTAMP) {
/* Set magn_val_addr to iio value address */
st->magn_val_addr[i] = &st->iio_vals[*chan_count];
- magn_3d_adjust_channel_bit_mask(_channels,
- *chan_count,
- st->magn[i].size);
+ _channels[*chan_count].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->magn[i].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
}
(*chan_count)++;
}
--
2.51.0
^ permalink raw reply related
* [PATCH v4 4/6] iio: light: HID: hid-sensor-prox: Refactor channel initialization
From: Natália Salvino André @ 2026-05-19 23:40 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260519234752.23911-1-natalia.andre@ime.usp.br>
Replace the local prox_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/light/hid-sensor-prox.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-prox.c b/drivers/iio/light/hid-sensor-prox.c
index efa904a70d0e..edc9274a2c07 100644
--- a/drivers/iio/light/hid-sensor-prox.c
+++ b/drivers/iio/light/hid-sensor-prox.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2014, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -67,17 +68,6 @@ static const struct iio_chan_spec prox_channels[] = {
PROX_CHANNEL(false, 0),
};
-/* Adjust channel real bits based on report descriptor */
-static void prox_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int prox_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -250,8 +240,11 @@ static int prox_parse_report(struct platform_device *pdev,
st->scan_mask[0] |= BIT(index);
channels[index] = prox_channels[i];
channels[index].scan_index = index;
- prox_adjust_channel_bit_mask(channels, index,
- st->prox_attr[index].size);
+ channels[index].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->prox_attr[index].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
dev_dbg(&pdev->dev, "prox %x:%x\n", st->prox_attr[index].index,
st->prox_attr[index].report_id);
st->scale_precision[index] =
--
2.51.0
^ permalink raw reply related
* [PATCH v4 3/6] iio: light: HID: hid-sensor-als: Refactor channel initialization
From: Natália Salvino André @ 2026-05-19 23:40 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260519234752.23911-1-natalia.andre@ime.usp.br>
Replace the local als_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/light/hid-sensor-als.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
index 384572844162..d72e260b8266 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -117,17 +118,6 @@ static const struct iio_chan_spec als_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
-/* Adjust channel real bits based on report descriptor */
-static void als_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int als_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -335,7 +325,11 @@ static int als_parse_report(struct platform_device *pdev,
channels[index] = als_channels[i];
st->als_scan_mask[0] |= BIT(i);
- als_adjust_channel_bit_mask(channels, index, st->als[i].size);
+ channels[index].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->als[i].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
++index;
dev_dbg(&pdev->dev, "als %x:%x\n", st->als[i].index,
--
2.51.0
^ permalink raw reply related
* [PATCH v4 2/6] iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
From: Natália Salvino André @ 2026-05-19 23:40 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260519234752.23911-1-natalia.andre@ime.usp.br>
Replace the local gyro_3d_adjust_channel_bit_mask() function with a
compound literal for scan_type initialization to improve code
readability. Additionaly, clean up the channel initialization
loop by iterating directly over the channel scan indices.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/gyro/hid-sensor-gyro-3d.c | 27 +++++++++------------------
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c b/drivers/iio/gyro/hid-sensor-gyro-3d.c
index c340cc899a7c..e48c25c87b6d 100644
--- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
+++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -82,17 +83,6 @@ static const struct iio_chan_spec gyro_3d_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
-/* Adjust channel real bits based on report descriptor */
-static void gyro_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int gyro_3d_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -248,19 +238,20 @@ static int gyro_3d_parse_report(struct platform_device *pdev,
struct gyro_3d_state *st)
{
int ret;
- int i;
- for (i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
+ 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 + i,
- &st->gyro[CHANNEL_SCAN_INDEX_X + i]);
+ HID_USAGE_SENSOR_ANGL_VELOCITY_X_AXIS + ch,
+ &st->gyro[ch]);
if (ret < 0)
break;
- gyro_3d_adjust_channel_bit_mask(channels,
- CHANNEL_SCAN_INDEX_X + i,
- st->gyro[CHANNEL_SCAN_INDEX_X + i].size);
+ channels[ch].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->gyro[ch].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
}
dev_dbg(&pdev->dev, "gyro_3d %x:%x, %x:%x, %x:%x\n",
st->gyro[0].index,
--
2.51.0
^ permalink raw reply related
* [PATCH v4 1/6] iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
From: Natália Salvino André @ 2026-05-19 23:40 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, Pietro Di Consolo Gregorio,
linux-iio, linux-input
In-Reply-To: <20260519234752.23911-1-natalia.andre@ime.usp.br>
Clean up the channel initialization loop and replace the local
accel_3d_adjust_channel_bit_mask() function with a compound literal
to improve code readability.
Signed-off-by: Natália Salvino André <natalia.andre@ime.usp.br>
Co-developed-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
Signed-off-by: Pietro Di Consolo Gregorio <pietro.gregorio@usp.br>
---
drivers/iio/accel/hid-sensor-accel-3d.c | 27 +++++++++----------------
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
index 2ff591b3458f..2bf05ab5235e 100644
--- a/drivers/iio/accel/hid-sensor-accel-3d.c
+++ b/drivers/iio/accel/hid-sensor-accel-3d.c
@@ -3,6 +3,7 @@
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
+#include <linux/bitops.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
@@ -119,17 +120,6 @@ static const struct iio_chan_spec gravity_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP),
};
-/* Adjust channel real bits based on report descriptor */
-static void accel_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
- int channel, int size)
-{
- channels[channel].scan_type.sign = 's';
- /* Real storage bits will change based on the report desc. */
- channels[channel].scan_type.realbits = size * 8;
- /* Maximum size of a sample to capture is u32 */
- channels[channel].scan_type.storagebits = sizeof(u32) * 8;
-}
-
/* Channel read_raw handler */
static int accel_3d_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
@@ -297,19 +287,20 @@ static int accel_3d_parse_report(struct platform_device *pdev,
struct accel_3d_state *st)
{
int ret;
- int i;
- for (i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
+ 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_ACCEL_X_AXIS + i,
- &st->accel[CHANNEL_SCAN_INDEX_X + i]);
+ HID_USAGE_SENSOR_ACCEL_X_AXIS + ch,
+ &st->accel[ch]);
if (ret < 0)
break;
- accel_3d_adjust_channel_bit_mask(channels,
- CHANNEL_SCAN_INDEX_X + i,
- st->accel[CHANNEL_SCAN_INDEX_X + i].size);
+ channels[ch].scan_type = (struct iio_scan_type) {
+ .format = 's',
+ .realbits = BYTES_TO_BITS(st->accel[ch].size),
+ .storagebits = BITS_PER_TYPE(u32),
+ };
}
dev_dbg(&pdev->dev, "accel_3d %x:%x, %x:%x, %x:%x\n",
st->accel[0].index,
--
2.51.0
^ permalink raw reply related
* [PATCH v4 0/6] iio: hid-sensor: standardize scan_type initialization
From: Natália Salvino André @ 2026-05-19 23:40 UTC (permalink / raw)
To: andy, dlechner, jic23, jikos, nuno.sa, srinivas.pandruvada
Cc: Natália Salvino André, linux-iio, linux-input
This series refactors the HID sensor drivers to standardize the
initialization of the iio_chan_spec scan_type structure using compound
literals.
This change improves code readability and ensures that all fields of
the scan_type structure are properly zero-initialized, allowing the
removal of local helper functions.
Additionally, the channel initialization loops for hid-sensor-accel-3d
and hid-sensor-gyro-3d were cleaned up to iterate directly over the
scan indices, eliminating redundant index-offset logic.
---
Changes in v4:
- Fixed a bug in the sensor_hub_input_get_attribute_info()
call where passing the raw loop index 'ch' broke the HID report
field lookup in hid-sensor-accel-3d. Restored the proper HID
usage ID offset calculation using HID_USAGE_SENSOR_ACCEL_X_AXIS + ch
- Cleaned up the channel initialization loop to iterate
directly over the scan indices in hid-sensor-gyro-3d for consistency
Changes in v3:
- Dropped the global helper function implementation from
hid-sensor-attributes.c following maintainer feedback.
- Shifted to local refactoring inside the drivers using compound
literals and the macros BYTES_TO_BITS() and BITS_PER_TYPE()
- Refactored the channel initialization loop in hid-sensor-accel-3d to
iterate directly over the scan enums instead of using 0-based
index offsets
- v3 link: https://lore.kernel.org/linux-iio/89a2e6775e3c922a4848a4b4730aab8d32097454.camel@linux.intel.com/T/#t
Changes in v2:
- Modified the helper function to use the BITS_PER_BYTE macro instead of
magic numbers for bit calculations
- Updated the scan_type structure field assignment from '.sign'
to '.format' based on recent subsystem renaming feedback
Natália Salvino André (6):
iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
iio: light: HID: hid-sensor-als: Refactor channel initialization
iio: light: HID: hid-sensor-prox: Refactor channel initialization
iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel
initialization
iio: pressure: HID: hid-sensor-press: Refactor channel initialization
drivers/iio/accel/hid-sensor-accel-3d.c | 27 +++++++------------
drivers/iio/gyro/hid-sensor-gyro-3d.c | 27 +++++++------------
drivers/iio/light/hid-sensor-als.c | 18 +++++--------
drivers/iio/light/hid-sensor-prox.c | 19 +++++--------
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 20 +++++---------
drivers/iio/pressure/hid-sensor-press.c | 19 +++++--------
6 files changed, 42 insertions(+), 88 deletions(-)
--
2.51.0
^ permalink raw reply
* Re: Mismatched product ids for the ASUS ROG RAIKIRI PRO
From: Dmitry Torokhov @ 2026-05-19 21:18 UTC (permalink / raw)
To: Justin Opini; +Cc: linux-input, linux-kernel, torvalds, Luke D. Jones
In-Reply-To: <20260519173800.6765-1-opinijm@provdh.com>
Hi Justin,
On Tue, May 19, 2026 at 01:37:59PM -0400, Justin Opini wrote:
> Hey Dimity,
>
> I had a question on the product id,
> { 0x0b05, 0x1abb, "ASUS ROG RAIKIRI PRO", 0, XTYPE_XBOXONE },
>
> This doesn’t match both my devices so I was wondering if somehow we
> have similar named devices with need for different product ids or if
> there was a mistake in the original commit?
>
> My relevant entries from lsusb are
> Bus 001 Device 002: ID 0b05:1a3c ASUSTek Computer, Inc. ROG RAIKIRI PRO
> Bus 001 Device 003: ID 0b05:1a3c ASUSTek Computer, Inc. ROG RAIKIRI PRO
>
> On my system I have ended up using this udev rule for quite some time
> ACTION=="add", ATTRS{idVendor}=="0b05", ATTRS{idProduct}=="1a3c", GROUP="input", MODE="0660", TAG+="uaccess", TAG+="seat", RUN+="/bin/sh -c 'echo 0b05 1a3c > /sys/bus/usb/drivers/xpad/new_id'"
I am CC-ing Luke who added this VID/PID comboi to double check, but it
looks like there are many variants of this controller using the same
"ROG RAIKIRI PRO" name. For example
https://github.com/atar-axis/xpadneo/issues/612 talks about
0x0b05/0x1abd.
Thanks.
--
Dmitry
^ permalink raw reply
* [syzbot] [fs?] [usb?] [input?] INFO: rcu detected stall in __fsnotify_parent (3)
From: syzbot @ 2026-05-19 20:54 UTC (permalink / raw)
To: amir73il, jack, linux-fsdevel, linux-input, linux-kernel,
linux-usb, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 6916d5703ddf Merge tag 'drm-fixes-2026-05-16' of https://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13437cc8580000
kernel config: https://syzkaller.appspot.com/x/.config?x=59da38148f3a3d24
dashboard link: https://syzkaller.appspot.com/bug?extid=27ce6cc06c1311c152f5
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=123e8596580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/637181391a5c/disk-6916d570.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/bfbefc8a3671/vmlinux-6916d570.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a419831b32a6/bzImage-6916d570.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+27ce6cc06c1311c152f5@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P4963/1:b..l
rcu: (detected by 1, t=10506 jiffies, g=15565, q=1900 ncpus=2)
task:acpid state:R
running task stack:22856 pid:4963 tgid:4963 ppid:1 task_flags:0x400040 flags:0x00080001
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5388 [inline]
__schedule+0x1295/0x67a0 kernel/sched/core.c:7189
preempt_schedule_irq+0x50/0x90 kernel/sched/core.c:7513
irqentry_exit_to_kernel_mode_preempt include/linux/irq-entry-common.h:476 [inline]
irqentry_exit_to_kernel_mode include/linux/irq-entry-common.h:547 [inline]
irqentry_exit+0x205/0x7e0 kernel/entry/common.c:164
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:lock_acquire+0x5e/0x370 kernel/locking/lockdep.c:5872
Code: 05 3b a2 26 12 83 f8 07 0f 87 d9 02 00 00 48 0f a3 05 46 41 f3 0e 0f 82 a4 02 00 00 8b 35 ce 74 f3 0e 85 f6 0f 85 bf 00 00 00 <48> 8b 44 24 30 65 48 2b 05 dd a1 26 12 0f 85 ed 02 00 00 48 83 c4
RSP: 0018:ffffc9000342fb30 EFLAGS: 00000206
RAX: 0000000000000046 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8defcf06 RDI: ffffffff8c1c3a00
RBP: ffffffff8e7e57a0 R08: 0000000086db7919 R09: 0000000000000007
R10: 0000000000000200 R11: 0000000000000000 R12: 0000000000000002
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
rcu_read_lock include/linux/rcupdate.h:838 [inline]
dput.part.0+0x4c/0x570 fs/dcache.c:971
dput+0x1f/0x30 fs/dcache.c:968
__fsnotify_parent+0x694/0xca0 fs/notify/fsnotify.c:242
fsnotify_parent include/linux/fsnotify.h:96 [inline]
fsnotify_path include/linux/fsnotify.h:113 [inline]
fsnotify_file include/linux/fsnotify.h:127 [inline]
fsnotify_file include/linux/fsnotify.h:116 [inline]
fsnotify_access include/linux/fsnotify.h:425 [inline]
vfs_read+0x486/0xb30 fs/read_write.c:578
ksys_read+0x1f8/0x250 fs/read_write.c:717
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x10b/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7feac7fb3407
RSP: 002b:00007ffc6dd51e00 EFLAGS: 00000202
ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 00007feac7f29780 RCX: 00007feac7fb3407
RDX: 0000000000000018 RSI: 00007ffc6dd51e50 RDI: 000000000000000b
RBP: 00007ffc6dd51e50 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000556e2f8031e4
R13: 0000556e4a9f2380 R14: 0000000000000007 R15: 000000000000000b
</TASK>
rcu: rcu_preempt kthread starved for 4298 jiffies! g15565 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:R
running task stack:27992 pid:16 tgid:16 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5388 [inline]
__schedule+0x1295/0x67a0 kernel/sched/core.c:7189
__schedule_loop kernel/sched/core.c:7268 [inline]
schedule+0xdd/0x390 kernel/sched/core.c:7283
schedule_timeout+0x127/0x280 kernel/time/sleep_timeout.c:99
rcu_gp_fqs_loop+0x1a9/0x900 kernel/rcu/tree.c:2095
rcu_gp_kthread+0x179/0x230 kernel/rcu/tree.c:2297
kthread+0x370/0x450 kernel/kthread.c:436
ret_from_fork+0x72b/0xd50 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
rcu: Stack dump where RCU GP kthread last ran:
CPU: 1 UID: 0 PID: 5978 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
RIP: 0010:write_comp_data+0x40/0x90 kernel/kcov.c:246
Code: 02 12 a9 00 01 ff 00 74 1b f6 c4 01 74 07 a9 00 00 ff 00 74 05 c3 cc cc cc cc 8b 87 d4 16 00 00 85 c0 74 f1 8b 87 b0 16 00 00 <83> f8 03 75 e6 48 8b 87 b8 16 00 00 8b bf b4 16 00 00 48 8b 30 48
RSP: 0018:ffffc900024af648 EFLAGS: 00000246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff81fc2bcd
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff88805a5e0000
RBP: ffff8880b8443320 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000003
R13: ffffed1017088665 R14: 0000000000000001 R15: ffff8880b853c5c0
FS: 0000000000000000(0000) GS:ffff88812446d000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8c6e1b56e8 CR3: 0000000059a89000 CR4: 00000000003526f0
Call Trace:
<TASK>
csd_lock_wait kernel/smp.c:342 [inline]
smp_call_function_many_cond+0x5ad/0x1700 kernel/smp.c:892
on_each_cpu_cond_mask+0x40/0x90 kernel/smp.c:1057
__flush_tlb_multi arch/x86/include/asm/paravirt.h:46 [inline]
flush_tlb_multi arch/x86/mm/tlb.c:1361 [inline]
flush_tlb_mm_range+0x45f/0x16f0 arch/x86/mm/tlb.c:1451
tlb_flush arch/x86/include/asm/tlb.h:23 [inline]
tlb_flush_mmu_tlbonly include/asm-generic/tlb.h:509 [inline]
tlb_flush_mmu_tlbonly include/asm-generic/tlb.h:499 [inline]
tlb_flush_mmu mm/mmu_gather.c:423 [inline]
tlb_finish_mmu+0x3fe/0x810 mm/mmu_gather.c:549
exit_mmap+0x454/0xa10 mm/mmap.c:1313
__mmput+0x12a/0x410 kernel/fork.c:1178
mmput+0x67/0x80 kernel/fork.c:1201
exit_mm kernel/exit.c:582 [inline]
do_exit+0x8b2/0x2af0 kernel/exit.c:964
do_group_exit+0xd5/0x2a0 kernel/exit.c:1119
get_signal+0x20ff/0x2210 kernel/signal.c:3037
arch_do_signal_or_restart+0x91/0x7e0 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
exit_to_user_mode_loop+0x8b/0x4f0 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:238 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
do_syscall_64+0x706/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f7a9eb5d68e
Code: Unable to access opcode bytes at 0x7f7a9eb5d664.
RSP: 002b:00007fffdcda5708 EFLAGS: 00000246
ORIG_RAX: 00000000000000e6
RAX: 0000000000000000 RBX: 000055558fc36500 RCX: 00007f7a9eb5d68e
RDX: 00007fffdcda5760 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffdcda58b0
R13: 00007f7a9ee15fac R14: 000000000002bbe6 R15: 00007f7a9ee15fa0
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH 6.18 000/188] 6.18.32-rc1 review
From: Sasha Levin @ 2026-05-19 19:25 UTC (permalink / raw)
To: gregkh
Cc: Sasha Levin, achill, akpm, broonie, conor, f.fainelli, hargar,
jonathanh, linux-kernel, linux, lkft-triage, patches, patches,
pavel, rwarsow, shuah, sr, stable, sudipm.mukherjee, torvalds,
Miguel Ojeda, Jiri Kosina, Benjamin Tissoires, linux-input,
Johan Hovold, Nathan Chancellor
In-Reply-To: <20260516020430.110135-1-ojeda@kernel.org>
On Sat, May 16, 2026 at 04:04:30AM +0200, Miguel Ojeda wrote:
> Via arm32 I see:
>
> drivers/hid/hid-core.c:2050:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
> 2049 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
> | ~~~
> | %zu
> 2050 | report->id, csize, bsize);
> | ^~~~~
>
> It is also reproducible in mainline, though. Cc'ing a few folks...
Nathan's mainline fix (4d3a2a466b8d "HID: core: Fix size_t specifier in
hid_report_raw_event()") has been queued for 6.18.y and 7.0.y.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Add support for newer Bluetooth keyboards
From: Alain Michaud @ 2026-05-19 18:46 UTC (permalink / raw)
To: Filipe Laíns; +Cc: jikos, bentiss, hadess, ogay, linux-input, linux-kernel
In-Reply-To: <64842eb18284bf49ab1e283b0fed1e6bdea7037d.camel@riseup.net>
On Tue, May 19, 2026 at 2:38 PM Filipe Laíns <lains@riseup.net> wrote:
>
> On Tue, 2026-05-12 at 13:22 +0000, Alain Michaud wrote:
> > Add product IDs (PIDs) for several newer Logitech Bluetooth keyboards
> > to the hidpp_devices matching table, enabling full HID++ support for
> > them.
> >
> > The added keyboards are:
> > - Logitech Signature K650 & B2B
> > - Logitech Pebble Keys 2 K380S
> > - Logitech Casa Pop-Up Desk & B2B
> > - Logitech Wave Keys & B2B
> > - Logitech Signature Slim K950 & B2B
> > - Logitech MX Keys S & B2B
> > - Logitech Keys-To-Go 2
> > - Logitech Pop Icon Keys
> > - Logitech MX Keys Mini & B2B
> > - Logitech Signature Slim Solar+ K980 B2B
> > - Logitech Bluetooth Keyboard K250/K251
> > - Logitech Signature Comfort K880 & B2B
>
> Hi Alain,
>
> Did you actually verify the functionality on each device, or did you just update
> the device ID list for new releases?
The later. Not all the functionality may be available across these
devices. However, these will definitely work with the Multi-Platform
feature patch currently under review.
>
> Cheers,
> Filipe Laíns
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Add support for newer Bluetooth keyboards
From: Filipe Laíns @ 2026-05-19 18:38 UTC (permalink / raw)
To: Alain Michaud, jikos, bentiss; +Cc: hadess, ogay, linux-input, linux-kernel
In-Reply-To: <20260512132244.2194556-1-alainmichaud@google.com>
[-- Attachment #1: Type: text/plain, Size: 829 bytes --]
On Tue, 2026-05-12 at 13:22 +0000, Alain Michaud wrote:
> Add product IDs (PIDs) for several newer Logitech Bluetooth keyboards
> to the hidpp_devices matching table, enabling full HID++ support for
> them.
>
> The added keyboards are:
> - Logitech Signature K650 & B2B
> - Logitech Pebble Keys 2 K380S
> - Logitech Casa Pop-Up Desk & B2B
> - Logitech Wave Keys & B2B
> - Logitech Signature Slim K950 & B2B
> - Logitech MX Keys S & B2B
> - Logitech Keys-To-Go 2
> - Logitech Pop Icon Keys
> - Logitech MX Keys Mini & B2B
> - Logitech Signature Slim Solar+ K980 B2B
> - Logitech Bluetooth Keyboard K250/K251
> - Logitech Signature Comfort K880 & B2B
Hi Alain,
Did you actually verify the functionality on each device, or did you just update
the device ID list for new releases?
Cheers,
Filipe Laíns
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Mismatched product ids for the ASUS ROG RAIKIRI PRO
From: Justin Opini @ 2026-05-19 17:37 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, torvalds
In-Reply-To: <Zjb8RrOFLHFSk_Gv@google.com>
Hey Dimity,
I had a question on the product id,
{ 0x0b05, 0x1abb, "ASUS ROG RAIKIRI PRO", 0, XTYPE_XBOXONE },
This doesn’t match both my devices so I was wondering if somehow we have similar named devices with need for different product ids or if there was a mistake in the original commit?
My relevant entries from lsusb are
Bus 001 Device 002: ID 0b05:1a3c ASUSTek Computer, Inc. ROG RAIKIRI PRO
Bus 001 Device 003: ID 0b05:1a3c ASUSTek Computer, Inc. ROG RAIKIRI PRO
On my system I have ended up using this udev rule for quite some time
ACTION=="add", ATTRS{idVendor}=="0b05", ATTRS{idProduct}=="1a3c", GROUP="input", MODE="0660", TAG+="uaccess", TAG+="seat", RUN+="/bin/sh -c 'echo 0b05 1a3c > /sys/bus/usb/drivers/xpad/new_id'"
Regards,
Justin
^ permalink raw reply
* [PATCH v1] HID: i2c-hid-of: Use named initializers for struct i2c_device_id
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-19 16:04 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
This patch doesn't modify the compiled array, only its representation in
source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
this patch is part of a bigger quest to use named initializers for
mainly struct i2c_device_id::driver_data to be able to modify
i2c_device_id. See e.g.
https://lore.kernel.org/all/20260518111203.639603-2-u.kleine-koenig@baylibre.com/
for the details.
This patch here isn't critical for this quest, as this driver doesn't
make use of .driver_data, so apart from the better readability this is
only about consistency with other subsystems.
This is the only i2c driver under drivers/hid, so this is the only patch
needed to adapt the whole subsystem to the new style for initializing
i2c_device_id arrays.
Best regards
Uwe
drivers/hid/i2c-hid/i2c-hid-of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-of.c b/drivers/hid/i2c-hid/i2c-hid-of.c
index 57379b77e977..59393d71ddb9 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of.c
@@ -144,8 +144,8 @@ MODULE_DEVICE_TABLE(of, i2c_hid_of_match);
#endif
static const struct i2c_device_id i2c_hid_of_id_table[] = {
- { "hid" },
- { "hid-over-i2c" },
+ { .name = "hid" },
+ { .name = "hid-over-i2c" },
{ }
};
MODULE_DEVICE_TABLE(i2c, i2c_hid_of_id_table);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Benjamin Tissoires @ 2026-05-19 14:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Lee Jones, Jiri Kosina, Filipe Laíns, Bastien Nocera,
Ping Cheng, Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Icenowy Zheng, linux-input, linux-kernel, greybus-dev,
linux-staging, linux-usb, stable
In-Reply-To: <2026051937-hefty-registry-37b2@gregkh>
On May 19 2026, Greg Kroah-Hartman wrote:
> On Tue, May 19, 2026 at 02:46:13PM +0200, Benjamin Tissoires wrote:
> > On May 19 2026, Lee Jones wrote:
> > > On Tue, 12 May 2026, Lee Jones wrote:
> > >
> > > > On Wed, 06 May 2026, Lee Jones wrote:
> > > >
> > > > > On Mon, 04 May 2026, Benjamin Tissoires wrote:
> > > > >
> > > > > > Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > > > > > bogus memset()") enforced the provided data to be at least the size of
> > > > > > the declared buffer in the report descriptor to prevent a buffer
> > > > > > overflow.
> > > > > >
> > > > > > We only had corner cases of malicious devices exposing the OOM because
> > > > > > in most cases, the buffer provided by the transport layer needs to be
> > > > > > allocated at probe time and is large enough to handle all the possible
> > > > > > reports.
> > > > > >
> > > > > > However, the patch from above, which enforces the spec a little bit more
> > > > > > introduced both regressions for devices not following the spec (not
> > > > > > necesserally malicious), but also a stream of errors for those devices.
> > > > > >
> > > > > > Let's revert to the old behavior by giving more information to HID core
> > > > > > to be able to decide whether it can or not memset the rest of the buffer
> > > > > > to 0 and continue the processing.
> > > > > >
> > > > > > Note that the first commit makes an API change, but the callers are
> > > > > > relatively limited, so it should be fine on its own. The second patch
> > > > > > can't really make the same kind of API change because we have too many
> > > > > > callers in various subsystems. We can switch them one by one to the safe
> > > > > > approach when needed.
> > > > > >
> > > > > > The last 2 patches are small cleanups I initially put together with the
> > > > > > 2 first patches, but they can be applied on their own and don't need to
> > > > > > be pulled in stable like the first 2.
> > > > > >
> > > > > > Cheers,
> > > > > > Benjamin
> > > > > >
> > > > > > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > > > > > ---
> > > > > > Changes in v3:
> > > > > > - fixed ghib -> ghid in greybus
> > > > > > - fixed i386 size_t debug size reported by kernel-bot
> > > > > > - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
> > > > > >
> > > > > > Changes in v2:
> > > > > > - added a small blurb explaining the difference between the safe and the
> > > > > > non safe version of hid_safe_input_report
> > > > > > - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
> > > > > >
> > > > > > ---
> > > > > > Benjamin Tissoires (4):
> > > > > > HID: pass the buffer size to hid_report_raw_event
> > > > > > HID: core: introduce hid_safe_input_report()
> > > > > > HID: multitouch: use __free(kfree) to clean up temporary buffers
> > > > > > HID: wacom: use __free(kfree) to clean up temporary buffers
> > > > > >
> > > > > > drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++--
> > > > > > drivers/hid/hid-core.c | 67 ++++++++++++++++++++++++++++++--------
> > > > > > drivers/hid/hid-gfrm.c | 4 +--
> > > > > > drivers/hid/hid-logitech-hidpp.c | 2 +-
> > > > > > drivers/hid/hid-multitouch.c | 18 ++++------
> > > > > > drivers/hid/hid-primax.c | 2 +-
> > > > > > drivers/hid/hid-vivaldi-common.c | 2 +-
> > > > > > drivers/hid/i2c-hid/i2c-hid-core.c | 7 ++--
> > > > > > drivers/hid/usbhid/hid-core.c | 11 ++++---
> > > > > > drivers/hid/wacom_sys.c | 46 +++++++++-----------------
> > > > > > drivers/staging/greybus/hid.c | 2 +-
> > > > > > include/linux/hid.h | 6 ++--
> > > > > > include/linux/hid_bpf.h | 14 +++++---
> > > > > > 13 files changed, 109 insertions(+), 78 deletions(-)
> > > > >
> > > > > What's the plan for this set Benjamin? -rcs or -next?
> > > >
> > > > Are there any updates on this set please?
> > > >
> > > > FYI, this set is still important to us.
> > > >
> > > > Ideally, if all is well, it would go into the -rcs for v7.1.
> > >
> > > I'm still actively tracking these.
> > >
> > > It looks like Mark has been reverting them from -next and I'm getting
> > > complaints from the Stable folks that they are causing build errors.
> > >
> > > drivers/hid/hid-core.c: In function 'hid_safe_input_report':
> > > drivers/hid/hid-core.c:2195:16: error: too many arguments to function '__hid_input_report'
> > > 2195 | return __hid_input_report(hid, type, data, bufsize, size, interrupt, 0,
> > >
> > > Are you folks still working on this set?
> >
> > Well, everything is in Linus' tree:
> >
> > not yet in a released rc (taken yesterday by Linus directly):
> >
> > 4d3a2a466b8d HID: core: Fix size_t specifier in hid_report_raw_event()
> >
> > Already in 7.1-rc4:
> >
> > 206342541fc8 HID: core: introduce hid_safe_input_report()
> > 2c85c61d1332 HID: pass the buffer size to hid_report_raw_event
> >
> > Not sure why the patches don't apply to stable, but from an upstream
> > subsystem point of view, everything is in order.
>
> We dropped them from stable because of the build breakage :(
>
If that was just the i386 size_t issue, then it has been fixed in Linus'
tree. Could you try retaking them? Please?
Cheers,
Benjamin
^ permalink raw reply
* Re: [BUG] ALSA: usb-audio: use-after-free in snd_dualsense_ih_match during rapid USB reconnect
From: Takashi Iwai @ 2026-05-19 13:44 UTC (permalink / raw)
To: Sean Brar
Cc: linux-input, linux-sound, roderick.colenbrander, jikos, bentiss,
perex, tiwai
In-Reply-To: <909876aa-7498-4ca4-b3a6-6618fbc6209d@seanbrar.com>
On Mon, 11 May 2026 23:58:30 +0200,
Sean Brar wrote:
>
> A rapid USB disconnect/reconnect cycle on a DualSense controller
> (054c:0ce6) triggers a use-after-free in snd_dualsense_ih_match()
> (sound/usb/mixer_quirks.c), resulting in a general protection fault
> and leaving the USB subsystem in an unrecoverable state requiring a
> hard reboot.
>
> Kernel version: 7.0.5-arch1-1 (also reproduced the trigger on
> 7.0.3-arch1-2; affected code in sound/usb/mixer_quirks.c is
> unchanged on current mainline)
>
> Hardware:
> - Sony DualSense Wireless Controller (054c:0ce6, bcdDevice=1.00)
> - hw_version=0x00000711, fw_version=0x0110002a
> - Host: Gigabyte B550 AORUS PRO AC, BIOS F17 03/22/2024
>
> Trigger condition:
>
> When connected to a degraded USB port (intermittent electrical
> contact), the DualSense enters a rapid disconnect/reconnect cycle.
> snd_usb_audio times out (ETIMEDOUT, -110) querying mixer controls
> during probe, each timeout triggers a USB reset, and the device
> reconnects every 1–2 seconds. This is not a driver bug, it's the
> expected kernel behavior when USB communication is unreliable, but
> it creates a race window for the use-after-free described below.
>
> The bug:
>
> In sound/usb/mixer_quirks.c, snd_dualsense_ih_match() is invoked as
> an input handler match callback from input_register_device() during
> ps_probe() (hid_playstation). At line 575, it obtains a pointer to
> the USB device struct:
>
> snd_dev = mei->info.head.mixer->chip->dev;
>
> It then uses this pointer in dev_warn() calls at lines 579 and 585:
>
> dev_warn(&snd_dev->dev, "Failed to get input dev path\n");
> dev_warn(&snd_dev->dev, "Failed to get USB dev path\n");
>
> No reference is taken on snd_dev. If the USB device is concurrently
> disconnected and freed while snd_dualsense_ih_match() is executing,
> snd_dev becomes a dangling pointer. The dev_warn() call dereferences
> snd_dev->dev.kobj.name via dev_vprintk_emit() → strnlen(), faulting
> on the freed memory.
>
> The OOPS offset (snd_dualsense_ih_match.cold+0xf/0x2b) corresponds
> to the first dev_warn() at line 579. The compiler placed both error
> branches in a cold section, and the offset is consistent with the
> earlier branch.
>
> OOPS:
>
> Oops: general protection fault, probably for non-canonical address
> 0x441f0ffa1e0ff3: 0000 [#1] SMP NOPTI
> CPU: 14 UID: 0 PID: 108 Comm: kworker/14:0 Not tainted 7.0.5-arch1-1
> #1 PREEMPT(full)
> Hardware name: Gigabyte Technology Co., Ltd. B550 AORUS PRO AC/B550
> AORUS PRO AC, BIOS F17 03/22/2024
> Workqueue: usb_hub_wq hub_event
> RIP: 0010:strnlen+0x29/0x40
> RSP: 0018:ffffce3f40537378 EFLAGS: 00010202
> RAX: 00441f0ffa1e0ff3 RBX: 00441f0ffa1e0ff3 RCX: 0000000000000000
> RDX: 00441f0ffa1e1003 RSI: 0000000000000010 RDI: 00441f0ffa1e0ff3
> RBP: ffffce3f40537408 R08: 0000000000000000 R09: ffffce3f40537478
> R10: 0000000000000004 R11: ffffffffc20ebe12 R12: ffff8943511c80b0
> R13: ffff8943511c80b0 R14: ffff894345daf028 R15: ffffce3f40537418
> FS: 0000000000000000(0000) GS:ffff8962144e7000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055e7f9dc3c18 CR3: 0000000135ffe000 CR4: 0000000000f50ef0
>
> Stack trace:
>
> Call Trace:
> <TASK>
> dev_vprintk_emit+0x70/0x1b0
> dev_printk_emit+0x61/0x7b
> __dev_printk+0x2d/0x70
> _dev_warn+0x7f/0x99
> snd_dualsense_ih_match.cold+0xf/0x2b [snd_usb_audio
> a3e71fdbdb8c7ccfdfdb57dadc854b1d1e18445c]
> input_attach_handler.isra.0+0x4b/0xa0
> input_register_device.cold+0xf8/0x1f0
> ps_probe+0xf79/0x10dc [hid_playstation
> 0cc5feea5231aa914fe418c8a06b14588cd5f064]
> hid_device_probe+0x1b8/0x270
> hid_add_device+0xcd/0x130
> usbhid_probe+0x49b/0x6c0
> usb_probe_interface+0xf8/0x2f0
> usb_set_configuration+0x738/0x920
> usb_generic_driver_probe+0x4a/0x70
> usb_probe_device+0x44/0x170
> usb_new_device.cold+0x154/0x3fd
> hub_event+0x129d/0x1ad0
> process_one_work+0x19c/0x3a0
> worker_thread+0x1b1/0x310
> kthread+0xe1/0x120
> ret_from_fork+0x2bc/0x350
> ret_from_fork_asm+0x1a/0x30
> </TASK>
> ---[ end trace 0000000000000000 ]---
>
> Analysis:
>
> The race is between two concurrent paths:
>
> 1. Probe: hub_event → usb_new_device → ... → ps_probe →
> input_register_device → input_attach_handler →
> snd_dualsense_ih_match (accesses USB device struct at line 575)
>
> 2. Disconnect: hub_event → usb_disconnect → ... → USB device
> struct freed
>
> snd_dualsense_ih_match() retrieves snd_dev via the mixer→chip→dev
> chain at line 575 without taking a reference. A concurrent disconnect
> can free the USB device struct before the subsequent dev_warn() call
> dereferences it. The faulting RDI value (0x441f0ffa1e0ff3) is
> non-canonical and consistent with SLUB freed-object poisoning,
> confirming a use-after-free.
>
> Impact:
>
> After the OOPS, the USB subsystem is left in an unrecoverable state:
> all USB ports stop enumerating devices (including ports not involved
> in the reconnect cycle), and a clean shutdown hangs in USB driver
> teardown. A hard reset is required. The trigger condition (rapid USB
> reconnection due to a degraded port) is a normal hardware failure
> mode.
>
> Workaround:
>
> # /etc/modprobe.d/dualsense.conf
> options snd_usb_audio ignore_ctl_error=1
>
> This suppresses the mixer control timeouts that drive the reconnect
> cycle, preventing the race window from opening. DualSense headphone
> jack audio controls may not function correctly with this option.
>
> Steps to reproduce:
>
> Disconnect/reconnect loop (the trigger condition):
> 1. Load hid_playstation and snd_usb_audio (default on standard
> desktop kernels)
> 2. Connect a DualSense (054c:0ce6) via USB to a port with
> unreliable electrical contact
> 3. Observe rapid disconnect/reconnect in dmesg -w, with device
> number incrementing each cycle
>
> The OOPS:
> The OOPS was observed after the loop ran for several minutes. Exact
> timing-dependent reproduction beyond triggering the loop is not
> confirmed; this was observed once and not retested to avoid the
> unrecoverable USB hang.
>
> Kernel .config (7.0.5-arch1-1):
> https://gist.github.com/seanbrar/d97a577efc3f48098d300105c4de398b
> dmesg with OOPS (7.0.5-arch1-1):
> https://gist.github.com/seanbrar/994ed882ca6f25b93e4763a8906d0fd5
> dmesg with reconnect loop (7.0.3-arch1-2):
> https://gist.github.com/seanbrar/188a75bf69fffe0d089f7aa82c6aebb6
Thanks for the report.
As this is involved with two individual devices, I wonder the bug is
triggered at which timing -- has the sound interface been already
disconnected (or being disconnected) while the input is being probed?
In such a case, does the change below help?
Takashi
-- 8< --
--- a/sound/usb/mixer_quirks.c
+++ b/sound/usb/mixer_quirks.c
@@ -705,14 +705,15 @@ static int snd_dualsense_resume_jack(struct usb_mixer_elem_list *list)
return 0;
}
-static void snd_dualsense_mixer_elem_free(struct snd_kcontrol *kctl)
+static void snd_dualsense_mixer_free(struct usb_mixer_interface *mixer)
{
- struct dualsense_mixer_elem_info *mei = snd_kcontrol_chip(kctl);
+ struct dualsense_mixer_elem_info *mei = mixer->private_data;
- if (mei->ih.event)
+ if (mei && mei->ih.event) {
input_unregister_handler(&mei->ih);
-
- snd_usb_mixer_elem_free(kctl);
+ mei->ih.event = NULL;
+ }
+ mixer->private_data = NULL;
}
static int snd_dualsense_jack_create(struct usb_mixer_interface *mixer,
@@ -744,7 +745,7 @@ static int snd_dualsense_jack_create(struct usb_mixer_interface *mixer,
}
strscpy(kctl->id.name, name, sizeof(kctl->id.name));
- kctl->private_free = snd_dualsense_mixer_elem_free;
+ kctl->private_free = snd_usb_mixer_elem_free;
err = snd_usb_mixer_add_control(&mei->info.head, kctl);
if (err)
@@ -774,6 +775,9 @@ static int snd_dualsense_jack_create(struct usb_mixer_interface *mixer,
dev_warn(&mixer->chip->dev->dev,
"Could not register input handler: %d\n", err);
mei->ih.event = NULL;
+ } else {
+ mixer->private_free = snd_dualsense_mixer_free;
+ mixer->private_data = mei;
}
return 0;
^ permalink raw reply
* [RFC PATCH] HID: core: quiesce input in hid_hw_stop() to prevent use-after-free
From: Philipp Weber @ 2026-05-19 13:00 UTC (permalink / raw)
To: bentiss, jikos
Cc: eadavis, linux-input, linux-kernel, syzkaller-bugs,
syzbot+9eebf5f6544c5e873858
In-Reply-To: <69eed7e0.a00a0220.7773.0026.GAE@google.com>
A driver's probe calls hid_device_io_start() to enable input delivery,
then fails at a later initialization step and unwinds via hid_hw_stop().
The unwind frees struct hidraw via hidraw_disconnect() while in-flight
HID reports may still be running on another CPU, dereferencing the
freed object through hidraw_report_event(). syzbot reports the
resulting use-after-free for the corsair-psu HID driver.
Edward Adam Davis posted a per-driver fix for corsair-psu that adds
an explicit hid_device_io_stop() before hid_hw_stop() in the probe
error path ("hwmon: prevent packets from going to driver for probe",
2026-04-28). Auditing the tree shows 15 drivers call
hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not:
drivers calling hid_device_io_start() without a matching
hid_device_io_stop() before hid_hw_stop():
drivers/hwmon/corsair-psu.c (fix posted by Edward)
drivers/hwmon/corsair-cpro.c
drivers/hwmon/nzxt-kraken3.c
drivers/hwmon/nzxt-smart2.c
drivers/hwmon/gigabyte_waterforce.c
drivers/hid/hid-logitech-dj.c
drivers/hid/hid-nintendo.c
drivers/hid/hid-mcp2221.c
Roughly half of all callers of the API are exposed. Centralize the
quiesce in hid_hw_stop() so callers do not have to remember the
matching stop: if a driver has left hdev->io_started true on entry,
call hid_device_io_stop() before hid_disconnect().
For the 7 drivers that already call hid_device_io_stop() correctly,
hdev->io_started is false on entry, the guard short-circuits, and
behavior is unchanged.
No Fixes: tag because the affected drivers gained their
hid_device_io_start() calls independently over years; the bug is a
class-wide API misuse rather than a regression from one commit.
Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858
Signed-off-by: Philipp Weber <kernel@phwe.de>
---
drivers/hid/hid-core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 41a79e43c82b..6b024118d983 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2440,9 +2440,16 @@ EXPORT_SYMBOL_GPL(hid_hw_start);
*
* This is usually called from remove function or from probe when something
* failed and hid_hw_start was called already.
+ *
+ * If the caller enabled HID input via hid_device_io_start() and is unwinding
+ * without an explicit hid_device_io_stop(), quiesce input first so that
+ * in-flight reports cannot reach handlers (e.g. hidraw_report_event) whose
+ * backing objects hid_disconnect() is about to free.
*/
void hid_hw_stop(struct hid_device *hdev)
{
+ if (hdev->io_started)
+ hid_device_io_stop(hdev);
hid_disconnect(hdev);
hdev->ll_driver->stop(hdev);
}
base-commit: ab5fce87a778cb780a05984a2ca448f2b41aafbf
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Greg Kroah-Hartman @ 2026-05-19 12:48 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Lee Jones, Jiri Kosina, Filipe Laíns, Bastien Nocera,
Ping Cheng, Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Icenowy Zheng, linux-input, linux-kernel, greybus-dev,
linux-staging, linux-usb, stable
In-Reply-To: <agxbD6k60vQYrJ6T@beelink>
On Tue, May 19, 2026 at 02:46:13PM +0200, Benjamin Tissoires wrote:
> On May 19 2026, Lee Jones wrote:
> > On Tue, 12 May 2026, Lee Jones wrote:
> >
> > > On Wed, 06 May 2026, Lee Jones wrote:
> > >
> > > > On Mon, 04 May 2026, Benjamin Tissoires wrote:
> > > >
> > > > > Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > > > > bogus memset()") enforced the provided data to be at least the size of
> > > > > the declared buffer in the report descriptor to prevent a buffer
> > > > > overflow.
> > > > >
> > > > > We only had corner cases of malicious devices exposing the OOM because
> > > > > in most cases, the buffer provided by the transport layer needs to be
> > > > > allocated at probe time and is large enough to handle all the possible
> > > > > reports.
> > > > >
> > > > > However, the patch from above, which enforces the spec a little bit more
> > > > > introduced both regressions for devices not following the spec (not
> > > > > necesserally malicious), but also a stream of errors for those devices.
> > > > >
> > > > > Let's revert to the old behavior by giving more information to HID core
> > > > > to be able to decide whether it can or not memset the rest of the buffer
> > > > > to 0 and continue the processing.
> > > > >
> > > > > Note that the first commit makes an API change, but the callers are
> > > > > relatively limited, so it should be fine on its own. The second patch
> > > > > can't really make the same kind of API change because we have too many
> > > > > callers in various subsystems. We can switch them one by one to the safe
> > > > > approach when needed.
> > > > >
> > > > > The last 2 patches are small cleanups I initially put together with the
> > > > > 2 first patches, but they can be applied on their own and don't need to
> > > > > be pulled in stable like the first 2.
> > > > >
> > > > > Cheers,
> > > > > Benjamin
> > > > >
> > > > > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > > > > ---
> > > > > Changes in v3:
> > > > > - fixed ghib -> ghid in greybus
> > > > > - fixed i386 size_t debug size reported by kernel-bot
> > > > > - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
> > > > >
> > > > > Changes in v2:
> > > > > - added a small blurb explaining the difference between the safe and the
> > > > > non safe version of hid_safe_input_report
> > > > > - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
> > > > >
> > > > > ---
> > > > > Benjamin Tissoires (4):
> > > > > HID: pass the buffer size to hid_report_raw_event
> > > > > HID: core: introduce hid_safe_input_report()
> > > > > HID: multitouch: use __free(kfree) to clean up temporary buffers
> > > > > HID: wacom: use __free(kfree) to clean up temporary buffers
> > > > >
> > > > > drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++--
> > > > > drivers/hid/hid-core.c | 67 ++++++++++++++++++++++++++++++--------
> > > > > drivers/hid/hid-gfrm.c | 4 +--
> > > > > drivers/hid/hid-logitech-hidpp.c | 2 +-
> > > > > drivers/hid/hid-multitouch.c | 18 ++++------
> > > > > drivers/hid/hid-primax.c | 2 +-
> > > > > drivers/hid/hid-vivaldi-common.c | 2 +-
> > > > > drivers/hid/i2c-hid/i2c-hid-core.c | 7 ++--
> > > > > drivers/hid/usbhid/hid-core.c | 11 ++++---
> > > > > drivers/hid/wacom_sys.c | 46 +++++++++-----------------
> > > > > drivers/staging/greybus/hid.c | 2 +-
> > > > > include/linux/hid.h | 6 ++--
> > > > > include/linux/hid_bpf.h | 14 +++++---
> > > > > 13 files changed, 109 insertions(+), 78 deletions(-)
> > > >
> > > > What's the plan for this set Benjamin? -rcs or -next?
> > >
> > > Are there any updates on this set please?
> > >
> > > FYI, this set is still important to us.
> > >
> > > Ideally, if all is well, it would go into the -rcs for v7.1.
> >
> > I'm still actively tracking these.
> >
> > It looks like Mark has been reverting them from -next and I'm getting
> > complaints from the Stable folks that they are causing build errors.
> >
> > drivers/hid/hid-core.c: In function 'hid_safe_input_report':
> > drivers/hid/hid-core.c:2195:16: error: too many arguments to function '__hid_input_report'
> > 2195 | return __hid_input_report(hid, type, data, bufsize, size, interrupt, 0,
> >
> > Are you folks still working on this set?
>
> Well, everything is in Linus' tree:
>
> not yet in a released rc (taken yesterday by Linus directly):
>
> 4d3a2a466b8d HID: core: Fix size_t specifier in hid_report_raw_event()
>
> Already in 7.1-rc4:
>
> 206342541fc8 HID: core: introduce hid_safe_input_report()
> 2c85c61d1332 HID: pass the buffer size to hid_report_raw_event
>
> Not sure why the patches don't apply to stable, but from an upstream
> subsystem point of view, everything is in order.
We dropped them from stable because of the build breakage :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Benjamin Tissoires @ 2026-05-19 12:46 UTC (permalink / raw)
To: Lee Jones
Cc: Jiri Kosina, Filipe Laíns, Bastien Nocera, Ping Cheng,
Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Icenowy Zheng, linux-input, linux-kernel,
greybus-dev, linux-staging, linux-usb, stable
In-Reply-To: <20260519111723.GU305027@google.com>
On May 19 2026, Lee Jones wrote:
> On Tue, 12 May 2026, Lee Jones wrote:
>
> > On Wed, 06 May 2026, Lee Jones wrote:
> >
> > > On Mon, 04 May 2026, Benjamin Tissoires wrote:
> > >
> > > > Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > > > bogus memset()") enforced the provided data to be at least the size of
> > > > the declared buffer in the report descriptor to prevent a buffer
> > > > overflow.
> > > >
> > > > We only had corner cases of malicious devices exposing the OOM because
> > > > in most cases, the buffer provided by the transport layer needs to be
> > > > allocated at probe time and is large enough to handle all the possible
> > > > reports.
> > > >
> > > > However, the patch from above, which enforces the spec a little bit more
> > > > introduced both regressions for devices not following the spec (not
> > > > necesserally malicious), but also a stream of errors for those devices.
> > > >
> > > > Let's revert to the old behavior by giving more information to HID core
> > > > to be able to decide whether it can or not memset the rest of the buffer
> > > > to 0 and continue the processing.
> > > >
> > > > Note that the first commit makes an API change, but the callers are
> > > > relatively limited, so it should be fine on its own. The second patch
> > > > can't really make the same kind of API change because we have too many
> > > > callers in various subsystems. We can switch them one by one to the safe
> > > > approach when needed.
> > > >
> > > > The last 2 patches are small cleanups I initially put together with the
> > > > 2 first patches, but they can be applied on their own and don't need to
> > > > be pulled in stable like the first 2.
> > > >
> > > > Cheers,
> > > > Benjamin
> > > >
> > > > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > > > ---
> > > > Changes in v3:
> > > > - fixed ghib -> ghid in greybus
> > > > - fixed i386 size_t debug size reported by kernel-bot
> > > > - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
> > > >
> > > > Changes in v2:
> > > > - added a small blurb explaining the difference between the safe and the
> > > > non safe version of hid_safe_input_report
> > > > - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
> > > >
> > > > ---
> > > > Benjamin Tissoires (4):
> > > > HID: pass the buffer size to hid_report_raw_event
> > > > HID: core: introduce hid_safe_input_report()
> > > > HID: multitouch: use __free(kfree) to clean up temporary buffers
> > > > HID: wacom: use __free(kfree) to clean up temporary buffers
> > > >
> > > > drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++--
> > > > drivers/hid/hid-core.c | 67 ++++++++++++++++++++++++++++++--------
> > > > drivers/hid/hid-gfrm.c | 4 +--
> > > > drivers/hid/hid-logitech-hidpp.c | 2 +-
> > > > drivers/hid/hid-multitouch.c | 18 ++++------
> > > > drivers/hid/hid-primax.c | 2 +-
> > > > drivers/hid/hid-vivaldi-common.c | 2 +-
> > > > drivers/hid/i2c-hid/i2c-hid-core.c | 7 ++--
> > > > drivers/hid/usbhid/hid-core.c | 11 ++++---
> > > > drivers/hid/wacom_sys.c | 46 +++++++++-----------------
> > > > drivers/staging/greybus/hid.c | 2 +-
> > > > include/linux/hid.h | 6 ++--
> > > > include/linux/hid_bpf.h | 14 +++++---
> > > > 13 files changed, 109 insertions(+), 78 deletions(-)
> > >
> > > What's the plan for this set Benjamin? -rcs or -next?
> >
> > Are there any updates on this set please?
> >
> > FYI, this set is still important to us.
> >
> > Ideally, if all is well, it would go into the -rcs for v7.1.
>
> I'm still actively tracking these.
>
> It looks like Mark has been reverting them from -next and I'm getting
> complaints from the Stable folks that they are causing build errors.
>
> drivers/hid/hid-core.c: In function 'hid_safe_input_report':
> drivers/hid/hid-core.c:2195:16: error: too many arguments to function '__hid_input_report'
> 2195 | return __hid_input_report(hid, type, data, bufsize, size, interrupt, 0,
>
> Are you folks still working on this set?
Well, everything is in Linus' tree:
not yet in a released rc (taken yesterday by Linus directly):
4d3a2a466b8d HID: core: Fix size_t specifier in hid_report_raw_event()
Already in 7.1-rc4:
206342541fc8 HID: core: introduce hid_safe_input_report()
2c85c61d1332 HID: pass the buffer size to hid_report_raw_event
Not sure why the patches don't apply to stable, but from an upstream
subsystem point of view, everything is in order.
I still have to resend the last 2 patches, but they are not fixing
anything, just nice to have.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Lee Jones @ 2026-05-19 11:17 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Filipe Laíns, Bastien Nocera, Ping Cheng,
Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Icenowy Zheng, linux-input, linux-kernel,
greybus-dev, linux-staging, linux-usb, stable
In-Reply-To: <20260512101723.GU305027@google.com>
On Tue, 12 May 2026, Lee Jones wrote:
> On Wed, 06 May 2026, Lee Jones wrote:
>
> > On Mon, 04 May 2026, Benjamin Tissoires wrote:
> >
> > > Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > > bogus memset()") enforced the provided data to be at least the size of
> > > the declared buffer in the report descriptor to prevent a buffer
> > > overflow.
> > >
> > > We only had corner cases of malicious devices exposing the OOM because
> > > in most cases, the buffer provided by the transport layer needs to be
> > > allocated at probe time and is large enough to handle all the possible
> > > reports.
> > >
> > > However, the patch from above, which enforces the spec a little bit more
> > > introduced both regressions for devices not following the spec (not
> > > necesserally malicious), but also a stream of errors for those devices.
> > >
> > > Let's revert to the old behavior by giving more information to HID core
> > > to be able to decide whether it can or not memset the rest of the buffer
> > > to 0 and continue the processing.
> > >
> > > Note that the first commit makes an API change, but the callers are
> > > relatively limited, so it should be fine on its own. The second patch
> > > can't really make the same kind of API change because we have too many
> > > callers in various subsystems. We can switch them one by one to the safe
> > > approach when needed.
> > >
> > > The last 2 patches are small cleanups I initially put together with the
> > > 2 first patches, but they can be applied on their own and don't need to
> > > be pulled in stable like the first 2.
> > >
> > > Cheers,
> > > Benjamin
> > >
> > > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > > ---
> > > Changes in v3:
> > > - fixed ghib -> ghid in greybus
> > > - fixed i386 size_t debug size reported by kernel-bot
> > > - Link to v2: https://lore.kernel.org/r/20260416-wip-fix-core-v2-0-be92570e5627@kernel.org
> > >
> > > Changes in v2:
> > > - added a small blurb explaining the difference between the safe and the
> > > non safe version of hid_safe_input_report
> > > - Link to v1: https://lore.kernel.org/r/20260415-wip-fix-core-v1-0-ed3c4c823175@kernel.org
> > >
> > > ---
> > > Benjamin Tissoires (4):
> > > HID: pass the buffer size to hid_report_raw_event
> > > HID: core: introduce hid_safe_input_report()
> > > HID: multitouch: use __free(kfree) to clean up temporary buffers
> > > HID: wacom: use __free(kfree) to clean up temporary buffers
> > >
> > > drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++--
> > > drivers/hid/hid-core.c | 67 ++++++++++++++++++++++++++++++--------
> > > drivers/hid/hid-gfrm.c | 4 +--
> > > drivers/hid/hid-logitech-hidpp.c | 2 +-
> > > drivers/hid/hid-multitouch.c | 18 ++++------
> > > drivers/hid/hid-primax.c | 2 +-
> > > drivers/hid/hid-vivaldi-common.c | 2 +-
> > > drivers/hid/i2c-hid/i2c-hid-core.c | 7 ++--
> > > drivers/hid/usbhid/hid-core.c | 11 ++++---
> > > drivers/hid/wacom_sys.c | 46 +++++++++-----------------
> > > drivers/staging/greybus/hid.c | 2 +-
> > > include/linux/hid.h | 6 ++--
> > > include/linux/hid_bpf.h | 14 +++++---
> > > 13 files changed, 109 insertions(+), 78 deletions(-)
> >
> > What's the plan for this set Benjamin? -rcs or -next?
>
> Are there any updates on this set please?
>
> FYI, this set is still important to us.
>
> Ideally, if all is well, it would go into the -rcs for v7.1.
I'm still actively tracking these.
It looks like Mark has been reverting them from -next and I'm getting
complaints from the Stable folks that they are causing build errors.
drivers/hid/hid-core.c: In function 'hid_safe_input_report':
drivers/hid/hid-core.c:2195:16: error: too many arguments to function '__hid_input_report'
2195 | return __hid_input_report(hid, type, data, bufsize, size, interrupt, 0,
Are you folks still working on this set?
--
Lee Jones
^ permalink raw reply
* Re: [PATCH 1/1] HID: wacom: Fix OOB write in wacom_hid_set_device_mode()
From: Lee Jones @ 2026-05-19 11:13 UTC (permalink / raw)
To: Ping Cheng
Cc: Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel, stable
In-Reply-To: <CAF8JNhKTMpT3CGq_oDqaGVygqXK0jjvrvjxbAWUerqtWzdB9+Q@mail.gmail.com>
On Wed, 13 May 2026, Ping Cheng wrote:
> On Wed, May 13, 2026 at 1:05 AM Lee Jones <lee@kernel.org> wrote:
> >
> > wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE
> > usage is always located in the first field (field[0]) of the feature report.
> > However, a device can specify HID_DG_INPUTMODE in a different field.
> >
> > If HID_DG_INPUTMODE is in a field other than the first one and the first
> > field has a report_count smaller than the usage_index of HID_DG_INPUTMODE,
> > this leads to an out-of-bounds write to r->field[0]->value.
> >
> > Fix this by storing the field index of HID_DG_INPUTMODE in 'struct
> > hid_data' during feature mapping. In wacom_hid_set_device_mode(), use
> > this stored field index to access the correct field and add bounds
> > checks to ensure both the field index and the value index are within
> > valid ranges before writing.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: 5ae6e89f7409 ("HID: wacom: implement the finger part of the HID generic handling")
> > Signed-off-by: Lee Jones <lee@kernel.org>
>
> Patch looks sensible to me. Thank you for your effort, Lee!
>
> Tested-by: Ping Cheng <ping.cheng@wacom.com>
> Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Thank you Ping, I appreciate your review.
HID folks - any movement on this please?
--
Lee Jones
^ permalink raw reply
* Re: [PATCH] i2c: add sanity check for input SMBus data length
From: Wolfram Sang @ 2026-05-19 9:43 UTC (permalink / raw)
To: Edward Adam Davis
Cc: syzbot+64ca69977b37604cd6d9, bentiss, jikos, linux-i2c,
linux-input, linux-kernel, michael.zaidman, syzkaller-bugs
In-Reply-To: <tencent_9443A8C45A37693763A6D7D3658367896405@qq.com>
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]
Hi,
thanks for your patch!
On Tue, Jan 20, 2026 at 09:47:02PM +0800, Edward Adam Davis wrote:
> The value passed to block[0] in the user-constructed data is too large,
> exceeding the length that data for SMBus messages can accommodate. This
> triggered the out-of-bounds access reported by syzbot [1].
>
> Adding relevant data size checks in the smbus ioctl can prevent this
> out-of-bounds access.
>
> [1]
> BUG: KASAN: stack-out-of-bounds in ft260_smbus_write+0x19b/0x2f0 drivers/hid/hid-ft260.c:486
> Read of size 42 at addr ffffc90003427d81 by task syz.2.65/6119
> Call Trace:
> ft260_smbus_write+0x19b/0x2f0 drivers/hid/hid-ft260.c:486
> ft260_smbus_xfer+0x22c/0x640 drivers/hid/hid-ft260.c:736
>
Did you look for a suitable Fixes tag?
> Reported-by: syzbot+64ca69977b37604cd6d9@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=64ca69977b37604cd6d9
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> drivers/i2c/i2c-dev.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
> index e9577f920286..6725a49d6921 100644
> --- a/drivers/i2c/i2c-dev.c
> +++ b/drivers/i2c/i2c-dev.c
> @@ -378,6 +378,14 @@ static noinline int i2cdev_ioctl_smbus(struct i2c_client *client,
> (read_write == I2C_SMBUS_WRITE)) {
> if (copy_from_user(&temp, data, datasize))
> return -EFAULT;
> +
> + if (temp.block[0] > datasize) {
> + dev_dbg(&client->adapter->dev,
> + "user input data size (%u) is too big "
> + "in ioctl I2C_SMBUS.\n",
Strings stay in one line, please, even if they break the line length.
> + temp.block[0]);
> + return -EINVAL;
> + }
> }
> if (size == I2C_SMBUS_I2C_BLOCK_BROKEN) {
> /* Convert old I2C block commands to the new
Happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: move Risc PC-specific <asm/hardware/iomd.h> header into mach-rpc
From: Helge Deller @ 2026-05-19 6:51 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-arm-kernel, linux-i2c, linux-input,
linux-fbdev
Cc: Russell King, Andi Shyti, Dmitry Torokhov, Kees Cook
In-Reply-To: <20260510031100.255248-1-enelsonmoore@gmail.com>
On 5/10/26 05:10, Ethan Nelson-Moore wrote:
> The <asm/hardware/iomd.h> header is specific to the IOMD chip used on
> the Risc PC. Move it into mach-rpc to avoid polluting asm/hardware/
> with machine-specific headers.
>
> Also take the opportunity to remove a comment with the file path from
> the header, which is bad style.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
> MAINTAINERS | 1 -
> arch/arm/mach-rpc/dma.c | 2 +-
> arch/arm/{include/asm/hardware => mach-rpc/include/mach}/iomd.h | 2 --
> arch/arm/mach-rpc/irq.c | 2 +-
> arch/arm/mach-rpc/riscpc.c | 2 +-
> arch/arm/mach-rpc/time.c | 2 +-
> drivers/i2c/busses/i2c-acorn.c | 2 +-
> drivers/input/mouse/rpcmouse.c | 2 +-
> drivers/input/serio/rpckbd.c | 2 +-
> drivers/video/fbdev/acornfb.h | 2 +-
Regarding the fbdev change:
Acked-by: Helge Deller <deller@gmx.de>
I assume this patch is pushed via the arm tree?
Helge
^ permalink raw reply
* RE: [PATCH v3 0/9] iio: introduce devm_ API for hid sensro setup and cleanup
From: Zhang, Lixu @ 2026-05-19 5:22 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: jikos@kernel.org, jic23@kernel.org,
srinivas.pandruvada@linux.intel.com, Lechner, David,
nuno.sa@analog.com, andy@kernel.org, sakari.ailus@linux.intel.com,
linux-input@vger.kernel.org, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <agoi55wCo//eY1YQ@hu-ckantibh-hyd.qualcomm.com>
>-----Original Message-----
>From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>Sent: Monday, May 18, 2026 4:20 AM
>To: Zhang, Lixu <lixu.zhang@intel.com>
>Cc: jikos@kernel.org; jic23@kernel.org; srinivas.pandruvada@linux.intel.com;
>Lechner, David <dlechner@baylibre.com>; nuno.sa@analog.com;
>andy@kernel.org; sakari.ailus@linux.intel.com; linux-input@vger.kernel.org;
>linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH v3 0/9] iio: introduce devm_ API for hid sensro setup and
>cleanup
>
>On Thu, May 14, 2026 at 02:47:52AM +0000, Zhang, Lixu wrote:
>> Tested-by: Zhang Lixu <lixu.zhang@intel.com>
>
>Hi Zhang,
>
>Thanks for the testing and validaiton.
>I hope you validated the complete series, including the unbind flow for the
>drivers using devm API.
Hi Sanjay,
Yes, I validated the complete series. The unbind flow was tested as Srinivas previously
suggested - performing the unbind while iio-sensor-proxy has an open session. No
regression issues were observed.
Since iio-sensor-proxy does not typically open a gyro session, I applied the same changes
from hid-sensor-gyro-3d to hid-sensor-accel-3d and tested the unbind flow on that driver
as well. Again, no regression issues were found.
Thanks,
Lixu
>
>Hi Jonathan,
>
>How should we take this series forward? should I extend the series to cover
>remaining HID IIO drivers for this devm API, or this series can applied to IIO tree
>first and sent followup patches on top of that?
>
>Thanks, Sanjay
>
>>
>> >-----Original Message-----
>> >From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>> >Sent: Saturday, May 9, 2026 6:11 PM
>> >To: jikos@kernel.org; jic23@kernel.org;
>> >srinivas.pandruvada@linux.intel.com
>> >Cc: Lechner, David <dlechner@baylibre.com>; nuno.sa@analog.com;
>> >andy@kernel.org; sanjayembeddedse@gmail.com;
>> >sakari.ailus@linux.intel.com; linux-input@vger.kernel.org; linux-
>> >iio@vger.kernel.org; linux-kernel@vger.kernel.org
>> >Subject: [PATCH v3 0/9] iio: introduce devm_ API for hid sensro setup
>> >and cleanup
>> >
>> >From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>> >
>> >Key highlights:
>> >- Prepare change as pre-requisite for devm conversion for HID IIO
>> > drivers by removing redundant argument
>> >- Add devm API to setup trigger and clenaup resource using
>> > devm_add_action_or_reset()
>> >- few cleanup and prepratory changes before updating driver for devm_
>> >- few sample driver update using devm conversion to auto release
>> >resource
>> >
>> >changes in v3:
>> >- Added cleanup and prepratory changes before adding devm_ API
>> > conversion based on self review: 0002, 0004, 0006, 0007 and 0008
>> >- Address andy's review comment on commit message and coding style
>> >- v2 series -> https://lore.kernel.org/all/20260429175918.2541914-1-
>> >sanjayembedded@gmail.com/
>> >changes in v2:
>> >- Following input from Jonathan and Andy, squash initial patch v1
>> > series in single change as individual change should not break
>> >anything
>> >- Add devm API support and two driver using the same
>> >- v1 series -> https://lore.kernel.org/all/20260428071613.1134053-1-
>> >sanjayembedded@gmail.com/
>> >
>> >Testing:
>> > - Compiled with W=1
>> > - Build-tested on QEMU x86_64
>> >
>> >Based on further feedback and reviews, I would extend this series to
>> >convert all HID IIO driver to use devm_* API.
>> >
>> >Thanks,
>> >Sanjay Chitroda
>> >
>> >
>> >Sanjay Chitroda (9):
>> > iio: hid-sensors: drop redundant iio_dev argument
>> > iio: hid-sensors: cleanup codestyle warning
>> > iio: hid-sensors: introduce device managed API
>> > iio: gyro: hid-sensor-gyro-3d: cleanup codestyle warning
>> > iio: gyro: hid-sensor-gyro-3d: drop hid_sensor_remove_trigger() using
>> > devm API
>> > iio: humidity: hid-sensor-humidity: cleanup codestyle check
>> > iio: humidity: hid-sensor-humidity: use common device for devres
>> > iio: humidity: hid-sensor-humidity: use local struct device
>> > iio: humidity: hid-sensor-humidity: drop hid_sensor_remove_trigger()
>> > using devm API
>> >
>> > drivers/iio/accel/hid-sensor-accel-3d.c | 4 +-
>> > .../common/hid-sensors/hid-sensor-trigger.c | 24 +++++++-
>> > .../common/hid-sensors/hid-sensor-trigger.h | 5 +-
>> > drivers/iio/gyro/hid-sensor-gyro-3d.c | 16 ++---
>> > drivers/iio/humidity/hid-sensor-humidity.c | 61 +++++++++----------
>> > drivers/iio/light/hid-sensor-als.c | 4 +-
>> > drivers/iio/light/hid-sensor-prox.c | 4 +-
>> > drivers/iio/magnetometer/hid-sensor-magn-3d.c | 4 +-
>> >drivers/iio/orientation/hid-sensor-incl-3d.c | 4 +-
>> >drivers/iio/orientation/hid- sensor-rotation.c | 4 +- .../position/hid-sensor-
>custom-intel-hinge.c | 4 +-
>> > drivers/iio/pressure/hid-sensor-press.c | 4 +-
>> > .../iio/temperature/hid-sensor-temperature.c | 4 +-
>> > 13 files changed, 78 insertions(+), 64 deletions(-)
>> >
>> >
>> >base-commit: 39b80c5c9830d12d2d6531059001301c4265322a
>> >--
>> >2.34.1
>> >
>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox