* Re: [PATCH] dt-bindings: input: matrix-keymap: fix key board wording
From: Dmitry Torokhov @ 2026-03-23 21:45 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Olof Johansson,
Hugo Villeneuve, linux-input, devicetree, linux-kernel
In-Reply-To: <20260323140024.104475-1-hugo@hugovil.com>
On Mon, Mar 23, 2026 at 10:00:21AM -0400, Hugo Villeneuve wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> The correct wording is keyboard, without a space.
The driver is often used for handling sets of keys or buttons, keypads,
etc, not full keyboards. So I am not sure if I can get fully behind this
statement.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: roccat: fix use-after-free in roccat_report_event
From: Silvan Jegen @ 2026-03-23 20:32 UTC (permalink / raw)
To: FirstName LastName
Cc: Stefan Achatz, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel, Benoît Sevens
In-Reply-To: <20260323161107.3478633-1-bsevens@google.com>
Hi
Thanks for the patch! One comment below.
FirstName LastName <bsevens@google.com> wrote:
> From: Benoît Sevens <bsevens@google.com>
>
> roccat_report_event() iterates over the device->readers list without
> holding the readers_lock. This allows a concurrent roccat_release() to
> remove and free a reader while it's still being accessed, leading to a
> use-after-free.
>
> Protect the readers list traversal with the readers_lock mutex.
>
> Signed-off-by: Benoît Sevens <bsevens@google.com>
> ---
> drivers/hid/hid-roccat.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/hid/hid-roccat.c b/drivers/hid/hid-roccat.c
> index fd0ea52f7cba..d6fff53d4ee7 100644
> --- a/drivers/hid/hid-roccat.c
> +++ b/drivers/hid/hid-roccat.c
> @@ -257,6 +257,7 @@ int roccat_report_event(int minor, u8 const *data)
> if (!new_value)
> return -ENOMEM;
>
> + mutex_lock(&device->readers_lock);
As the readers are only accessed later, we could move the locking further
down. Not sure if it's worth it in this case.
Other than that this LGTM!
Reviewed-by: Silvan Jegen <s.jegen@gmail.com>
Cheers,
Silvan
> mutex_lock(&device->cbuf_lock);
>
> report = &device->cbuf[device->cbuf_end];
> @@ -279,6 +280,7 @@ int roccat_report_event(int minor, u8 const *data)
> }
>
> mutex_unlock(&device->cbuf_lock);
> + mutex_unlock(&device->readers_lock);
>
> wake_up_interruptible(&device->wait);
> return 0;
^ permalink raw reply
* Re: [PATCH] HID: pulsar: add driver for Pulsar gaming mice
From: Nikolas Koesling @ 2026-03-23 19:50 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Leo; +Cc: linux-input, linux-kernel
In-Reply-To: <bfb2bcd2-d484-40b3-a548-ccdb6c88a75d@managarm.org>
Hi Leo,
thanks for testing and for the detailed feedback.
> I did some digging into the protocol, and from what I can tell it is
> not necessarily associated with the specific sensor, as multiple mice
> with differing sensors speak the same protocol (PAW3950 to name one).
> The nrf52840 also does not seem to be limited to this protocol. I can't
> find a public name for the protocol. Given that and that I'm not sure
> what the subsystem's policy on module naming is, but I would assume
> that changing them after the fact is not ideal. Probably (?) the
> optimal solution would be to integrate your patch (thank you!) with the
> existing hid-kysona driver; maybe a maintainer should weigh in on that.
Same here, I could not find a public name for the protocol either.
I will either fold it into hid-kysona or keep hid-pulsar, depending
on what a maintainer suggests.
> I added my mouse's ID (3554:F58F) to the list and tested the patch.
> Everything behaved as expected, UPower output looks reasonable. If you
> like, you can amend the device ID to your patch.
Will include it in v2.
Kind regards,
Nikolas
^ permalink raw reply
* [PATCH] HID: roccat: fix use-after-free in roccat_report_event
From: FirstName LastName @ 2026-03-23 16:11 UTC (permalink / raw)
To: Stefan Achatz, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Benoît Sevens
From: Benoît Sevens <bsevens@google.com>
roccat_report_event() iterates over the device->readers list without
holding the readers_lock. This allows a concurrent roccat_release() to
remove and free a reader while it's still being accessed, leading to a
use-after-free.
Protect the readers list traversal with the readers_lock mutex.
Signed-off-by: Benoît Sevens <bsevens@google.com>
---
drivers/hid/hid-roccat.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-roccat.c b/drivers/hid/hid-roccat.c
index fd0ea52f7cba..d6fff53d4ee7 100644
--- a/drivers/hid/hid-roccat.c
+++ b/drivers/hid/hid-roccat.c
@@ -257,6 +257,7 @@ int roccat_report_event(int minor, u8 const *data)
if (!new_value)
return -ENOMEM;
+ mutex_lock(&device->readers_lock);
mutex_lock(&device->cbuf_lock);
report = &device->cbuf[device->cbuf_end];
@@ -279,6 +280,7 @@ int roccat_report_event(int minor, u8 const *data)
}
mutex_unlock(&device->cbuf_lock);
+ mutex_unlock(&device->readers_lock);
wake_up_interruptible(&device->wait);
return 0;
--
2.53.0.959.g497ff81fa9-goog
^ permalink raw reply related
* [PATCH 6.1 078/481] HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them
From: Greg Kroah-Hartman @ 2026-03-23 13:41 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Jiri Kosina, Benjamin Tissoires,
Bastien Nocera, linux-input, stable
In-Reply-To: <20260323134525.256603107@linuxfoundation.org>
6.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ecfa6f34492c493a9a1dc2900f3edeb01c79946b upstream.
In commit 2ff5baa9b527 ("HID: appleir: Fix potential NULL dereference at
raw event handle"), we handle the fact that raw event callbacks
can happen even for a HID device that has not been "claimed" causing a
crash if a broken device were attempted to be connected to the system.
Fix up the remaining in-tree HID drivers that forgot to add this same
check to resolve the same issue.
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: Bastien Nocera <hadess@hadess.net>
Cc: linux-input@vger.kernel.org
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_2000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-cmedia.c | 2 +-
drivers/hid/hid-creative-sb0540.c | 2 +-
drivers/hid/hid-zydacron.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/hid/hid-cmedia.c
+++ b/drivers/hid/hid-cmedia.c
@@ -99,7 +99,7 @@ static int cmhid_raw_event(struct hid_de
{
struct cmhid *cm = hid_get_drvdata(hid);
- if (len != CM6533_JD_RAWEV_LEN)
+ if (len != CM6533_JD_RAWEV_LEN || !(hid->claimed & HID_CLAIMED_INPUT))
goto out;
if (memcmp(data+CM6533_JD_SFX_OFFSET, ji_sfx, sizeof(ji_sfx)))
goto out;
--- a/drivers/hid/hid-creative-sb0540.c
+++ b/drivers/hid/hid-creative-sb0540.c
@@ -153,7 +153,7 @@ static int creative_sb0540_raw_event(str
u64 code, main_code;
int key;
- if (len != 6)
+ if (len != 6 || !(hid->claimed & HID_CLAIMED_INPUT))
return 0;
/* From daemons/hw_hiddev.c sb0540_rec() in lirc */
--- a/drivers/hid/hid-zydacron.c
+++ b/drivers/hid/hid-zydacron.c
@@ -114,7 +114,7 @@ static int zc_raw_event(struct hid_devic
unsigned key;
unsigned short index;
- if (report->id == data[0]) {
+ if (report->id == data[0] && (hdev->claimed & HID_CLAIMED_INPUT)) {
/* break keys */
for (index = 0; index < 4; index++) {
^ permalink raw reply
* [PATCH v2 11/19] HID: Use trace_call__##name() at guarded tracepoint call sites
From: Vineeth Pillai (Google) @ 2026-03-23 16:00 UTC (permalink / raw)
Cc: Vineeth Pillai (Google), Steven Rostedt, Peter Zijlstra,
Srinivas Pandruvada, Jiri Kosina, Benjamin Tissoires, Zhang Lixu,
Andy Shevchenko, linux-input, linux-kernel, linux-trace-kernel
In-Reply-To: <20260323160052.17528-1-vineeth@bitbyteword.org>
Replace trace_foo() with the new trace_call__foo() at sites already
guarded by trace_foo_enabled(), avoiding a redundant
static_branch_unlikely() re-evaluation inside the tracepoint.
trace_call__foo() calls the tracepoint callbacks directly without
utilizing the static branch again.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index ed3405c05e73c..8d36ae96a3eea 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -110,7 +110,7 @@ void ish_event_tracer(struct ishtp_device *dev, const char *format, ...)
vsnprintf(tmp_buf, sizeof(tmp_buf), format, args);
va_end(args);
- trace_ishtp_dump(tmp_buf);
+ trace_call__ishtp_dump(tmp_buf);
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 01/19] tracepoint: Add trace_call__##name() API
From: Vineeth Pillai (Google) @ 2026-03-23 16:00 UTC (permalink / raw)
To: Steven Rostedt, Peter Zijlstra, Dmitry Ilvokhin
Cc: Vineeth Pillai (Google), Masami Hiramatsu, Mathieu Desnoyers,
Ingo Molnar, Jens Axboe, io-uring, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
Marcelo Ricardo Leitner, Xin Long, Jon Maloy, Aaron Conole,
Eelco Chaudron, Ilya Maximets, netdev, bpf, linux-sctp,
tipc-discussion, dev, Jiri Pirko, Oded Gabbay, Koby Elbaz,
dri-devel, Rafael J. Wysocki, Viresh Kumar, Gautham R. Shenoy,
Huang Rui, Mario Limonciello, Len Brown, Srinivas Pandruvada,
linux-pm, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
Christian König, Sumit Semwal, linaro-mm-sig, Eddie James,
Andrew Jeffery, Joel Stanley, linux-fsi, David Airlie,
Simona Vetter, Alex Deucher, Danilo Krummrich, Matthew Brost,
Philipp Stanner, Harry Wentland, Leo Li, amd-gfx, Jiri Kosina,
Benjamin Tissoires, linux-input, Wolfram Sang, linux-i2c,
Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, Thomas Gleixner, Andrew Morton,
SeongJae Park, linux-mm, Borislav Petkov, Dave Hansen, x86,
linux-trace-kernel, linux-kernel
In-Reply-To: <20260323160052.17528-1-vineeth@bitbyteword.org>
Add trace_call__##name() as a companion to trace_##name(). When a
caller already guards a tracepoint with an explicit enabled check:
if (trace_foo_enabled() && cond)
trace_foo(args);
trace_foo() internally repeats the static_branch_unlikely() test, which
the compiler cannot fold since static branches are patched binary
instructions. This results in two static-branch evaluations for every
guarded call site.
trace_call__##name() calls __do_trace_##name() directly, skipping the
redundant static-branch re-check. This avoids leaking the internal
__do_trace_##name() symbol into call sites while still eliminating the
double evaluation:
if (trace_foo_enabled() && cond)
trace_invoke_foo(args); /* calls __do_trace_foo() directly */
Three locations are updated:
- __DECLARE_TRACE: invoke form omits static_branch_unlikely, retains
the LOCKDEP RCU-watching assertion.
- __DECLARE_TRACE_SYSCALL: same, plus retains might_fault().
- !TRACEPOINTS_ENABLED stub: empty no-op so callers compile cleanly
when tracepoints are compiled out.
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
Assisted-by: Claude:claude-sonnet-4-6
---
include/linux/tracepoint.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 22ca1c8b54f32..ed969705341f1 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -294,6 +294,10 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
WARN_ONCE(!rcu_is_watching(), \
"RCU not watching for tracepoint"); \
} \
+ } \
+ static inline void trace_call__##name(proto) \
+ { \
+ __do_trace_##name(args); \
}
#define __DECLARE_TRACE_SYSCALL(name, proto, args, data_proto) \
@@ -313,6 +317,11 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
WARN_ONCE(!rcu_is_watching(), \
"RCU not watching for tracepoint"); \
} \
+ } \
+ static inline void trace_call__##name(proto) \
+ { \
+ might_fault(); \
+ __do_trace_##name(args); \
}
/*
@@ -398,6 +407,8 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
#define __DECLARE_TRACE_COMMON(name, proto, args, data_proto) \
static inline void trace_##name(proto) \
{ } \
+ static inline void trace_call__##name(proto) \
+ { } \
static inline int \
register_trace_##name(void (*probe)(data_proto), \
void *data) \
--
2.53.0
^ permalink raw reply related
* [PATCH v2 00/19] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Vineeth Pillai (Google) @ 2026-03-23 16:00 UTC (permalink / raw)
To: Steven Rostedt, Peter Zijlstra, Dmitry Ilvokhin
Cc: Vineeth Pillai (Google), Masami Hiramatsu, Mathieu Desnoyers,
Ingo Molnar, Jens Axboe, io-uring, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
Marcelo Ricardo Leitner, Xin Long, Jon Maloy, Aaron Conole,
Eelco Chaudron, Ilya Maximets, netdev, bpf, linux-sctp,
tipc-discussion, dev, Jiri Pirko, Oded Gabbay, Koby Elbaz,
dri-devel, Rafael J. Wysocki, Viresh Kumar, Gautham R. Shenoy,
Huang Rui, Mario Limonciello, Len Brown, Srinivas Pandruvada,
linux-pm, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
Christian König, Sumit Semwal, linaro-mm-sig, Eddie James,
Andrew Jeffery, Joel Stanley, linux-fsi, David Airlie,
Simona Vetter, Alex Deucher, Danilo Krummrich, Matthew Brost,
Philipp Stanner, Harry Wentland, Leo Li, amd-gfx, Jiri Kosina,
Benjamin Tissoires, linux-input, Wolfram Sang, linux-i2c,
Mark Brown, Michael Hennerich, Nuno Sá, linux-spi,
James E.J. Bottomley, Martin K. Petersen, linux-scsi, Chris Mason,
David Sterba, linux-btrfs, Thomas Gleixner, Andrew Morton,
SeongJae Park, linux-mm, Borislav Petkov, Dave Hansen, x86,
linux-trace-kernel, linux-kernel
When a caller already guards a tracepoint with an explicit enabled check:
if (trace_foo_enabled() && cond)
trace_foo(args);
trace_foo() internally re-evaluates the static_branch_unlikely() key.
Since static branches are patched binary instructions the compiler cannot
fold the two evaluations, so every such site pays the cost twice.
This series introduces trace_call__##name() as a companion to
trace_##name(). It calls __do_trace_##name() directly, bypassing the
redundant static-branch re-check, while preserving all other correctness
properties of the normal path (RCU-watching assertion, might_fault() for
syscall tracepoints). The internal __do_trace_##name() symbol is not
leaked to call sites; trace_call__##name() is the only new public API.
if (trace_foo_enabled() && cond)
trace_call__foo(args); /* calls __do_trace_foo() directly */
The first patch adds the three-location change to
include/linux/tracepoint.h (__DECLARE_TRACE, __DECLARE_TRACE_SYSCALL,
and the !TRACEPOINTS_ENABLED stub). The remaining 18 patches
mechanically convert all guarded call sites found in the tree:
kernel/, io_uring/, net/, accel/habanalabs, cpufreq/, devfreq/,
dma-buf/, fsi/, drm/, HID, i2c/, spi/, scsi/ufs/, btrfs/,
net/devlink/, kernel/time/, kernel/trace/, mm/damon/, and arch/x86/.
This series is motivated by Peter Zijlstra's observation in the discussion
around Dmitry Ilvokhin's locking tracepoint instrumentation series, where
he noted that compilers cannot optimize static branches and that guarded
call sites end up evaluating the static branch twice for no reason, and
by Steven Rostedt's suggestion to add a proper API instead of exposing
internal implementation details like __do_trace_##name() directly to
call sites:
https://lore.kernel.org/linux-trace-kernel/8298e098d3418cb446ef396f119edac58a3414e9.1772642407.git.d@ilvokhin.com
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Changes in v2:
- Renamed trace_invoke_##name() to trace_call__##name() (double
underscore) per review comments.
- Added 4 new patches covering sites missed in v1, found using
coccinelle to scan the tree (Keith Busch):
* net/devlink: guarded tracepoint_enabled() block in trap.c
* kernel/time: early-return guard in tick-sched.c (tick_stop)
* kernel/trace: early-return guard in trace_benchmark.c
* mm/damon: early-return guard in core.c
* arch/x86: do_trace_*() wrapper functions in lib/msr.c, which
are called exclusively from tracepoint_enabled()-guarded sites
in asm/msr.h
v1: https://lore.kernel.org/linux-trace-kernel/abSqrJ1J59RQC47U@kbusch-mbp/
Vineeth Pillai (Google) (19):
tracepoint: Add trace_call__##name() API
kernel: Use trace_call__##name() at guarded tracepoint call sites
io_uring: Use trace_call__##name() at guarded tracepoint call sites
net: Use trace_call__##name() at guarded tracepoint call sites
accel/habanalabs: Use trace_call__##name() at guarded tracepoint call
sites
cpufreq: Use trace_call__##name() at guarded tracepoint call sites
devfreq: Use trace_call__##name() at guarded tracepoint call sites
dma-buf: Use trace_call__##name() at guarded tracepoint call sites
fsi: Use trace_call__##name() at guarded tracepoint call sites
drm: Use trace_call__##name() at guarded tracepoint call sites
HID: Use trace_call__##name() at guarded tracepoint call sites
i2c: Use trace_call__##name() at guarded tracepoint call sites
spi: Use trace_call__##name() at guarded tracepoint call sites
scsi: ufs: Use trace_call__##name() at guarded tracepoint call sites
btrfs: Use trace_call__##name() at guarded tracepoint call sites
net: devlink: Use trace_call__##name() at guarded tracepoint call
sites
kernel: time, trace: Use trace_call__##name() at guarded tracepoint
call sites
mm: damon: Use trace_call__##name() at guarded tracepoint call sites
x86: msr: Use trace_call__##name() at guarded tracepoint call sites
arch/x86/lib/msr.c | 6 +++---
drivers/accel/habanalabs/common/device.c | 12 ++++++------
drivers/accel/habanalabs/common/mmu/mmu.c | 3 ++-
drivers/accel/habanalabs/common/pci/pci.c | 4 ++--
drivers/cpufreq/amd-pstate.c | 10 +++++-----
drivers/cpufreq/cpufreq.c | 2 +-
drivers/cpufreq/intel_pstate.c | 2 +-
drivers/devfreq/devfreq.c | 2 +-
drivers/dma-buf/dma-fence.c | 4 ++--
drivers/fsi/fsi-master-aspeed.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++--
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
drivers/gpu/drm/scheduler/sched_entity.c | 4 ++--
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 2 +-
drivers/i2c/i2c-core-slave.c | 2 +-
drivers/spi/spi-axi-spi-engine.c | 4 ++--
drivers/ufs/core/ufshcd.c | 12 ++++++------
fs/btrfs/extent_map.c | 4 ++--
fs/btrfs/raid56.c | 4 ++--
include/linux/tracepoint.h | 11 +++++++++++
io_uring/io_uring.h | 2 +-
kernel/irq_work.c | 2 +-
kernel/sched/ext.c | 2 +-
kernel/smp.c | 2 +-
kernel/time/tick-sched.c | 12 ++++++------
kernel/trace/trace_benchmark.c | 2 +-
mm/damon/core.c | 2 +-
net/core/dev.c | 2 +-
net/core/xdp.c | 2 +-
net/devlink/trap.c | 2 +-
net/openvswitch/actions.c | 2 +-
net/openvswitch/datapath.c | 2 +-
net/sctp/outqueue.c | 2 +-
net/tipc/node.c | 2 +-
35 files changed, 74 insertions(+), 62 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH 6.6 099/567] HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them
From: Greg Kroah-Hartman @ 2026-03-23 13:40 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Jiri Kosina, Benjamin Tissoires,
Bastien Nocera, linux-input, stable
In-Reply-To: <20260323134533.749096647@linuxfoundation.org>
6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ecfa6f34492c493a9a1dc2900f3edeb01c79946b upstream.
In commit 2ff5baa9b527 ("HID: appleir: Fix potential NULL dereference at
raw event handle"), we handle the fact that raw event callbacks
can happen even for a HID device that has not been "claimed" causing a
crash if a broken device were attempted to be connected to the system.
Fix up the remaining in-tree HID drivers that forgot to add this same
check to resolve the same issue.
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: Bastien Nocera <hadess@hadess.net>
Cc: linux-input@vger.kernel.org
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_2000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hid/hid-cmedia.c | 2 +-
drivers/hid/hid-creative-sb0540.c | 2 +-
drivers/hid/hid-zydacron.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/hid/hid-cmedia.c
+++ b/drivers/hid/hid-cmedia.c
@@ -99,7 +99,7 @@ static int cmhid_raw_event(struct hid_de
{
struct cmhid *cm = hid_get_drvdata(hid);
- if (len != CM6533_JD_RAWEV_LEN)
+ if (len != CM6533_JD_RAWEV_LEN || !(hid->claimed & HID_CLAIMED_INPUT))
goto out;
if (memcmp(data+CM6533_JD_SFX_OFFSET, ji_sfx, sizeof(ji_sfx)))
goto out;
--- a/drivers/hid/hid-creative-sb0540.c
+++ b/drivers/hid/hid-creative-sb0540.c
@@ -153,7 +153,7 @@ static int creative_sb0540_raw_event(str
u64 code, main_code;
int key;
- if (len != 6)
+ if (len != 6 || !(hid->claimed & HID_CLAIMED_INPUT))
return 0;
/* From daemons/hw_hiddev.c sb0540_rec() in lirc */
--- a/drivers/hid/hid-zydacron.c
+++ b/drivers/hid/hid-zydacron.c
@@ -114,7 +114,7 @@ static int zc_raw_event(struct hid_devic
unsigned key;
unsigned short index;
- if (report->id == data[0]) {
+ if (report->id == data[0] && (hdev->claimed & HID_CLAIMED_INPUT)) {
/* break keys */
for (index = 0; index < 4; index++) {
^ permalink raw reply
* Re: (subset) [PATCH v8 0/2] Add support for sound profile switching and leverage for OnePlus slider
From: Bjorn Andersson @ 2026-03-23 14:50 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Jiri Kosina, Benjamin Tissoires,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Casey Connolly, Guido Günther, David Heidelberg
Cc: linux-input, linux-doc, linux-kernel, linux-arm-msm, devicetree,
phone-devel, Gergo Koteles, Casey Connolly
In-Reply-To: <20251113-op6-tri-state-v8-0-54073f3874bc@ixit.cz>
On Thu, 13 Nov 2025 17:02:57 +0100, David Heidelberg wrote:
> This series add initial support for OnePlus 6 and 6T, but other OnePlus
> phones contains same mechanism to switch sound profiles.
>
> This code was tested for two years within the downstream Snapdragon 845 tree.
> It is now perfectly integrated with feedbackd in the Phosh environment.
>
> The series is also available (until merged) at
> https://gitlab.com/sdm845/sdm845-next/-/commits/b4/op6-tri-state
>
> [...]
Applied, thanks!
[2/2] arm64: dts: qcom: sdm845-oneplus: Add alert-slider
commit: ca5adb26c5927f28016c6b1778622dee9ada5ca0
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* [PATCH] dt-bindings: input: matrix-keymap: fix key board wording
From: Hugo Villeneuve @ 2026-03-23 14:00 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Olof Johansson
Cc: hugo, Hugo Villeneuve, linux-input, devicetree, linux-kernel
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
The correct wording is keyboard, without a space.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
Documentation/devicetree/bindings/input/matrix-keymap.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.yaml b/Documentation/devicetree/bindings/input/matrix-keymap.yaml
index a715c2a773fe..ce910e4ac823 100644
--- a/Documentation/devicetree/bindings/input/matrix-keymap.yaml
+++ b/Documentation/devicetree/bindings/input/matrix-keymap.yaml
@@ -4,13 +4,13 @@
$id: http://devicetree.org/schemas/input/matrix-keymap.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Common Key Matrices on Matrix-connected Key Boards
+title: Common Key Matrices on Matrix-connected Keyboards
maintainers:
- Olof Johansson <olof@lixom.net>
description: |
- A simple common binding for matrix-connected key boards. Currently targeted at
+ A simple common binding for matrix-connected keyboards. Currently targeted at
defining the keys in the scope of linux key codes since that is a stable and
standardized interface at this time.
base-commit: c369299895a591d96745d6492d4888259b004a9e
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] Input: penmount: bound packet buffer indices in IRQ path
From: Andy Shevchenko @ 2026-03-23 13:32 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: dmitry.torokhov, kees, linux-input, linux-kernel
In-Reply-To: <20260323121715.74954-1-pengpeng@iscas.ac.cn>
On Mon, Mar 23, 2026 at 08:17:15PM +0800, Pengpeng Hou wrote:
> The IRQ handler stores each incoming byte into pm->data[] before the
> packet parser gets a chance to reset pm->idx. If the incoming serial
> stream never matches one of the expected packet headers, pm->idx can
> advance past the fixed receive buffer and the next IRQ will write beyond
> PM_MAX_LENGTH.
How did you find the issue? Any assistance?
> Reset stale indices before writing the next byte so malformed packet
> streams cannot walk past the end of the local packet buffer.
Why do you think this is the best possible approach? Maybe we should
simply ignore IRQ or handle it without any further actions?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] HID: playstation: validate num_touch_reports in DualShock 4 reports
From: FirstName LastName @ 2026-03-23 12:47 UTC (permalink / raw)
To: Roderick Colenbrander, Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, Benoît Sevens
From: Benoît Sevens <bsevens@google.com>
The DualShock 4 HID driver fails to validate the num_touch_reports field
received from the device in both USB and Bluetooth input reports.
A malicious device could set this field to a value larger than the
allocated size of the touch_reports array (3 for USB, 4 for Bluetooth),
leading to an out-of-bounds read in dualshock4_parse_report().
This can result in kernel memory disclosure when processing malicious
HID reports.
Validate num_touch_reports against the array size for the respective
connection types before processing the touch data.
Signed-off-by: Benoît Sevens <bsevens@google.com>
---
drivers/hid/hid-playstation.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 3c0db8f93c82..c43caac20b61 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -2377,6 +2377,12 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
struct dualshock4_input_report_usb *usb =
(struct dualshock4_input_report_usb *)data;
+ if (usb->num_touch_reports > ARRAY_SIZE(usb->touch_reports)) {
+ hid_err(hdev, "DualShock4 USB input report has invalid num_touch_reports=%d\n",
+ usb->num_touch_reports);
+ return -EINVAL;
+ }
+
ds4_report = &usb->common;
num_touch_reports = usb->num_touch_reports;
touch_reports = usb->touch_reports;
@@ -2391,6 +2397,12 @@ static int dualshock4_parse_report(struct ps_device *ps_dev, struct hid_report *
return -EILSEQ;
}
+ if (bt->num_touch_reports > ARRAY_SIZE(bt->touch_reports)) {
+ hid_err(hdev, "DualShock4 BT input report has invalid num_touch_reports=%d\n",
+ bt->num_touch_reports);
+ return -EINVAL;
+ }
+
ds4_report = &bt->common;
num_touch_reports = bt->num_touch_reports;
touch_reports = bt->touch_reports;
--
2.53.0.959.g497ff81fa9-goog
^ permalink raw reply related
* [PATCH] Input: penmount: bound packet buffer indices in IRQ path
From: Pengpeng Hou @ 2026-03-23 12:17 UTC (permalink / raw)
To: dmitry.torokhov
Cc: andriy.shevchenko, kees, linux-input, linux-kernel, pengpeng
The IRQ handler stores each incoming byte into pm->data[] before the
packet parser gets a chance to reset pm->idx. If the incoming serial
stream never matches one of the expected packet headers, pm->idx can
advance past the fixed receive buffer and the next IRQ will write beyond
PM_MAX_LENGTH.
Reset stale indices before writing the next byte so malformed packet
streams cannot walk past the end of the local packet buffer.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/input/touchscreen/penmount.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/touchscreen/penmount.c b/drivers/input/touchscreen/penmount.c
index 4b57b6664e37..ba09096c6573 100644
--- a/drivers/input/touchscreen/penmount.c
+++ b/drivers/input/touchscreen/penmount.c
@@ -163,6 +163,9 @@ static irqreturn_t pm_interrupt(struct serio *serio,
{
struct pm *pm = serio_get_drvdata(serio);
+ if (pm->idx >= pm->packetsize || pm->idx >= PM_MAX_LENGTH)
+ pm->idx = 0;
+
pm->data[pm->idx] = data;
pm->parse_packet(pm);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v6 4/4] Input: Add TouchNetix aXiom I2C Touchscreen support
From: Andrew Thomas @ 2026-03-23 9:59 UTC (permalink / raw)
To: Marco Felsch
Cc: Luis Chamberlain, Russ Weight, Greg Kroah-Hartman,
Rafael J. Wysocki, Andrew Morton, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Kamel Bouhara,
Marco Felsch, Henrik Rydberg, Danilo Krummrich, linux-kernel,
devicetree, linux-input
In-Reply-To: <enyz3io3i7mzoaquexpkbsjtxmcuib7lxj334ii2yqvdgpvajb@aspqccwo7vnf>
On Fri, Mar 13, 2026 at 08:50:05PM +0100, Marco Felsch wrote:
>Hi Andrew,
>
>thanks for your feedback! Please see below.
>
>On 26-03-13, Andrew Thomas wrote:
>> On Tue, Mar 03, 2026 at 11:41:22PM +0100, Marco Felsch wrote:
>> >This adds the initial support for the TouchNetix AX54A touchcontroller
>> >which is part of TouchNetix's aXiom touchscreen controller family.
>> >
>> >The TouchNetix aXiom family provides two physical interfaces: SPI and
>> >I2C. This patch covers only the I2C interface.
>> >
>> >Apart the input event handling the driver supports firmware updates too.
>> >One firmware interface handles the touchcontroller firmware (AXFW)
>> >update the other handles the touchcontroller configuration (TH2CFGBIN)
>> >update.
>> >
>> >Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
>> >---
>
>...
>
>> >+static int axiom_u02_enter_bootloader(struct axiom_data *ts)
>> >+{
>> >+ struct axiom_u02_rev1_system_manager_msg msg = { };
>> >+ struct device *dev = ts->dev;
>> >+ unsigned int val;
>> >+ int error;
>> >+
>> >+ if (!axiom_driver_supports_usage(ts, AXIOM_U02))
>> >+ return -EINVAL;
>> >+
>> >+ /*
>> >+ * Enter the bootloader mode requires 3 consecutive messages so we can't
>> >+ * check for the response.
>> >+ * TODO: Check if it's required to add a delay between the consecutive
>> >+ * CMD_ENTERBOOTLOADER cmds.
>> >+ */
>> >+ msg.command = cpu_to_le16(AXIOM_U02_REV1_CMD_ENTERBOOTLOADER);
>> >+ msg.parameters[0] = cpu_to_le16(AXIOM_U02_REV1_PARAM0_ENTERBOOLOADER_KEY1);
>> >+ error = axiom_u02_send_msg(ts, &msg, false);
>>
>> As mentioned before the delay between commands is too short and the
>> next command is sent before u02 is ready, which means the driver fails
>> to put axiom into the bootloader.
>
>Please see my comment [1].
>
>> Have you tested with an i2c speed of 400KHz?
>
>Yes, my target platform is based on a i.MX8MP.
>
>> All you need is to put true in above to wait for the bootloader command.
>> error = axiom_u02_send_msg(ts, &msg, true);
>
>Please see my comment [1].
>
>> Just dont do it for the last command.
>
>Please see my comment [1].
>
>> I am not too sure why you are having issues with this, this is how we
>> do it for all our devices.
>
>Please see my comment [1].
>
>On what platform do you perform the tests?
>
>> >+ if (error) {
>> >+ dev_err(dev, "Failed to send bootloader-key1: %d\n", error);
>> >+ return error;
>> >+ }
>> >+
>> >+ msg.parameters[0] = cpu_to_le16(AXIOM_U02_REV1_PARAM0_ENTERBOOLOADER_KEY2);
>> >+ error = axiom_u02_send_msg(ts, &msg, false);
>>
>> Here also.
>
>Please see my comment [1].
>
>> >+ if (error) {
>> >+ dev_err(dev, "Failed to send bootloader-key2: %d\n", error);
>> >+ return error;
>> >+ }
>> >+
>> >+ msg.parameters[0] = cpu_to_le16(AXIOM_U02_REV1_PARAM0_ENTERBOOLOADER_KEY3);
>> >+ error = axiom_u02_send_msg(ts, &msg, false);
>> >+ if (error) {
>> >+ dev_err(dev, "Failed to send bootloader-key3: %d\n", error);
>> >+ return error;
>> >+ }
>> >+
>> >+ /* Sleep before the first read to give the device time */
>> >+ fsleep(250 * USEC_PER_MSEC);
>> >+
>> >+ /* Wait till the device reports it is in bootloader mode */
>> >+ error = regmap_read_poll_timeout(ts->regmap,
>> >+ AXIOM_U31_REV1_DEVICE_ID_HIGH_REG, val,
>> >+ FIELD_GET(AXIOM_U31_REV1_MODE_MASK, val) ==
>> >+ AXIOM_U31_REV1_MODE_BLP,
>> >+ 250 * USEC_PER_MSEC, USEC_PER_SEC);
>> >+ if (error)
>> >+ return error;
>> >+
>> >+ return 0;
>> >+}
>> >+
>>
>> ...
>>
>>
>> Other than the above comments I have no issues with the driver.
>
>If you're fine with the patch you could add your acked-by [2] :)
>
>> We can support more usages in a later patch.
>
>Sure :)
>
>[1] https://lore.kernel.org/all/4x3dnedfzf3rqzsy3wjdoj6yaxmy6kop37xhxeao4vjer7ifdi@35ux42ztq3eb
>[2] https://docs.kernel.org/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
>
>Regards,
> Marco
>--
>#gernperDu
>#CallMeByMyFirstName
>
>Pengutronix e.K. | |
>Steuerwalder Str. 21 | https://www.pengutronix.de |
>31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
>Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Acked-by: Andrew Thomas <andrew.thomas@touchnetix.com>
^ permalink raw reply
* [PATCH] Input: gf2k: clamp hat values to the lookup table
From: Pengpeng Hou @ 2026-03-23 7:45 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, kees, pengpeng
gf2k_read() decodes the hat position from a 4-bit field and uses it
directly to index gf2k_hat_to_axis[]. The lookup table only has nine
entries, so malformed packets can read past the end of the fixed table.
Clamp invalid hat values to the neutral position before indexing the
lookup table.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/input/joystick/gf2k.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/joystick/gf2k.c b/drivers/input/joystick/gf2k.c
index 5a1cdce0bc48..78fba36285dc 100644
--- a/drivers/input/joystick/gf2k.c
+++ b/drivers/input/joystick/gf2k.c
@@ -164,6 +164,8 @@ static void gf2k_read(struct gf2k *gf2k, unsigned char *data)
input_report_abs(dev, gf2k_abs[i], GB(i*9+60,8,0) | GB(i+54,1,9));
t = GB(40,4,0);
+ if (t >= ARRAY_SIZE(gf2k_hat_to_axis))
+ t = 0;
for (i = 0; i < gf2k_hats[gf2k->id]; i++)
input_report_abs(dev, ABS_HAT0X + i, gf2k_hat_to_axis[t][i]);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH 2/7] Input: aiptek: validate macro key indices
From: Pengpeng Hou @ 2026-03-23 7:03 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, pengpeng
aiptek_irq() derives macro key indices directly from tablet reports and
then uses them to index macroKeyEvents[]. Report types 4 and 5 use
(data[3] >> 1), while report type 6 reads a 16-bit macro number from the
packet body. None of those indices are checked against the array bounds
before input_report_key() dereferences them.
Reject out-of-range macro indices at each use site so malformed reports
cannot read past macroKeyEvents[].
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/input/tablet/aiptek.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/input/tablet/aiptek.c b/drivers/input/tablet/aiptek.c
index 6df24cee3c9d..ab5886a9241d 100644
--- a/drivers/input/tablet/aiptek.c
+++ b/drivers/input/tablet/aiptek.c
@@ -676,12 +676,15 @@ static void aiptek_irq(struct urb *urb)
}
}
- if (aiptek->lastMacro != -1 && aiptek->lastMacro != macro) {
+ if (aiptek->lastMacro >= 0 &&
+ aiptek->lastMacro < ARRAY_SIZE(macroKeyEvents) &&
+ aiptek->lastMacro != macro) {
input_report_key(inputdev, macroKeyEvents[aiptek->lastMacro], 0);
aiptek->lastMacro = -1;
}
- if (macro != -1 && macro != aiptek->lastMacro) {
+ if (macro >= 0 && macro < ARRAY_SIZE(macroKeyEvents) &&
+ macro != aiptek->lastMacro) {
input_report_key(inputdev, macroKeyEvents[macro], 1);
aiptek->lastMacro = macro;
}
@@ -715,12 +718,15 @@ static void aiptek_irq(struct urb *urb)
}
}
- if (aiptek->lastMacro != -1 && aiptek->lastMacro != macro) {
+ if (aiptek->lastMacro >= 0 &&
+ aiptek->lastMacro < ARRAY_SIZE(macroKeyEvents) &&
+ aiptek->lastMacro != macro) {
input_report_key(inputdev, macroKeyEvents[aiptek->lastMacro], 0);
aiptek->lastMacro = -1;
}
- if (macro != -1 && macro != aiptek->lastMacro) {
+ if (macro >= 0 && macro < ARRAY_SIZE(macroKeyEvents) &&
+ macro != aiptek->lastMacro) {
input_report_key(inputdev, macroKeyEvents[macro], 1);
aiptek->lastMacro = macro;
}
@@ -737,11 +743,11 @@ static void aiptek_irq(struct urb *urb)
*/
else if (data[0] == 6) {
macro = get_unaligned_le16(data + 1);
- if (macro > 0) {
+ if (macro > 0 && macro - 1 < ARRAY_SIZE(macroKeyEvents)) {
input_report_key(inputdev, macroKeyEvents[macro - 1],
0);
}
- if (macro < 25) {
+ if (macro + 1 < ARRAY_SIZE(macroKeyEvents)) {
input_report_key(inputdev, macroKeyEvents[macro + 1],
0);
}
@@ -760,7 +766,8 @@ static void aiptek_irq(struct urb *urb)
aiptek->curSetting.toolMode;
}
- input_report_key(inputdev, macroKeyEvents[macro], 1);
+ if (macro < ARRAY_SIZE(macroKeyEvents))
+ input_report_key(inputdev, macroKeyEvents[macro], 1);
input_report_abs(inputdev, ABS_MISC,
1 | AIPTEK_REPORT_TOOL_UNKNOWN);
input_sync(inputdev);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH] Input: uinput - fix circular locking dependency with ff-core
From: Mikhail Gavrilov @ 2026-03-23 5:39 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <acDPeFpxX57Uu0Mm@google.com>
On Mon, Mar 23, 2026 at 10:34 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hmm, I am not sure I see the issue. We are not going to change state
> back to UIST_CREATED until after uinput_destroy_device() returns so we
> will not submit more requests...
>
> What am I missing?
You are right, there is no lock ordering issue since the state
transition is one-way.
The reason I reused requests_lock is that uinput_request_send()
needs to atomically check state and access udev->dev. If we use a
separate state_lock and release it before calling
uinput_dev_event(), uinput_destroy_device() could run in between,
unregister the device, and we'd hit a use-after-free on udev->dev.
A separate lock would need to be held across the same scope,
making it functionally equivalent to reusing requests_lock.
--
Best Regards,
Mike Gavrilov.
^ permalink raw reply
* Re: [PATCH] Input: uinput - fix circular locking dependency with ff-core
From: Dmitry Torokhov @ 2026-03-23 5:34 UTC (permalink / raw)
To: Mikhail Gavrilov; +Cc: linux-input, linux-kernel
In-Reply-To: <CABXGCsOwJu2dw67bR38MJb5DFvGon=MUCxKcGEQYfT6qrPZU1w@mail.gmail.com>
On Mon, Mar 23, 2026 at 10:17:01AM +0500, Mikhail Gavrilov wrote:
> On Mon, Mar 23, 2026 at 7:47 AM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > Thank you for the patch, it looks solid, however I wonder if creating a
> > separate "state_lock" spinlock would not be better than reusing
> > requests_lock?
>
> Hi Dmitry,
>
> Thank you for the review.
>
> A separate spinlock would certainly be cleaner from a naming
> perspective. One thing I'd like to note though: the current
> approach of reusing requests_lock has the benefit of atomically
> checking state and queueing the event in uinput_request_send(),
> and atomically changing state and flushing requests in
> uinput_destroy_device(). With a separate state_lock these become
> two independent locks, so the ordering between them would need to
> be defined.
Hmm, I am not sure I see the issue. We are not going to change state
back to UIST_CREATED until after uinput_destroy_device() returns so we
will not submit more requests...
What am I missing?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: uinput - fix circular locking dependency with ff-core
From: Mikhail Gavrilov @ 2026-03-23 5:17 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <acCpW6McaPOE0Jq5@google.com>
On Mon, Mar 23, 2026 at 7:47 AM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Thank you for the patch, it looks solid, however I wonder if creating a
> separate "state_lock" spinlock would not be better than reusing
> requests_lock?
Hi Dmitry,
Thank you for the review.
A separate spinlock would certainly be cleaner from a naming
perspective. One thing I'd like to note though: the current
approach of reusing requests_lock has the benefit of atomically
checking state and queueing the event in uinput_request_send(),
and atomically changing state and flushing requests in
uinput_destroy_device(). With a separate state_lock these become
two independent locks, so the ordering between them would need to
be defined.
That said, if you prefer the cleaner separation I'm happy to make
the change. Please let me know.
--
Best Regards,
Mike Gavrilov.
^ permalink raw reply
* Re: [PATCH 2/3] Input: adafruit-seesaw - add interrupt support
From: Dmitry Torokhov @ 2026-03-23 5:12 UTC (permalink / raw)
To: charles.embedded
Cc: Anshul Dalal, Shuah Khan, Brigham Campbell, linux-input,
linux-kernel, Charles Dias
In-Reply-To: <20260321202446.724277-3-charles.embedded@gmail.com>
Hi Charles,
On Sat, Mar 21, 2026 at 05:24:45PM -0300, charles.embedded@gmail.com wrote:
> @@ -289,6 +341,19 @@ static int seesaw_probe(struct i2c_client *client)
> input_set_max_poll_interval(seesaw->input_dev, SEESAW_GAMEPAD_POLL_MAX);
> input_set_min_poll_interval(seesaw->input_dev, SEESAW_GAMEPAD_POLL_MIN);
>
> + if (client->irq) {
> + err = seesaw_register_write_u32(client, SEESAW_GPIO_INTENSET, SEESAW_BUTTON_MASK);
> + if (err)
> + return dev_err_probe(&client->dev, err,
> + "failed to enable hardware interrupts\n");
Maybe this should be in seesaw_open()?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: uinput - fix circular locking dependency with ff-core
From: Dmitry Torokhov @ 2026-03-23 2:47 UTC (permalink / raw)
To: Mikhail Gavrilov; +Cc: linux-input, linux-kernel
In-Reply-To: <20260228223628.472208-1-mikhail.v.gavrilov@gmail.com>
Hi Mikhail,
On Sun, Mar 01, 2026 at 03:36:28AM +0500, Mikhail Gavrilov wrote:
> A lockdep circular locking dependency warning can be triggered
> reproducibly when using a force-feedback gamepad with uinput (for
> example, playing ELDEN RING under Wine with a Flydigi Vader 5
> controller):
>
> ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex
>
> The cycle is caused by four lock acquisition paths:
>
> 1. ff upload: input_ff_upload() holds ff->mutex and calls
> uinput_dev_upload_effect() -> uinput_request_submit() ->
> uinput_request_send(), which acquires udev->mutex.
>
> 2. device create: uinput_ioctl_handler() holds udev->mutex and calls
> uinput_create_device() -> input_register_device(), which acquires
> input_mutex.
>
> 3. device register: input_register_device() holds input_mutex and
> calls kbd_connect() -> input_register_handle(), which acquires
> dev->mutex.
>
> 4. evdev release: evdev_release() calls input_flush_device() under
> dev->mutex, which calls input_ff_flush() acquiring ff->mutex.
>
> Fix this by replacing udev->mutex with the existing
> udev->requests_lock spinlock in uinput_request_send(). The function
> only needs to atomically check device state and queue an input event
> into the ring buffer via uinput_dev_event() -- both operations are safe
> under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not
> sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock
> is a leaf in the lock ordering and cannot form cycles with mutexes.
>
> To keep state transitions visible to uinput_request_send(), protect
> writes to udev->state in uinput_create_device() and
> uinput_destroy_device() with the same spinlock.
Thank you for the patch, it looks solid, however I wonder if creating a
separate "state_lock" spinlock would not be better than reusing
requests_lock?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: inkern: Use namespaced exports
From: Dmitry Torokhov @ 2026-03-22 22:26 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Romain Gantois, MyungJoo Ham, Chanwoo Choi, Guenter Roeck,
Peter Rosin, David Lechner, Nuno Sá, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Mariel Tinaco, Kevin Tsai,
Linus Walleij, Eugen Hristev, Vinod Koul, Kishon Vijay Abraham I,
Sebastian Reichel, Chen-Yu Tsai, Hans de Goede,
Support Opensource, Paul Cercueil, Iskren Chernev,
Krzysztof Kozlowski, Marek Szyprowski, Matheus Castello,
Saravanan Sekar, Matthias Brugger, AngeloGioacchino Del Regno,
Casey Connolly, Pali Rohár, Orson Zhai, Baolin Wang,
Chunyan Zhang, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Claudiu Beznea,
Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Sylwester Nawrocki, Olivier Moysan, Arnaud Pouliquen,
Maxime Coquelin, Alexandre Torgue, Thomas Petazzoni, linux-kernel,
linux-hwmon, linux-iio, linux-input, linux-phy, linux-pm,
linux-mips, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Sebastian Reichel, Andy Shevchenko
In-Reply-To: <20260322122529.62093f12@jic23-huawei>
On Sun, Mar 22, 2026 at 12:25:29PM +0000, Jonathan Cameron wrote:
> On Sun, 11 Jan 2026 17:02:22 +0000
> Jonathan Cameron <jic23@kernel.org> wrote:
>
> > On Tue, 09 Dec 2025 09:25:56 +0100
> > Romain Gantois <romain.gantois@bootlin.com> wrote:
> >
> > > Use namespaced exports for IIO consumer API functions.
> > >
> > > This will make it easier to manage the IIO export surface. Consumer drivers
> > > will only be provided access to a specific set of functions, thereby
> > > restricting usage of internal IIO functions by other parts of the kernel.
> > >
> > > This change cannot be split into several parts without breaking
> > > bisectability, thus all of the affected drivers are modified at once.
> > >
> > > Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for power-supply
> > > Acked-by: Guenter Roeck <linux@roeck-us.net>
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> > > Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
> > Ideally looking for a couple more Acks.
> >
> > If any of the maintainers of other trees who haven't already replied
> > have time for a quick glance that would be great. I'll spin an
> > immutable branch but I'm not really expecting any non trivial
> > conflicts unless there is a new user in flight that I've forgotten
> > about.
>
> At this stage, given I'm still waiting on replies from a couple of
> subsystem maintainers, I'm thinking we'll do this next cycle and I'll
> provide an immutable branch based on rc1 for anyone to grab if they
> run into merge conflicts in linux-next.
Sorry, I just acked the input bits in the patch, but in general I feel
these kind of mechanical changes in consumers do not require an ack and
you can just go an apply such changes.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: inkern: Use namespaced exports
From: Dmitry Torokhov @ 2026-03-22 22:24 UTC (permalink / raw)
To: Romain Gantois
Cc: MyungJoo Ham, Chanwoo Choi, Guenter Roeck, Peter Rosin,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Mariel Tinaco, Kevin Tsai,
Linus Walleij, Eugen Hristev, Vinod Koul, Kishon Vijay Abraham I,
Sebastian Reichel, Chen-Yu Tsai, Hans de Goede,
Support Opensource, Paul Cercueil, Iskren Chernev,
Krzysztof Kozlowski, Marek Szyprowski, Matheus Castello,
Saravanan Sekar, Matthias Brugger, AngeloGioacchino Del Regno,
Casey Connolly, Pali Rohár, Orson Zhai, Baolin Wang,
Chunyan Zhang, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Claudiu Beznea,
Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Sylwester Nawrocki, Olivier Moysan, Arnaud Pouliquen,
Maxime Coquelin, Alexandre Torgue, Thomas Petazzoni, linux-kernel,
linux-hwmon, linux-iio, linux-input, linux-phy, linux-pm,
linux-mips, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Sebastian Reichel, Andy Shevchenko
In-Reply-To: <20251209-iio-inkern-use-namespaced-exports-v2-2-9799a33c4b7f@bootlin.com>
On Tue, Dec 09, 2025 at 09:25:56AM +0100, Romain Gantois wrote:
> Use namespaced exports for IIO consumer API functions.
>
> This will make it easier to manage the IIO export surface. Consumer drivers
> will only be provided access to a specific set of functions, thereby
> restricting usage of internal IIO functions by other parts of the kernel.
>
> This change cannot be split into several parts without breaking
> bisectability, thus all of the affected drivers are modified at once.
>
> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for power-supply
> Acked-by: Guenter Roeck <linux@roeck-us.net>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
For input:
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: HIDP: cap report descriptor size in HID setup
From: Eric_Terminal @ 2026-03-22 15:37 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Bastien Nocera, marcel, johan.hedberg, luiz.dentz,
linux-bluetooth, linux-kernel, linux-input
In-Reply-To: <abFA9nm_fBqw8mNS@beelink>
Hi all,
Just a gentle ping on this patch.
Since Benjamin reviewed it from the input side and concluded it should
be safe, I was wondering if there are any further comments from the
Bluetooth side, or if anything else is needed from me for this to be
merged?
Thanks,
Yufan
On Wed, Mar 11, 2026 at 6:19 PM Benjamin Tissoires <bentiss@kernel.org> wrote:
>
> On Mar 01 2026, Bastien Nocera wrote:
> > On Sun, 2026-03-01 at 01:26 +0800, Eric-Terminal wrote:
> > > From: Yufan Chen <ericterminal@gmail.com>
> > >
> > > hidp_setup_hid() duplicates the report descriptor from userspace
> > > based on
> > > req->rd_size. Large values can trigger oversized copies.
> > >
> > > Do not reject the connection when rd_size exceeds
> > > HID_MAX_DESCRIPTOR_SIZE. Instead, cap rd_size in hidp_setup_hid()
> > > and use the capped value for memdup_user() and session->rd_size.
> > >
> > > This keeps compatibility with existing userspace behavior while
> > > bounding memory usage in the HID setup path.
> >
> > Cross-sending this to linux-input@ for review, they would know the best
> > way to deal with oversized HID descriptors.
>
> AFAICT the hid-core code would be fine with it (it would parse it), but
> there will be some issues (hidraw will not be able to export the entire
> rdesc, so is the sysfs).
>
> For reference, usbhid just returns -EINVAL for oversize report
> descriptors.
>
> Anyway, if the report descriptor is truncated, like in this patch, the
> hid core parse will fail if the data is not correct, so I thing this
> should be safe.
>
> Cheers,
> Benjamin
>
> >
> > >
> > > Signed-off-by: Yufan Chen <ericterminal@gmail.com>
> > > ---
> > > net/bluetooth/hidp/core.c | 7 +++++--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> > > index 6fe815241..31aeffa39 100644
> > > --- a/net/bluetooth/hidp/core.c
> > > +++ b/net/bluetooth/hidp/core.c
> > > @@ -755,13 +755,16 @@ static int hidp_setup_hid(struct hidp_session
> > > *session,
> > > const struct hidp_connadd_req *req)
> > > {
> > > struct hid_device *hid;
> > > + unsigned int rd_size;
> > > int err;
> > >
> > > - session->rd_data = memdup_user(req->rd_data, req->rd_size);
> > > + rd_size = min_t(unsigned int, req->rd_size,
> > > HID_MAX_DESCRIPTOR_SIZE);
> > > +
> > > + session->rd_data = memdup_user(req->rd_data, rd_size);
> > > if (IS_ERR(session->rd_data))
> > > return PTR_ERR(session->rd_data);
> > >
> > > - session->rd_size = req->rd_size;
> > > + session->rd_size = rd_size;
> > >
> > > hid = hid_allocate_device();
> > > if (IS_ERR(hid)) {
> >
^ 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