* Re: [linux-5.10.y 1/3] HID: core: Add printk_ratelimited variants to hid_warn() etc
From: Sasha Levin @ 2026-06-09 0:51 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Viresh Kumar, Johan Hovold,
Alex Elder, Greg Kroah-Hartman, linux-input, linux-kernel,
greybus-dev, linux-staging
Cc: Sasha Levin, stable, Vicki Pfau, Jiri Kosina
In-Reply-To: <20260608100236.2781796-1-lee@kernel.org>
> [linux-5.10.y 1/3] HID: core: Add printk_ratelimited variants to hid_warn() etc
> [linux-5.10.y 2/3] HID: pass the buffer size to hid_report_raw_event
> [linux-5.10.y 3/3] HID: core: Fix size_t specifier in hid_report_raw_event()
Whole series queued for 5.10, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH] Input: cyapa: fix runtime PM refcount leak in cyapa_update_rt_suspend_scanrate()
From: Wentao Liang @ 2026-06-09 0:46 UTC (permalink / raw)
To: dmitry.torokhov
Cc: sakari.ailus, linux-input, linux-kernel, Wentao Liang, stable
pm_runtime_get_sync() at line 901 increments the runtime PM usage
count. If mutex_lock_interruptible() fails at line 903, the function
returns the error immediately at line 905 without calling
pm_runtime_put_sync_autosuspend(), leaking the PM reference and
preventing the device from ever entering runtime suspend.
Add pm_runtime_put_sync_autosuspend(dev) on the error path before
returning.
Cc: stable@vger.kernel.org
Fixes: 672865080a8f ("Input: cyapa - add runtime power management support")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
drivers/input/mouse/cyapa.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 6e0d956617a1..5edf4fdbb373 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -901,8 +901,10 @@ static ssize_t cyapa_update_rt_suspend_scanrate(struct device *dev,
pm_runtime_get_sync(dev);
error = mutex_lock_interruptible(&cyapa->state_sync_lock);
- if (error)
+ if (error) {
+ pm_runtime_put_sync_autosuspend(dev);
return error;
+ }
cyapa->runtime_suspend_sleep_time = min_t(u16, time, 1000);
cyapa->runtime_suspend_power_mode =
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 0/7] HID: iio: basic clean up for usage_id
From: Maxwell Doose @ 2026-06-08 22:03 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada, David Lechner,
Nuno Sá, Andy Shevchenko, linux-input, linux-iio,
linux-kernel
In-Reply-To: <20260606-6-june-hid-iio-correct-usage-id-v1-0-dd4a6820b674@gmail.com>
On Sat, 06 Jun 2026 17:47:41 +0530
Sanjay Chitroda <sanjayembeddedse@gmail.com> wrote:
> Hi all,
>
> This series updates all HID IIO drivers to use 'u32' instead of
> bare 'unsigned' for the usage_id parameter.
>
> This improves type clarity and ensures consistency with kernel
> coding style, as HID usage IDs are defined as 32-bit values.
>
> No functional changes are introduced.
>
> Testing:
> - Compiled with W=1 for each patch in the series
>
> ---
> Sanjay Chitroda (7):
> iio: gyro: hid-sensor-gyro-3d: use u32 instead of unsigned
> iio: accel: hid-sensor-accel-3d: use u32 instead of unsigned
> iio: light: hid-sensor-als: use u32 instead of unsigned
> iio: light: hid-sensor-prox: use u32 instead of unsigned
> iio: orientation: hid-sensor-incl-3d: use u32 instead of unsigned
> iio: orientation: hid-sensor-rotation: use u32 instead of unsigned
> iio: pressure: hid-sensor-press: use u32 instead of unsigned
>
> drivers/iio/accel/hid-sensor-accel-3d.c | 6 +++---
> drivers/iio/gyro/hid-sensor-gyro-3d.c | 6 +++---
> drivers/iio/light/hid-sensor-als.c | 6 +++---
> drivers/iio/light/hid-sensor-prox.c | 4 ++--
> drivers/iio/orientation/hid-sensor-incl-3d.c | 6 +++---
> drivers/iio/orientation/hid-sensor-rotation.c | 6 +++---
> drivers/iio/pressure/hid-sensor-press.c | 6 +++---
> 7 files changed, 20 insertions(+), 20 deletions(-)
> ---
> base-commit: ae696dfa47c30016cd429b9db5e70b259b8f509e
> change-id: 20260606-6-june-hid-iio-correct-usage-id-57ce92cb102b
>
> Best regards,
> --
> Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
>
This series:
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
--
best regards,
max
^ permalink raw reply
* Re: [PATCH 3/7] iio: light: hid-sensor-als: use u32 instead of unsigned
From: Maxwell Doose @ 2026-06-08 22:01 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Joshua Crofts, Sanjay Chitroda, Jiri Kosina, Srinivas Pandruvada,
David Lechner, Nuno Sá, Andy Shevchenko, linux-input,
linux-iio, linux-kernel
In-Reply-To: <20260608194047.23791938@jic23-huawei>
On Mon, 8 Jun 2026 19:40:47 +0100
Jonathan Cameron <jic23@kernel.org> wrote:
> On Mon, 8 Jun 2026 08:37:38 +0200
> Joshua Crofts <joshua.crofts1@gmail.com> wrote:
>
> > On Sun, 7 Jun 2026 at 22:54, Maxwell Doose <m32285159@gmail.com> wrote:
> > >
> > > On Sat, Jun 6, 2026 at 7:19 AM Sanjay Chitroda
> > > <sanjayembeddedse@gmail.com> wrote:
> > > >
> > > > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> > > >
> > > > Prefer 'u32' instead of bare 'unsigned' variable to improve code
> > > > clarity and consistency with kernel style.
> > > >
> > > > Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> > > > ---
> > > > drivers/iio/light/hid-sensor-als.c | 6 +++---
> > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > >
> > > Do we *need* u32 though? Usually these types are for places where we
> > > require specific bit-widths for a reason (e.g., reading a hardware
> > > register) but I'm not sure that's the case here. I could be totally
> > > wrong, in that case please correct me but otherwise I unfortunately
> > > don't see much value in this. That's just my personal opinion though,
> > > Jonathan may think otherwise.
> >
> > Aside from the array of usage ids that are u32 defined here:
> > https://elixir.bootlin.com/linux/v7.1-rc6/source/drivers/iio/light/hid-sensor-als.c#L46
> >
> > there are additional structs used in the HID drivers that take u32 (I
> > had a similar
> > patch moving `unsigned` to `unsigned int`, but it was recommended to use the
> > types that the structs use, hence u32).
> >
> Here the reason for the change is even simpler. These are callbacks assigned to:
>
> struct hid_sensor_hub_callbacks {
> struct platform_device *pdev;
> int (*suspend)(struct hid_sensor_hub_device *hsdev, void *priv);
> int (*resume)(struct hid_sensor_hub_device *hsdev, void *priv);
> int (*capture_sample)(struct hid_sensor_hub_device *hsdev,
> u32 usage_id, size_t raw_len, char *raw_data,
> void *priv);
> int (*send_event)(struct hid_sensor_hub_device *hsdev, u32 usage_id,
> void *priv);
> };
>
> So given those signatures, these should always have been u32.
>
Ah then perhaps I was a bit harsh on Sanjay.
>
> I would like that clearly stated in the patch descriptions. Consistency
> is a bit too vague.
>
Agree though. But given this
Reviewed-by: Maxwell Doose <m32285159@gmail.com>
--
best regards,
max
^ permalink raw reply
* Re: [PATCH] input: ipaq-micro-keys: simplify allocation
From: Rosen Penev @ 2026-06-08 20:20 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, open list
In-Reply-To: <aibx1y8ANiZoMHyY@google.com>
On Mon, Jun 8, 2026 at 9:49 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Rosen,
>
> On Sun, Jun 07, 2026 at 09:50:41PM -0700, Rosen Penev wrote:
> > Use a flexible array member to have a single allocation.
>
> Why does it have to be flexible? The size is known.
From a quick glance, that would be a compilation error. micro_keycodes
gets declared after ipaq_micro_keys
From looking at a bunch of struct definitions, [ARRAY_SIZE(foo)] seems
to be atypical.
>
> >
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> > drivers/input/keyboard/ipaq-micro-keys.c | 9 +++------
> > 1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/input/keyboard/ipaq-micro-keys.c b/drivers/input/keyboard/ipaq-micro-keys.c
> > index ca7ec054b1ce..0fc5b5dcdef5 100644
> > --- a/drivers/input/keyboard/ipaq-micro-keys.c
> > +++ b/drivers/input/keyboard/ipaq-micro-keys.c
> > @@ -23,7 +23,7 @@
> > struct ipaq_micro_keys {
> > struct ipaq_micro *micro;
> > struct input_dev *input;
> > - u16 *codes;
> > + u16 codes[];
> > };
> >
> > static const u16 micro_keycodes[] = {
> > @@ -90,10 +90,11 @@ static int micro_key_probe(struct platform_device *pdev)
> > int error;
> > int i;
> >
> > - keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
> > + keys = devm_kzalloc(&pdev->dev, struct_size(keys, codes, ARRAY_SIZE(micro_keycodes)), GFP_KERNEL);
>
> Please keep to the limits for the kernel. 100 columns is acceptable when
> leads to better readability, but I prefer 80 when it makes sense.
Seems I forgot to run git clang-format here. Will resend.
>
> checkpatch.pl would have warned you.
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH v2] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume
From: d3z @ 2026-06-08 20:02 UTC (permalink / raw)
To: even.xu, xinpeng.sun, jikos, bentiss
Cc: Danny D ., linux-input, linux-kernel, abhishektamboli9,
sakari.ailus
In-Reply-To: <IA1PR11MB6098E927297E716FA72FDD04F41C2@IA1PR11MB6098.namprd11.prod.outlook.com>
From: Danny D. <d3z.the.dev@gmail.com>
Hi Even,
Thanks for the review, and for working through this together.
Danny
^ permalink raw reply
* Re: [PATCH] HID: hiddev: Use kref to track struct hiddev lifetime
From: Dmitry Torokhov @ 2026-06-08 18:44 UTC (permalink / raw)
To: Heitor Alves de Siqueira
Cc: Jiri Kosina, Benjamin Tissoires, kernel-dev, linux-usb,
linux-input, linux-kernel, syzbot+563191a4939ddbfe73d4
In-Reply-To: <20260608-hiddev_kref-v1-1-cd240c95423f@igalia.com>
Hi Heitor,
On Mon, Jun 08, 2026 at 01:33:03PM -0300, Heitor Alves de Siqueira wrote:
> If a USB HID device is disconnected while userspace still holds the
> hiddev node open, hiddev_disconnect() and hiddev_release() can race on
> the embedded existancelock mutex. Syzbot has triggered this with kfree()
> happening during the mutex slow path.
>
> Fix by introducing a kref in struct hiddev, and moving kfree() into a
> dedicated release callback. This way, struct hiddev will only be freed
> after both hiddev_release() and hiddev_disconnect() are done.
This looks like a common issue with usb_register_dev() that does not
allow tying the lifetime of the created device, lifetime of user of the
created device, and userspace accessing it. Ideally the class device
would be embedded into struct hiddev, and tie its lifetime with lifetime
of the chardev associated with it and userspace accessors using it. tie
its lifetime with lifetime of the chardev associated with it and
userspace accessors using it. See cdev_device_add() and how it is being
used by multiple subsystems and how they handle class devices.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/7] HID: iio: basic clean up for usage_id
From: Jonathan Cameron @ 2026-06-08 18:41 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: Jiri Kosina, Srinivas Pandruvada, David Lechner, Nuno Sá,
Andy Shevchenko, linux-input, linux-iio, linux-kernel
In-Reply-To: <20260606-6-june-hid-iio-correct-usage-id-v1-0-dd4a6820b674@gmail.com>
On Sat, 06 Jun 2026 17:47:41 +0530
Sanjay Chitroda <sanjayembeddedse@gmail.com> wrote:
> Hi all,
>
> This series updates all HID IIO drivers to use 'u32' instead of
> bare 'unsigned' for the usage_id parameter.
>
> This improves type clarity and ensures consistency with kernel
> coding style, as HID usage IDs are defined as 32-bit values.
Other than adding some more detail to the consistency part
(make sure to mention the callback signatures), this looks fine to
me.
Jonathan
>
> No functional changes are introduced.
>
> Testing:
> - Compiled with W=1 for each patch in the series
>
> ---
> Sanjay Chitroda (7):
> iio: gyro: hid-sensor-gyro-3d: use u32 instead of unsigned
> iio: accel: hid-sensor-accel-3d: use u32 instead of unsigned
> iio: light: hid-sensor-als: use u32 instead of unsigned
> iio: light: hid-sensor-prox: use u32 instead of unsigned
> iio: orientation: hid-sensor-incl-3d: use u32 instead of unsigned
> iio: orientation: hid-sensor-rotation: use u32 instead of unsigned
> iio: pressure: hid-sensor-press: use u32 instead of unsigned
>
> drivers/iio/accel/hid-sensor-accel-3d.c | 6 +++---
> drivers/iio/gyro/hid-sensor-gyro-3d.c | 6 +++---
> drivers/iio/light/hid-sensor-als.c | 6 +++---
> drivers/iio/light/hid-sensor-prox.c | 4 ++--
> drivers/iio/orientation/hid-sensor-incl-3d.c | 6 +++---
> drivers/iio/orientation/hid-sensor-rotation.c | 6 +++---
> drivers/iio/pressure/hid-sensor-press.c | 6 +++---
> 7 files changed, 20 insertions(+), 20 deletions(-)
> ---
> base-commit: ae696dfa47c30016cd429b9db5e70b259b8f509e
> change-id: 20260606-6-june-hid-iio-correct-usage-id-57ce92cb102b
>
> Best regards,
> --
> Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
^ permalink raw reply
* Re: [PATCH 3/7] iio: light: hid-sensor-als: use u32 instead of unsigned
From: Jonathan Cameron @ 2026-06-08 18:40 UTC (permalink / raw)
To: Joshua Crofts
Cc: Maxwell Doose, Sanjay Chitroda, Jiri Kosina, Srinivas Pandruvada,
David Lechner, Nuno Sá, Andy Shevchenko, linux-input,
linux-iio, linux-kernel
In-Reply-To: <CALoEA-yiDwjkKxUE3B=qiTdBhbvinfq-UN8h1H-HysXGm0prSg@mail.gmail.com>
On Mon, 8 Jun 2026 08:37:38 +0200
Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> On Sun, 7 Jun 2026 at 22:54, Maxwell Doose <m32285159@gmail.com> wrote:
> >
> > On Sat, Jun 6, 2026 at 7:19 AM Sanjay Chitroda
> > <sanjayembeddedse@gmail.com> wrote:
> > >
> > > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> > >
> > > Prefer 'u32' instead of bare 'unsigned' variable to improve code
> > > clarity and consistency with kernel style.
> > >
> > > Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> > > ---
> > > drivers/iio/light/hid-sensor-als.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> >
> > Do we *need* u32 though? Usually these types are for places where we
> > require specific bit-widths for a reason (e.g., reading a hardware
> > register) but I'm not sure that's the case here. I could be totally
> > wrong, in that case please correct me but otherwise I unfortunately
> > don't see much value in this. That's just my personal opinion though,
> > Jonathan may think otherwise.
>
> Aside from the array of usage ids that are u32 defined here:
> https://elixir.bootlin.com/linux/v7.1-rc6/source/drivers/iio/light/hid-sensor-als.c#L46
>
> there are additional structs used in the HID drivers that take u32 (I
> had a similar
> patch moving `unsigned` to `unsigned int`, but it was recommended to use the
> types that the structs use, hence u32).
>
Here the reason for the change is even simpler. These are callbacks assigned to:
struct hid_sensor_hub_callbacks {
struct platform_device *pdev;
int (*suspend)(struct hid_sensor_hub_device *hsdev, void *priv);
int (*resume)(struct hid_sensor_hub_device *hsdev, void *priv);
int (*capture_sample)(struct hid_sensor_hub_device *hsdev,
u32 usage_id, size_t raw_len, char *raw_data,
void *priv);
int (*send_event)(struct hid_sensor_hub_device *hsdev, u32 usage_id,
void *priv);
};
So given those signatures, these should always have been u32.
I would like that clearly stated in the patch descriptions. Consistency
is a bit too vague.
^ permalink raw reply
* Re: [PATCH 3/7] iio: light: hid-sensor-als: use u32 instead of unsigned
From: Jonathan Cameron @ 2026-06-08 18:34 UTC (permalink / raw)
To: Joshua Crofts
Cc: Sanjay Chitroda, Jiri Kosina, Srinivas Pandruvada, David Lechner,
Nuno Sá, Andy Shevchenko, linux-input, linux-iio,
linux-kernel
In-Reply-To: <CALoEA-yasQhXE9o-iYL5h8w0wPMrP4f-iva-YOJ2KZV9UuGe3g@mail.gmail.com>
On Mon, 8 Jun 2026 08:41:07 +0200
Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> On Sat, 6 Jun 2026 at 14:19, Sanjay Chitroda <sanjayembeddedse@gmail.com> wrote:
> >
> > From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> >
> > Prefer 'u32' instead of bare 'unsigned' variable to improve code
> > clarity and consistency with kernel style.
> >
> > Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> > ---
> > drivers/iio/light/hid-sensor-als.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
> > index d72e260b8266..ae2fda8dc500 100644
> > --- a/drivers/iio/light/hid-sensor-als.c
> > +++ b/drivers/iio/light/hid-sensor-als.c
> > @@ -241,7 +241,7 @@ static const struct iio_info als_info = {
> >
> > /* Callback handler to send event after all samples are received and captured */
> > static int als_proc_event(struct hid_sensor_hub_device *hsdev,
> > - unsigned usage_id,
> > + u32 usage_id,
> > void *priv)
>
> Code-wise fine, however looking at this function, usage_id is never
> actually used,
> though not sure whether removing it would break the ABI... up to you
> to check it.
>
It is a callback so signature needs to match.
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: input: microchip,cap11xx: Cleanup and refine LED constraints
From: Conor Dooley @ 2026-06-08 17:44 UTC (permalink / raw)
To: Jun Yan
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260606150458.250606-4-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4602 bytes --]
On Sat, Jun 06, 2026 at 11:03:56PM +0800, Jun Yan wrote:
> Add detailed datasheet links for all supported CAP11xx devices.
>
> Unify LED node pattern to support all chip variants in preparation
> for CAP1114 support.
>
> Remove redundant LED properties inherited from common.yaml
>
> Apply per-chip LED channel limits:
> - CAP1126: max 2 channels (0-1)
> - CAP1188: max 8 channels (0-7)
> - CAP1106, CAP12xx: no LED support
>
> Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> ---
> .../bindings/input/microchip,cap11xx.yaml | 51 ++++++++++++++-----
> 1 file changed, 37 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> index 7ade03f1b32b..99d00f572a2d 100644
> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> @@ -10,6 +10,15 @@ description: |
> The Microchip CAP1xxx Family of RightTouchTM multiple-channel capacitive
> touch controllers and LED drivers. The device communication via I2C only.
>
> + For more product information please see the links below:
> + CAP1106: https://ww1.microchip.com/downloads/en/DeviceDoc/00001624B.pdf
> + CAP1126: https://ww1.microchip.com/downloads/en/DeviceDoc/00001623B.pdf
> + CAP1188: https://ww1.microchip.com/downloads/en/DeviceDoc/00001620C.pdf
> + CAP1203: https://ww1.microchip.com/downloads/en/DeviceDoc/00001572B.pdf
> + CAP1206: https://ww1.microchip.com/downloads/en/DeviceDoc/00001567B.pdf
> + CAP1293: https://ww1.microchip.com/downloads/en/DeviceDoc/00001566B.pdf
> + CAP1298: https://ww1.microchip.com/downloads/en/DeviceDoc/00001571B.pdf
> +
> maintainers:
> - Rob Herring <robh@kernel.org>
>
> @@ -124,25 +133,21 @@ properties:
> The number of entries must correspond to the number of channels.
>
> patternProperties:
> - "^led@[0-7]$":
> + "^led@[0-9a-f]$":
> type: object
> description: CAP11xx LEDs
> $ref: /schemas/leds/common.yaml#
>
> properties:
> reg:
> - enum: [0, 1, 2, 3, 4, 5, 6, 7]
> -
> - label: true
> -
> - linux,default-trigger: true
> -
> - default-state: true
> + description: LED channel number
> + minimum: 0
> + maximum: 7
>
> required:
> - reg
>
> - additionalProperties: false
> + unevaluatedProperties: false
> Remove redundant LED properties inherited from common.yaml
But the pattern here suggests they aren't redundant, this is how you say
"these properties are the only common ones allowed". You need to explain
why other ones are valid to change this.
pw-bot: changes-requested
(a commit message change is required at least)
>
> allOf:
> - $ref: input.yaml
> @@ -158,7 +163,20 @@ allOf:
> - microchip,cap1298
> then:
> patternProperties:
> - "^led@[0-7]$": false
> + "^led@": false
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - microchip,cap1126
> + then:
> + patternProperties:
> + "^led@":
> + properties:
> + reg:
> + maximum: 1
I think these changes to permitted properties should be a standalone
patch.
Thanks,
Conor.
>
> - if:
> properties:
> @@ -183,6 +201,9 @@ additionalProperties: false
>
> examples:
> - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/leds/common.h>
> +
> i2c {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -208,19 +229,21 @@ examples:
> #size-cells = <0>;
>
> led@0 {
> - label = "cap11xx:green:usr0";
> reg = <0>;
> + function = LED_FUNCTION_INDICATOR;
> + color = <LED_COLOR_ID_GREEN>;
> };
>
> led@1 {
> - label = "cap11xx:green:usr1";
> reg = <1>;
> + function = LED_FUNCTION_INDICATOR;
> + color = <LED_COLOR_ID_GREEN>;
> };
>
> led@2 {
> - label = "cap11xx:green:alive";
> reg = <2>;
> - linux,default-trigger = "heartbeat";
> + function = LED_FUNCTION_INDICATOR;
> + color = <LED_COLOR_ID_GREEN>;
> };
> };
> };
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 4/8] dt-bindings: input: microchip,cap11xx: Add reset-gpios property
From: Conor Dooley @ 2026-06-08 17:38 UTC (permalink / raw)
To: Jun Yan
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260606150458.250606-5-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 7/8] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Conor Dooley @ 2026-06-08 17:38 UTC (permalink / raw)
To: Jun Yan
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260606150458.250606-8-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3409 bytes --]
On Sat, Jun 06, 2026 at 11:04:00PM +0800, Jun Yan wrote:
> CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
> and hardware reset support.
>
> Add the compatible string for CAP1114, include its datasheet URL,
> and update the maximum count of LED channels and linux,keycodes entries.
>
> Add description for microchip,input-threshold: CAP1114 only provides eight
> threshold entries, which does not match its total channel count.
>
> Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> ---
> .../bindings/input/microchip,cap11xx.yaml | 21 +++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> index e307628350c2..08233386a433 100644
> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> @@ -12,6 +12,7 @@ description: |
>
> For more product information please see the links below:
> CAP1106: https://ww1.microchip.com/downloads/en/DeviceDoc/00001624B.pdf
> + CAP1114: https://ww1.microchip.com/downloads/en/DeviceDoc/00002444A.pdf
> CAP1126: https://ww1.microchip.com/downloads/en/DeviceDoc/00001623B.pdf
> CAP1188: https://ww1.microchip.com/downloads/en/DeviceDoc/00001620C.pdf
> CAP1203: https://ww1.microchip.com/downloads/en/DeviceDoc/00001572B.pdf
> @@ -26,6 +27,7 @@ properties:
> compatible:
> enum:
> - microchip,cap1106
> + - microchip,cap1114
> - microchip,cap1126
> - microchip,cap1188
> - microchip,cap1203
> @@ -62,7 +64,7 @@ properties:
>
> linux,keycodes:
> minItems: 3
> - maxItems: 8
> + maxItems: 14
> description: |
> Specifies an array of numeric keycode values to
> be used for the channels. If this property is
> @@ -122,6 +124,8 @@ properties:
> is required for a touch to be registered, making the touch sensor less
> sensitive.
> The number of entries must correspond to the number of channels.
> + CAP1114 is an exception where channels 8~14 reuse the eighth entry's
> + threshold, so counts differ.
>
> microchip,calib-sensitivity:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> @@ -149,7 +153,7 @@ patternProperties:
> reg:
> description: LED channel number
> minimum: 0
> - maximum: 7
> + maximum: 10
>
> required:
> - reg
> @@ -199,6 +203,19 @@ allOf:
> reg:
> maximum: 1
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - microchip,cap1188
I don't understand this restriction, shouldn't this be
if: properties: compatible: not: contains: microchip,cap1114
so that the constraints before your change are retained?
Also, you don't add a new constraint for linux,keycodes, so now it is
permitted to have > 8 entries for existing devices.
pw-bot: changes-requested
Thanks,
Conor.
> + then:
> + patternProperties:
> + "^led@":
> + properties:
> + reg:
> + maximum: 7
> +
> - if:
> properties:
> compatible:
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Ethan Nelson-Moore @ 2026-06-08 17:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Dmitry Torokhov, linux-arm-kernel, linux-input, linux-serial,
Russell King, Greg Kroah-Hartman, Jiri Slaby, Russell King,
Linus Walleij, Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weißschuh,
Peter Zijlstra
In-Reply-To: <86765df4-0d2d-435e-85d8-b9bd4f3ea85d@app.fastmail.com>
Hi, Arnd,
On Mon, Jun 8, 2026 at 10:11 AM Arnd Bergmann <arnd@arndb.de> wrote:
> I think this is correct, as footbridge is the only one that selects
> CONFIG_ARCH_MIGHT_HAVE_PC_SERIO and defines I8042_KBD_IRQ on arm.
I came to the same conclusion.
Ethan
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Arnd Bergmann @ 2026-06-08 17:11 UTC (permalink / raw)
To: Dmitry Torokhov, Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Greg Kroah-Hartman, Jiri Slaby, Russell King, Linus Walleij,
Kees Cook, Nathan Chancellor, Sebastian Andrzej Siewior,
Steven Rostedt, Thomas Weißschuh, Peter Zijlstra
In-Reply-To: <aibz3auoiq4CFa9l@google.com>
On Mon, Jun 8, 2026, at 18:56, Dmitry Torokhov wrote:
> On Sat, May 09, 2026 at 10:20:49PM -0700, Ethan Nelson-Moore wrote:
>> diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
>> index a8f4b2d70e59..cea72bd888af 100644
>>
>> -#if defined(__arm__)
>> -/* defined in include/asm-arm/arch-xxx/irqs.h */
>> -#include <asm/irq.h>
>> +#ifdef CONFIG_ARCH_FOOTBRIDGE
>> +/* defined in arch/arm/mach-footbridge/include/mach/irqs.h */
>> +#include <mach/irqs.h>
>> #elif defined(CONFIG_PPC)
>> extern int of_i8042_kbd_irq;
>> extern int of_i8042_aux_irq;
>
> This does not look right. Did you mean to drop inclusion of asm/irq.h
> for all other arms?
I think this is correct, as footbridge is the only one that selects
CONFIG_ARCH_MIGHT_HAVE_PC_SERIO and defines I8042_KBD_IRQ on arm.
Arnd
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Dmitry Torokhov @ 2026-06-08 16:56 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Jiri Slaby,
Russell King (Oracle), Linus Walleij, Kees Cook,
Nathan Chancellor, Sebastian Andrzej Siewior, Steven Rostedt,
Thomas Weissschuh, Peter Zijlstra
In-Reply-To: <20260510052107.555825-1-enelsonmoore@gmail.com>
Hi Ethan,
On Sat, May 09, 2026 at 10:20:49PM -0700, Ethan Nelson-Moore wrote:
> diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
> index a8f4b2d70e59..cea72bd888af 100644
> --- a/drivers/input/serio/i8042-io.h
> +++ b/drivers/input/serio/i8042-io.h
> @@ -15,9 +15,9 @@
> * IRQs.
> */
>
> -#if defined(__arm__)
> -/* defined in include/asm-arm/arch-xxx/irqs.h */
> -#include <asm/irq.h>
> +#ifdef CONFIG_ARCH_FOOTBRIDGE
> +/* defined in arch/arm/mach-footbridge/include/mach/irqs.h */
> +#include <mach/irqs.h>
> #elif defined(CONFIG_PPC)
> extern int of_i8042_kbd_irq;
> extern int of_i8042_aux_irq;
This does not look right. Did you mean to drop inclusion of asm/irq.h
for all other arms?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: hiddev: Use kref to track struct hiddev lifetime
From: sashiko-bot @ 2026-06-08 16:52 UTC (permalink / raw)
To: Heitor Alves de Siqueira; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260608-hiddev_kref-v1-1-cd240c95423f@igalia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Use-After-Free in hiddev_send_event due to race between hid_disconnect and usbhid_irq_in.
--
commit a4056f7ab6df2200de09a38f314eabfb8dd4a066
Author: Heitor Alves de Siqueira <halves@igalia.com>
HID: hiddev: Use kref to track struct hiddev lifetime
This commit fixes a race between hiddev_disconnect() and hiddev_release()
by introducing a kref in struct hiddev. It moves the deallocation into a
dedicated release callback, ensuring the structure is only freed after both
functions are complete.
Closes: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4
> diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
> index 6378801b22c6d..1f2802920beee 100644
> --- a/drivers/hid/usbhid/hiddev.c
> +++ b/drivers/hid/usbhid/hiddev.c
[ ... ]
> @@ -933,13 +947,11 @@ void hiddev_disconnect(struct hid_device *hid)
>
> mutex_lock(&hiddev->existancelock);
> hiddev->exist = 0;
> -
> if (hiddev->open) {
> hid_hw_close(hiddev->hid);
> wake_up_interruptible(&hiddev->wait);
> - mutex_unlock(&hiddev->existancelock);
> - } else {
> - mutex_unlock(&hiddev->existancelock);
> - kfree(hiddev);
> }
> + mutex_unlock(&hiddev->existancelock);
> +
> + kref_put(&hiddev->kref, hiddev_kref_free);
[Severity: Critical]
This isn't a bug introduced by this patch, but is there a use-after-free
race condition when freeing struct hiddev while URBs are still active?
When a USB HID device is disconnected, usbhid_disconnect() eventually calls
hid_hw_stop(), which tears down the high-level structures before stopping
the low-level driver:
drivers/hid/hid-core.c:hid_hw_stop() {
hid_disconnect(hdev);
hdev->ll_driver->stop(hdev);
}
Because hid_disconnect() calls hiddev_disconnect() (which drops the kref
here), if no userspace process holds the file open, struct hiddev will be
freed immediately.
Since the input URBs have not yet been killed by hdev->ll_driver->stop(),
can an URB complete concurrently on another CPU?
If the URB completes, the completion handler usbhid_irq_in() propagates to
hid_input_report() -> hid_input_field() -> hiddev_send_event(), which then
dereferences the freed hiddev pointer:
drivers/hid/usbhid/hiddev.c:hiddev_send_event() {
struct hiddev *hiddev = hid->hiddev;
struct hiddev_list *list;
unsigned long flags;
spin_lock_irqsave(&hiddev->list_lock, flags);
Would this cause a use-after-free panic in interrupt context when it tries
to acquire list_lock?
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260608-hiddev_kref-v1-1-cd240c95423f@igalia.com?part=1
^ permalink raw reply
* Re: [PATCH] input: ipaq-micro-keys: simplify allocation
From: Dmitry Torokhov @ 2026-06-08 16:49 UTC (permalink / raw)
To: Rosen Penev; +Cc: linux-input, open list
In-Reply-To: <20260608045041.4664-1-rosenp@gmail.com>
Hi Rosen,
On Sun, Jun 07, 2026 at 09:50:41PM -0700, Rosen Penev wrote:
> Use a flexible array member to have a single allocation.
Why does it have to be flexible? The size is known.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/input/keyboard/ipaq-micro-keys.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/input/keyboard/ipaq-micro-keys.c b/drivers/input/keyboard/ipaq-micro-keys.c
> index ca7ec054b1ce..0fc5b5dcdef5 100644
> --- a/drivers/input/keyboard/ipaq-micro-keys.c
> +++ b/drivers/input/keyboard/ipaq-micro-keys.c
> @@ -23,7 +23,7 @@
> struct ipaq_micro_keys {
> struct ipaq_micro *micro;
> struct input_dev *input;
> - u16 *codes;
> + u16 codes[];
> };
>
> static const u16 micro_keycodes[] = {
> @@ -90,10 +90,11 @@ static int micro_key_probe(struct platform_device *pdev)
> int error;
> int i;
>
> - keys = devm_kzalloc(&pdev->dev, sizeof(*keys), GFP_KERNEL);
> + keys = devm_kzalloc(&pdev->dev, struct_size(keys, codes, ARRAY_SIZE(micro_keycodes)), GFP_KERNEL);
Please keep to the limits for the kernel. 100 columns is acceptable when
leads to better readability, but I prefer 80 when it makes sense.
checkpatch.pl would have warned you.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Ethan Nelson-Moore @ 2026-06-08 16:40 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Dmitry Torokhov, Jiri Slaby,
Russell King (Oracle), Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weissschuh,
Peter Zijlstra
In-Reply-To: <CAD++jLmUW4KjxEjwv7_an_dEMTSOtvG=q2MjhqKvnuGrWaaCsQ@mail.gmail.com>
Hi, Linus,
On Mon, Jun 8, 2026 at 1:50 AM Linus Walleij <linusw@kernel.org> wrote:
> Have you tested this on real hardware?
> The commit doesn't really say.
No, I haven't. I can try to test it in GXemul, but I'm not sure if it
can boot Linux. The developer only lists it as capable of booting
NetBSD.
Ethan
^ permalink raw reply
* [PATCH] HID: hiddev: Use kref to track struct hiddev lifetime
From: Heitor Alves de Siqueira @ 2026-06-08 16:33 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: kernel-dev, linux-usb, linux-input, linux-kernel,
syzbot+563191a4939ddbfe73d4
If a USB HID device is disconnected while userspace still holds the
hiddev node open, hiddev_disconnect() and hiddev_release() can race on
the embedded existancelock mutex. Syzbot has triggered this with kfree()
happening during the mutex slow path.
Fix by introducing a kref in struct hiddev, and moving kfree() into a
dedicated release callback. This way, struct hiddev will only be freed
after both hiddev_release() and hiddev_disconnect() are done.
Fixes: 6cb4b040795c ("HID: hiddev: fix race between hiddev_disconnect and hiddev_release")
Reported-by: syzbot+563191a4939ddbfe73d4@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=563191a4939ddbfe73d4
Signed-off-by: Heitor Alves de Siqueira <halves@igalia.com>
---
drivers/hid/usbhid/hiddev.c | 36 ++++++++++++++++++++++++------------
include/linux/hiddev.h | 1 +
2 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
index 6378801b22c6..1f2802920bee 100644
--- a/drivers/hid/usbhid/hiddev.c
+++ b/drivers/hid/usbhid/hiddev.c
@@ -46,6 +46,13 @@ struct hiddev_list {
struct mutex thread_lock;
};
+static void hiddev_kref_free(struct kref *kref)
+{
+ struct hiddev *hiddev = container_of(kref, struct hiddev, kref);
+
+ kfree(hiddev);
+}
+
/*
* Find a report, given the report's type and ID. The ID can be specified
* indirectly by REPORT_ID_FIRST (which returns the first report of the given
@@ -227,15 +234,11 @@ static int hiddev_release(struct inode * inode, struct file * file)
if (list->hiddev->exist) {
hid_hw_close(list->hiddev->hid);
hid_hw_power(list->hiddev->hid, PM_HINT_NORMAL);
- } else {
- mutex_unlock(&list->hiddev->existancelock);
- kfree(list->hiddev);
- vfree(list);
- return 0;
}
}
-
mutex_unlock(&list->hiddev->existancelock);
+
+ kref_put(&list->hiddev->kref, hiddev_kref_free);
vfree(list);
return 0;
@@ -298,10 +301,20 @@ static int hiddev_open(struct inode *inode, struct file *file)
hid = usb_get_intfdata(intf);
hiddev = hid->hiddev;
+ /*
+ * kref_get_unless_zero() checks if we've already dropped
+ * the last reference; bail out early in this case
+ */
+ if (!hiddev || !kref_get_unless_zero(&hiddev->kref))
+ return -ENODEV;
+
mutex_lock(&hiddev->existancelock);
res = hiddev->exist ? __hiddev_open(hiddev, file) : -ENODEV;
mutex_unlock(&hiddev->existancelock);
+ if (res < 0)
+ kref_put(&hiddev->kref, hiddev_kref_free);
+
return res;
}
@@ -893,6 +906,7 @@ int hiddev_connect(struct hid_device *hid, unsigned int force)
if (!(hiddev = kzalloc_obj(struct hiddev)))
return -ENOMEM;
+ kref_init(&hiddev->kref);
init_waitqueue_head(&hiddev->wait);
INIT_LIST_HEAD(&hiddev->list);
spin_lock_init(&hiddev->list_lock);
@@ -904,7 +918,7 @@ int hiddev_connect(struct hid_device *hid, unsigned int force)
if (retval) {
hid_err(hid, "Not able to get a minor for this device\n");
hid->hiddev = NULL;
- kfree(hiddev);
+ kref_put(&hiddev->kref, hiddev_kref_free);
return retval;
}
@@ -933,13 +947,11 @@ void hiddev_disconnect(struct hid_device *hid)
mutex_lock(&hiddev->existancelock);
hiddev->exist = 0;
-
if (hiddev->open) {
hid_hw_close(hiddev->hid);
wake_up_interruptible(&hiddev->wait);
- mutex_unlock(&hiddev->existancelock);
- } else {
- mutex_unlock(&hiddev->existancelock);
- kfree(hiddev);
}
+ mutex_unlock(&hiddev->existancelock);
+
+ kref_put(&hiddev->kref, hiddev_kref_free);
}
diff --git a/include/linux/hiddev.h b/include/linux/hiddev.h
index 2164c03d2c72..1613c9c37ab7 100644
--- a/include/linux/hiddev.h
+++ b/include/linux/hiddev.h
@@ -24,6 +24,7 @@ struct hiddev {
int minor;
int exist;
int open;
+ struct kref kref;
struct mutex existancelock;
wait_queue_head_t wait;
struct hid_device *hid;
---
base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
change-id: 20260603-hiddev_kref-52f5507d4e42
Best regards,
--
Heitor Alves de Siqueira <halves@igalia.com>
^ permalink raw reply related
* Re: [PATCH 2/9] iio: orientation: hid-sensor-incl-3d: Fix race between callback registration and device exposure
From: Pandruvada, Srinivas @ 2026-06-08 15:34 UTC (permalink / raw)
To: dlechner@baylibre.com, archana.patni@linux.intel.com,
hongyan.song@intel.com, nuno.sa@analog.com, jic23@kernel.org,
jikos@kernel.org, andy@kernel.org, sanjayembeddedse@gmail.com
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org
In-Reply-To: <20260606-5-june-hid-iio-race-fixes-v1-2-27a848c5758f@gmail.com>
On Sat, 2026-06-06 at 17:07 +0530, Sanjay Chitroda wrote:
> From: Sanjay Chitroda <sanjayembeddedse@gmail.com>
>
> The driver registers the IIO device before completing sensor hub
> callback registration and unregisters callbacks while the IIO device
> is still exposed during teardown.
>
> This creates race windows in both probe and remove paths, which can
> lead to NULL pointer dereferences or use-after-free.
Reordering is fine, but can you show how this use after free is
possible?
Thanks,
Srinivas
>
> Fix this by correct ordering of callback registration and
> IIO device registration in probe and remove paths.
>
> Fixes: 098d3beccfb6 ("iio: hid-sensors: Added Inclinometer 3D")
> Signed-off-by: Sanjay Chitroda <sanjayembeddedse@gmail.com>
> ---
> drivers/iio/orientation/hid-sensor-incl-3d.c | 20 ++++++++++--------
> --
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iio/orientation/hid-sensor-incl-3d.c
> b/drivers/iio/orientation/hid-sensor-incl-3d.c
> index 4e23a598a3fb..5e3d2bb9b5bf 100644
> --- a/drivers/iio/orientation/hid-sensor-incl-3d.c
> +++ b/drivers/iio/orientation/hid-sensor-incl-3d.c
> @@ -356,12 +356,6 @@ static int hid_incl_3d_probe(struct
> platform_device *pdev)
> return ret;
> }
>
> - ret = iio_device_register(indio_dev);
> - if (ret) {
> - dev_err(&pdev->dev, "device register failed\n");
> - goto error_remove_trigger;
> - }
> -
> incl_state->callbacks.send_event = incl_3d_proc_event;
> incl_state->callbacks.capture_sample =
> incl_3d_capture_sample;
> incl_state->callbacks.pdev = pdev;
> @@ -370,13 +364,19 @@ static int hid_incl_3d_probe(struct
> platform_device *pdev)
> &incl_state->callbacks);
> if (ret) {
> dev_err(&pdev->dev, "callback reg failed\n");
> - goto error_iio_unreg;
> + goto error_remove_trigger;
> + }
> +
> + ret = iio_device_register(indio_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "device register failed\n");
> + goto error_remove_callback;
> }
>
> return 0;
>
> -error_iio_unreg:
> - iio_device_unregister(indio_dev);
> +error_remove_callback:
> + sensor_hub_remove_callback(hsdev,
> HID_USAGE_SENSOR_INCLINOMETER_3D);
> error_remove_trigger:
> hid_sensor_remove_trigger(indio_dev, &incl_state-
> >common_attributes);
> return ret;
> @@ -389,8 +389,8 @@ static void hid_incl_3d_remove(struct
> platform_device *pdev)
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> struct incl_3d_state *incl_state = iio_priv(indio_dev);
>
> - sensor_hub_remove_callback(hsdev,
> HID_USAGE_SENSOR_INCLINOMETER_3D);
> iio_device_unregister(indio_dev);
> + sensor_hub_remove_callback(hsdev,
> HID_USAGE_SENSOR_INCLINOMETER_3D);
> hid_sensor_remove_trigger(indio_dev, &incl_state-
> >common_attributes);
> }
>
^ permalink raw reply
* Re: [PATCH 1/7] iio: gyro: hid-sensor-gyro-3d: use u32 instead of unsigned
From: Andy Shevchenko @ 2026-06-08 13:58 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada, David Lechner,
Nuno Sá, Andy Shevchenko, linux-input, linux-iio,
linux-kernel
In-Reply-To: <20260606-6-june-hid-iio-correct-usage-id-v1-1-dd4a6820b674@gmail.com>
On Sat, Jun 06, 2026 at 05:47:42PM +0530, Sanjay Chitroda wrote:
> Prefer 'u32' instead of bare 'unsigned' variable to improve code
> clarity and consistency with kernel style.
...
> /* Callback handler to send event after all samples are received and captured */
> static int gyro_3d_proc_event(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> void *priv)
It still has an indentation issue and I dunno if it's okay to solve at the same
time. Jonathan?
...
> static int gyro_3d_capture_sample(struct hid_sensor_hub_device *hsdev,
> - unsigned usage_id,
> + u32 usage_id,
> size_t raw_len, char *raw_data,
> void *priv)
Ditto.
...
> static int gyro_3d_parse_report(struct platform_device *pdev,
> struct hid_sensor_hub_device *hsdev,
> struct iio_chan_spec *channels,
> - unsigned usage_id,
> + u32 usage_id,
> struct gyro_3d_state *st)
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/9] HID: iio: Fix race condition between callback registration and device exposure
From: Andy Shevchenko @ 2026-06-08 13:56 UTC (permalink / raw)
To: Sanjay Chitroda
Cc: Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada, David Lechner,
Nuno Sá, Andy Shevchenko, Archana Patni, Song Hongyan,
linux-input, linux-iio, linux-kernel, srinivas pandruvada
In-Reply-To: <20260606-5-june-hid-iio-race-fixes-v1-0-27a848c5758f@gmail.com>
On Sat, Jun 06, 2026 at 05:07:09PM +0530, Sanjay Chitroda wrote:
> Hi all,
>
> This series fixes a race condition in HID IIO drivers related to the
> ordering between callback registration and device exposure.
>
> Currently, several HID IIO drivers register the IIO device (making it
> visible to userspace and other kernel consumers) before all required
> callbacks and resources are fully initialized, or rely on devm-based
> cleanup in a way that does not guarantee correct teardown ordering.
> This creates a window where the device can be accessed while it is
> not fully initialized or is being torn down, potentially leading NULL
> dereference or use-after-free.
>
> To address this, the series ensures that:
> - All required callbacks and resources are set up before the device
> is registered with the IIO core
> - Resource cleanup is performed explicitly where ordering matters
>
> PS: This is prepratory series to convert all HID IIO driver to devm.
I haven't found anything problematic, but still would be nice if somebody can
reproduce the issue and test this fix. Code wise LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 8/8] Input: cap11xx - add support for CAP1114
From: Jun Yan @ 2026-06-08 13:37 UTC (permalink / raw)
To: sashiko-bot
Cc: conor+dt, devicetree, dmitry.torokhov, jerrysteve1101,
linux-input, robh, sashiko-reviews
In-Reply-To: <20260606152056.B77161F00893@smtp.kernel.org>
> Thank you for your contribution! Sashiko AI review found 3 potential issue(=
> s) to consider:
> - [High] Buffer overflow when reading the 'microchip,calib-sensitivity' dev=
> ice tree property for devices with >8 channels.
> - [High] Failure to mask `STATUS1` before ORing `STATUS2` can cause phantom=
> key presses for channels 7 and 8.
> - [Low] Bitmask calculation for 'microchip,signal-guard' truncates settings=
> for channels 8 and above.
> --
>
> commit 8885b1d0f98cb8d5ca53ba5fd9a458743481d5be
> Author: Jun Yan <jerrysteve1101@gmail.com>
>
> Input: cap11xx - add support for CAP1114
>
> CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
> and hardware reset support. The CAP1114 uses two separate control registers
> for LED output management and requires two button status registers for touch
> input state reporting.
>
> > diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/ca=
> p11xx.c
> > index 408880cf65167..2aba3b508947d 100644
> > --- a/drivers/input/keyboard/cap11xx.c
> > +++ b/drivers/input/keyboard/cap11xx.c
>
> [ ... ]
>
> > @@ -311,6 +337,20 @@ static irqreturn_t cap11xx_thread_func(int irq_num, =
> void *data)
> > if (ret < 0)
> > goto out;
> > =20
> > + if (priv->model->num_channels > 8) {
> > + unsigned int status2;
> > +
> > + ret =3D regmap_read(priv->regmap, priv->model->sensor_input_reg_base +=
> 1, &status2);
> > + if (ret < 0)
> > + goto out;
> > +
> > + /*
> > + * CAP1114 STATUS1 register only contains data for the first 6 channel=
> s.
> > + * the remaining channels is stored in STATUS2.
> > + */
> > + status |=3D FIELD_PREP(GENMASK(13, 6), status2);
>
> [Severity: High]
> If the hardware sets reserved bits 6 or 7 in the first status register to 1,
> will they be preserved and incorrectly reported as touch events for channels
> 7 and 8?
>
> Since the status variable (which holds STATUS1) is not masked before this OR
> operation, any reserved bits set in STATUS1 could overlap with the shifted
> status2 values.
>
> Should the status variable be masked to clear bits 6 and 7 before ORing in
> status2?
>
Thanks. Will mask bits 6/7 via status &= GENMASK(5, 0) after reading STATUS1 in v2.
> > + }
> > +
> > for (i =3D 0; i < priv->idev->keycodemax; i++)
>
> [ ... ]
>
> > @@ -572,6 +625,14 @@ static const struct cap11xx_hw_model cap1106_model =
> =3D {
> > .has_repeat_en =3D true,
> > };
> > =20
> > +static const struct cap11xx_hw_model cap1114_model =3D {
> > + .product_id =3D 0x3a,
> > + .led_output_control_reg_base =3D CAP1114_REG_LED_OUTPUT_CONTROL1,
> > + .sensor_input_reg_base =3D CAP1114_REG_BUTTON_STATUS1,
> > + .num_channels =3D 14, .num_leds =3D 11, .num_sensor_thresholds =3D 8,
>
> [Severity: High]
> Does configuring num_channels to 14 cause a buffer overflow when parsing the
> device tree?
>
> In struct cap11xx_priv, calib_sensitivities is defined as a fixed 8-element
> array:
>
> struct cap11xx_priv {
> ...
> u32 calib_sensitivities[8];
> u32 keycodes[];
> };
>
> When cap11xx_init_keys() parses the microchip,calib-sensitivity property, it
> requests num_channels elements:
>
> of_property_read_u32_array(node, "microchip,calib-sensitivity",
> priv->calib_sensitivities,
> priv->model->num_channels)
>
> If the device tree provides 14 elements, won't this write 56 bytes into the
> 32-byte array, overflowing into the adjacent keycodes flexible array?
>
> [Severity: Low]
> Additionally, does setting num_channels to 14 cause truncation in the
> microchip,signal-guard bitmask logic?
>
> In cap11xx_init_keys(), priv->signal_guard_inputs_mask is typed as a u8, but
> the initialization loop runs up to num_channels:
I will exclude CAP1114 from using microchip,calib-sensitivity and microchip,
signal-guard in the dt-bindings to resolve these two issues in V2.
>
> if (u32_val)
> priv->signal_guard_inputs_mask |=3D 0x01 << i;
>
> For i >=3D 8, does the shifted bit exceed the 8-bit width and get silently
> truncated to 0 during the assignment?
>
> > + .has_grouped_sensors =3D true,
> > +};
> > +
>
> --=20
> Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260606150458.2506=
> 06-1-jerrysteve1101@gmail.com?part=3D8
^ permalink raw reply
* Re: [PATCH 7/8] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Jun Yan @ 2026-06-08 13:27 UTC (permalink / raw)
To: sashiko-bot
Cc: conor+dt, devicetree, dmitry.torokhov, jerrysteve1101,
linux-input, robh, sashiko-reviews
In-Reply-To: <20260606151658.60E2C1F00893@smtp.kernel.org>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(=
> s) to consider:
> - [Medium] The new `microchip,cap1114` compatible string was omitted from t=
> he `if-then` conditional block that restricts `microchip,signal-guard` and =
> `microchip,calib-sensitivity` for prior CAP11xx generations.
> --
>
> commit 5c58a6baee363da7434a9782efa913c250015130
> Author: Jun Yan <jerrysteve1101@gmail.com>
>
> dt-bindings: input: microchip,cap11xx: Add CAP1114 support
>
> This commit adds device tree binding support for the CAP1114 capacitive
> touch sensor. It updates the compatible string list, maximum LED channel
> counts, and keycode entries.
>
> > diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.ya=
> ml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> > index e307628350c24..08233386a4336 100644
> > --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> > +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> [ ... ]
> > @@ -26,6 +27,7 @@ properties:
> > compatible:
> > enum:
> > - microchip,cap1106
> > + - microchip,cap1114
> > - microchip,cap1126
> > - microchip,cap1188
> > - microchip,cap1203
>
> [Severity: Medium]
> Since microchip,cap1114 is being added here, could this validation
> regression be avoided by also appending it to the if-then conditional
> block further down the schema that restricts microchip,signal-guard and
> microchip,calib-sensitivity?
>
Good catch. CAP1114 doesn't support these features, so I'll add it to the if-then block in v2.
>
> Documentation/devicetree/bindings/input/microchip,cap11xx.yaml:
> - if:
> properties:
> compatible:
> contains:
> enum:
> - microchip,cap1106
> - microchip,cap1126
> - microchip,cap1188
> - microchip,cap1203
> - microchip,cap1206
> then:
> properties:
> microchip,signal-guard: false
> microchip,calib-sensitivity: false
>
> Since the maxItems for these properties remains at 8 (and CAP1114 has 14
> channels), it appears CAP1114 does not support them either. Omitting the
> new compatible string from this block allows device trees with these
> unsupported properties to pass schema validation.
>
> --=20
> Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260606150458.2506=
> 06-1-jerrysteve1101@gmail.com?part=3D7
^ 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