* [PATCH v2 1/4] dt-bindings: net: remove obsolete mdio.txt
From: Akash Sukhavasi @ 2026-06-03 20:42 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Vladimir Oltean, Simon Horman, Jonathan Corbet, Shuah Khan,
Dmitry Torokhov, Thierry Reding, Jonathan Hunter, Lee Jones
Cc: netdev, devicetree, linux-kernel, linux-media, linux-doc,
linux-input, linux-tegra, Akash Sukhavasi
In-Reply-To: <20260603-b4-remove-redirect-stubs-v2-0-c8c19876ab64@gmail.com>
mdio.txt has been a single-line redirect to mdio.yaml since
commit 62d77ff7ecbf ("dt-bindings: net: Add a YAML schemas for the
generic MDIO options"), which introduced the .yaml schema and reduced
the .txt to a stub in the same change. The .yaml has the same filename
in the same directory, making this redirect unnecessary for
discoverability.
No files in the tree reference mdio.txt and it has not been touched
since June 2019. Remove the obsolete stub.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Documentation/devicetree/bindings/net/mdio.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/mdio.txt b/Documentation/devicetree/bindings/net/mdio.txt
deleted file mode 100644
index cf8a0105488e..000000000000
--- a/Documentation/devicetree/bindings/net/mdio.txt
+++ /dev/null
@@ -1 +0,0 @@
-This file has moved to mdio.yaml.
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/4] dt-bindings: remove redundant .txt redirect stubs
From: Akash Sukhavasi @ 2026-06-03 20:42 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mauro Carvalho Chehab,
Vladimir Oltean, Simon Horman, Jonathan Corbet, Shuah Khan,
Dmitry Torokhov, Thierry Reding, Jonathan Hunter, Lee Jones
Cc: netdev, devicetree, linux-kernel, linux-media, linux-doc,
linux-input, linux-tegra, Akash Sukhavasi
Several .txt files under Documentation/devicetree/bindings/ contain
only a redirect notice pointing to a .yaml schema with the same base
filename in the same directory. These stubs were useful during the
.txt to .yaml transition but are now redundant, since the .yaml is
discoverable by name. Meanwhile, other documentation still references
some of these stubs, forcing readers through an unnecessary extra hop
to reach the actual schema.
This series removes four such stubs and updates all remaining
cross-references to point directly to the .yaml schemas.
Other redirect stubs in the tree were evaluated and intentionally
kept:
- Stubs pointing to .yaml files with different names (e.g.,
spi-bus.txt -> spi-controller.yaml) serve as breadcrumbs for
the renamed schema.
- Stubs pointing to multiple .yaml files (e.g., nvmem.txt ->
nvmem.yaml and nvmem-consumer.yaml) convey that the content
was split.
- Stubs pointing to .yaml files in a different directory (e.g.,
reset/st,stm32-rcc.txt -> clock/st,stm32-rcc.yaml) serve as
cross-directory pointers.
Two additional same-name, same-directory stubs (leds/common.txt,
regulator/regulator.txt) have significantly more cross references
and will be addressed in a follow-up series.
v2:
- Patch 4/4: corrected commit message (eight references in six files, not
eight files), Sashiko review.
https://sashiko.dev/#/patchset/20260529052246.4934-1-akash.sukhavasi@gmail.com?part=4
v1: https://lore.kernel.org/all/20260529052246.4934-1-akash.sukhavasi@gmail.com/
Patch 1 supersedes my earlier standalone submission:
https://lore.kernel.org/all/20260523004223.3045-1-akash.sukhavasi@gmail.com/
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Akash Sukhavasi (4):
dt-bindings: net: remove obsolete mdio.txt
dt-bindings: media: remove obsolete rc.txt
dt-bindings: net: dsa: remove obsolete dsa.txt
dt-bindings: input: remove obsolete matrix-keymap.txt
Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/clps711x-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/matrix-keymap.txt | 1 -
Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt | 2 +-
Documentation/devicetree/bindings/input/pxa27x-keypad.txt | 2 +-
Documentation/devicetree/bindings/input/st-keyscan.txt | 2 +-
Documentation/devicetree/bindings/media/hix5hd2-ir.txt | 2 +-
Documentation/devicetree/bindings/media/rc.txt | 1 -
Documentation/devicetree/bindings/mfd/tc3589x.txt | 6 +++---
Documentation/devicetree/bindings/net/dsa/dsa.txt | 4 ----
Documentation/devicetree/bindings/net/dsa/lan9303.txt | 2 +-
Documentation/devicetree/bindings/net/mdio.txt | 1 -
Documentation/networking/dsa/dsa.rst | 2 +-
13 files changed, 11 insertions(+), 18 deletions(-)
---
base-commit: b7bee4ca5688e30ca50fbc87b1b8f7eed7006c17
change-id: 20260603-b4-remove-redirect-stubs-899afc8fa7d6
Best regards,
--
Akash Sukhavasi <akash.sukhavasi@gmail.com>
^ permalink raw reply
* Re: [PATCH v14 1/2] HID: cp2112: Add fwnode support
From: Jacky Huang @ 2026-06-03 19:46 UTC (permalink / raw)
To: Danny Kaehn
Cc: Jacky Huang, Benjamin Tissoires, Andy Shevchenko, Andi Shyti,
Conor Dooley, Jiri Kosina, Dmitry Torokhov, Ethan Twardy,
Bartosz Golaszewski, Leo Huang, Arun D Patil, Willie Thai,
Ting-Kai Chen, linux-input, linux-i2c, linux-kernel
In-Reply-To: <20260520-cp2112-dt-v14-1-b1b4b6734b6f@plexus.com>
Hi Danny,
Thank you for all your work bringing this through so many revisions, and
I am glad to help by testing it.
I tested this on an AST2600-based OpenBMC platform (NVIDIA Vera Rubin)
that has several CP2112s. With this patch, a CP2112 whose device-tree
"i2c" subnode declares downstream I2C devices (PCA9555 expanders) has
them auto-instantiated by i2c-core: they appeared on the adapter's I2C
bus with their gpio-line-names. CP2112s with an empty "i2c" node
registered their adapters but instantiated no children, as expected.
Tested-by: Jacky Huang <jackyhuang@nvidia.com>
^ permalink raw reply
* Re: [PATCH] Input: apbps2: Simplify resource mapping and IRQ retrieval
From: sashiko-bot @ 2026-06-03 19:33 UTC (permalink / raw)
To: Rosen Penev; +Cc: linux-input, dmitry.torokhov
In-Reply-To: <20260603192415.6679-1-rosenp@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Requesting a shared IRQ before the serio port is fully allocated and initialized leads to a potential NULL pointer dereference or uninitialized spinlock access in the interrupt handler.
- [High] Mixing `devm` managed interrupts with manual resource unregistration causes an incorrect teardown order, leading to a use-after-free if a shared interrupt fires during device removal.
--
commit d306647eec008111ed14c378d300aa2cb98191b6
Author: Rosen Penev <rosenp@gmail.com>
Input: apbps2: Simplify resource mapping and IRQ retrieval
Simplify resource mapping by using devm_platform_ioremap_resource()
instead of the longer devm_platform_get_and_ioremap_resource() helper
as the last argument is NULL.
Additionally, use platform_get_irq() to retrieve the interrupt
instead of irq_of_parse_and_map() and propagate its error code on
failure. irq_of_parse_and_map() requires irq_dispose_mapping, which is
missing.
> diff --git a/drivers/input/serio/apbps2.c b/drivers/input/serio/apbps2.c
> index 0aa4ab00af352..5f21acdd41139 100644
> --- a/drivers/input/serio/apbps2.c
> +++ b/drivers/input/serio/apbps2.c
[ ... ]
> @@ -148,7 +148,10 @@ static int apbps2_of_probe(struct platform_device *ofdev)
> iowrite32be(0, &priv->regs->ctrl);
>
> /* IRQ */
> - irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
> + irq = platform_get_irq(ofdev, 0);
> + if (irq < 0)
> + return irq;
> +
> err = devm_request_irq(&ofdev->dev, irq, apbps2_isr,
> IRQF_SHARED, "apbps2", priv);
[Severity: High]
This is a pre-existing issue, but requesting a shared IRQ here before the
serio port is fully allocated and initialized creates a window for a NULL
pointer dereference.
If a shared interrupt fires immediately (triggered by another device on the
same line) and there is leftover data in the PS/2 FIFO, apbps2_isr() will
execute:
drivers/input/serio/apbps2.c:apbps2_isr() {
...
serio_interrupt(priv->io, data, rxflags);
...
}
Since priv->io is either NULL or not fully initialized until later in probe:
drivers/input/serio/apbps2.c:apbps2_of_probe() {
...
priv->io = ... /* allocated later */
...
}
Could this lead to a crash if the ISR fires early?
[Severity: High]
This is another pre-existing issue, but does mixing a devm-managed interrupt
here with manual unregistration in apbps2_of_remove() cause a teardown order
issue?
In apbps2_of_remove(), the driver manually unregisters and frees the serio
port:
drivers/input/serio/apbps2.c:apbps2_of_remove() {
...
serio_unregister_port(priv->io);
...
}
Because the interrupt was requested with devm_request_irq(), its handler
remains active until devres runs free_irq() after apbps2_of_remove() returns.
If a shared interrupt fires during this window and there is pending data,
apbps2_isr() will execute and pass the already-freed priv->io pointer to
serio_interrupt(), resulting in a use-after-free.
Could the interrupt teardown order be adjusted to prevent this race?
> if (err) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260603192415.6679-1-rosenp@gmail.com?part=1
^ permalink raw reply
* [PATCH] Input: apbps2: Simplify resource mapping and IRQ retrieval
From: Rosen Penev @ 2026-06-03 19:24 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, open list
Simplify resource mapping by using devm_platform_ioremap_resource()
instead of the longer devm_platform_get_and_ioremap_resource() helper
as the last argument is NULL.
Additionally, use platform_get_irq() to retrieve the interrupt
instead of irq_of_parse_and_map() and propagate its error code on
failure. irq_of_parse_and_map() requires irq_dispose_mapping, which is
missing.
Assisted-by: Antigravity:Gemini-3.5-Flash
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/input/serio/apbps2.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/input/serio/apbps2.c b/drivers/input/serio/apbps2.c
index 0aa4ab00af35..5f21acdd4113 100644
--- a/drivers/input/serio/apbps2.c
+++ b/drivers/input/serio/apbps2.c
@@ -140,7 +140,7 @@ static int apbps2_of_probe(struct platform_device *ofdev)
}
/* Find device address */
- priv->regs = devm_platform_get_and_ioremap_resource(ofdev, 0, NULL);
+ priv->regs = devm_platform_ioremap_resource(ofdev, 0);
if (IS_ERR(priv->regs))
return PTR_ERR(priv->regs);
@@ -148,7 +148,10 @@ static int apbps2_of_probe(struct platform_device *ofdev)
iowrite32be(0, &priv->regs->ctrl);
/* IRQ */
- irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
+ irq = platform_get_irq(ofdev, 0);
+ if (irq < 0)
+ return irq;
+
err = devm_request_irq(&ofdev->dev, irq, apbps2_isr,
IRQF_SHARED, "apbps2", priv);
if (err) {
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] iio: inkern: Use namespaced exports
From: Jonathan Cameron @ 2026-06-03 17:20 UTC (permalink / raw)
To: Dmitry Torokhov
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: <acBr-W2ILu9tnMyd@google.com>
On Sun, 22 Mar 2026 15:24:21 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 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.
>
For anyone wondering what happened to this... I forgot to apply this at the
beginning of the cycle and by the time I remembered we had too much queued up
so it would have been messy to do an immutable branch. Anyhow, I plan to
sort this at start of next cycle.
Jonathan
^ permalink raw reply
* Re: [linux-6.1.y 2/3] HID: pass the buffer size to hid_report_raw_event
From: sashiko-bot @ 2026-06-03 16:47 UTC (permalink / raw)
To: Lee Jones; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260603163022.3301081-2-lee@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The logic to safely pad short HID reports with zeros is entirely unreachable for standard input reports, causing valid short reports to be incorrectly rejected.
--
commit 74b88a2431a35fe5904c8ec2805668a0317adde6
Author: Benjamin Tissoires <bentiss@kernel.org>
HID: pass the buffer size to hid_report_raw_event
This commit introduces a bufsize parameter to hid_report_raw_event() to help
distinguish between the actual payload size and the buffer capacity. This allows
the HID core to safely memset zero-pad short reports without causing
out-of-bounds writes if the buffer is too small.
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
[ ... ]
> @@ -2019,9 +2027,15 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
> else if (rsize > max_buffer_size)
> rsize = max_buffer_size;
>
> + if (bsize < rsize) {
> + hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
> + report->id, rsize, bsize);
> + return -EINVAL;
> + }
> +
> if (csize < rsize) {
> dbg_hid("report %d is too short, (%d < %d)\n", report->id,
> - csize, rsize);
> + csize, rsize);
> memset(cdata + csize, 0, rsize - csize);
> }
[Severity: High]
Does this new check unconditionally reject short reports for callers that pass
the payload size as the buffer size?
Since bsize is checked against rsize and returns -EINVAL, if bsize
happens to equal csize, the subsequent csize < rsize check and its memset
zero-padding logic become unreachable dead code.
[ ... ]
> @@ -2058,12 +2072,13 @@ EXPORT_SYMBOL_GPL(hid_report_raw_event);
> *
> * This is data entry for lower layers.
> */
> -int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
> - int interrupt)
> +int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data,
> + u32 size, int interrupt)
> {
> struct hid_report_enum *report_enum;
> struct hid_driver *hdrv;
> struct hid_report *report;
> + size_t bufsize = size;
> int ret = 0;
>
> if (!hid)
[Severity: High]
Does initializing bufsize to size here lose the actual allocation capacity
of the buffer?
By constraining bufsize to the payload size, this ensures that bsize == csize
in hid_report_raw_event(), which means valid short reports missing trailing
zero bytes will be rejected rather than padded.
[ ... ]
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -74,7 +74,7 @@ static void wacom_wac_queue_flush(struct hid_device *hdev,
> int err;
>
> size = kfifo_out(fifo, buf, sizeof(buf));
> - err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, false);
> + err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, size, false);
[Severity: High]
Should this pass sizeof(buf) as the buffer size instead of size?
Since size is the number of bytes read from the kfifo (the payload size),
passing size as both the buffer size and data size prevents the short-report
zero-padding logic from working correctly.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260603163022.3301081-2-lee@kernel.org?part=1
^ permalink raw reply
* [linux-6.1.y 3/3] HID: core: Fix size_t specifier in hid_report_raw_event()
From: Lee Jones @ 2026-06-03 16:30 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Filipe Laíns,
Bastien Nocera, Ping Cheng, Jason Gerecke, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman, linux-input,
linux-kernel, greybus-dev, linux-staging
Cc: stable, Nathan Chancellor, Miguel Ojeda, Linus Torvalds,
Sasha Levin
In-Reply-To: <20260603163022.3301081-1-lee@kernel.org>
From: Nathan Chancellor <nathan@kernel.org>
[ Upstream commit 4d3a2a466b8d68d852a1f3bbf11204b718428dc4 ]
When building for 32-bit platforms, for which 'size_t' is
'unsigned int', there are warnings around using the incorrect format
specifier to print bsize in hid_report_raw_event():
drivers/hid/hid-core.c:2054:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
| ~~~
| %zu
2054 | report->id, csize, bsize);
| ^~~~~
drivers/hid/hid-core.c:2076:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
| ~~~
| %zu
2076 | report->id, rsize, bsize);
| ^~~~~
Use the proper 'size_t' format specifier, '%zu', to clear up the
warnings.
Cc: stable@vger.kernel.org
Fixes: 2c85c61d1332 ("HID: pass the buffer size to hid_report_raw_event")
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://lore.kernel.org/20260516020430.110135-1-ojeda@kernel.org/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 3ab135238832446399614e7a4bb796d620717806)
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/hid-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 346c5554da5c..1620a13c89c0 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2003,7 +2003,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
return 0;
if (unlikely(bsize < csize)) {
- hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
+ hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %zu)\n",
report->id, csize, bsize);
return -EINVAL;
}
@@ -2025,7 +2025,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
rsize = max_buffer_size;
if (bsize < rsize) {
- hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
+ hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %zu)\n",
report->id, rsize, bsize);
return -EINVAL;
}
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [linux-6.1.y 2/3] HID: pass the buffer size to hid_report_raw_event
From: Lee Jones @ 2026-06-03 16:30 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Filipe Laíns,
Bastien Nocera, Ping Cheng, Jason Gerecke, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman, linux-input,
linux-kernel, greybus-dev, linux-staging
Cc: stable, Benjamin Tissoires, Jiri Kosina, Sasha Levin
In-Reply-To: <20260603163022.3301081-1-lee@kernel.org>
From: Benjamin Tissoires <bentiss@kernel.org>
[ Upstream commit 2c85c61d1332e1e16f020d76951baf167dcb6f7a ]
commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
bogus memset()") enforced the provided data to be at least the size of
the declared buffer in the report descriptor to prevent a buffer
overflow. However, we can try to be smarter by providing both the buffer
size and the data size, meaning that hid_report_raw_event() can make
better decision whether we should plaining reject the buffer (buffer
overflow attempt) or if we can safely memset it to 0 and pass it to the
rest of the stack.
Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Acked-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Stable-dep-of: 206342541fc8 ("HID: core: introduce hid_safe_input_report()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 509c2605065004fc4cd86ee50a9350d402785307)
[Lee: Backported to linux-6.12.y and beyond]
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/hid-core.c | 33 +++++++++++++++++++++++---------
drivers/hid/hid-gfrm.c | 4 ++--
drivers/hid/hid-logitech-hidpp.c | 2 +-
drivers/hid/hid-multitouch.c | 2 +-
drivers/hid/hid-primax.c | 2 +-
drivers/hid/hid-vivaldi-common.c | 2 +-
drivers/hid/wacom_sys.c | 6 +++---
drivers/staging/greybus/hid.c | 2 +-
include/linux/hid.h | 4 ++--
9 files changed, 36 insertions(+), 21 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e3d728d67b53..346c5554da5c 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1986,24 +1986,32 @@ int __hid_request(struct hid_device *hid, struct hid_report *report,
}
EXPORT_SYMBOL_GPL(__hid_request);
-int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
- int interrupt)
+int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
+ size_t bufsize, u32 size, int interrupt)
{
struct hid_report_enum *report_enum = hid->report_enum + type;
struct hid_report *report;
struct hid_driver *hdrv;
int max_buffer_size = HID_MAX_BUFFER_SIZE;
u32 rsize, csize = size;
+ size_t bsize = bufsize;
u8 *cdata = data;
int ret = 0;
report = hid_get_report(report_enum, data);
if (!report)
- goto out;
+ return 0;
+
+ if (unlikely(bsize < csize)) {
+ hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
+ report->id, csize, bsize);
+ return -EINVAL;
+ }
if (report_enum->numbered) {
cdata++;
csize--;
+ bsize--;
}
rsize = hid_compute_report_size(report);
@@ -2016,9 +2024,15 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
else if (rsize > max_buffer_size)
rsize = max_buffer_size;
+ if (bsize < rsize) {
+ hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
+ report->id, rsize, bsize);
+ return -EINVAL;
+ }
+
if (csize < rsize) {
dbg_hid("report %d is too short, (%d < %d)\n", report->id,
- csize, rsize);
+ csize, rsize);
memset(cdata + csize, 0, rsize - csize);
}
@@ -2027,7 +2041,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
if (hid->claimed & HID_CLAIMED_HIDRAW) {
ret = hidraw_report_event(hid, data, size);
if (ret)
- goto out;
+ return ret;
}
if (hid->claimed != HID_CLAIMED_HIDRAW && report->maxfield) {
@@ -2039,7 +2053,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
if (hid->claimed & HID_CLAIMED_INPUT)
hidinput_report_event(hid, report);
-out:
+
return ret;
}
EXPORT_SYMBOL_GPL(hid_report_raw_event);
@@ -2055,12 +2069,13 @@ EXPORT_SYMBOL_GPL(hid_report_raw_event);
*
* This is data entry for lower layers.
*/
-int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
- int interrupt)
+int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data,
+ u32 size, int interrupt)
{
struct hid_report_enum *report_enum;
struct hid_driver *hdrv;
struct hid_report *report;
+ size_t bufsize = size;
int ret = 0;
if (!hid)
@@ -2105,7 +2120,7 @@ int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data
goto unlock;
}
- ret = hid_report_raw_event(hid, type, data, size, interrupt);
+ ret = hid_report_raw_event(hid, type, data, bufsize, size, interrupt);
unlock:
up(&hid->driver_input_lock);
diff --git a/drivers/hid/hid-gfrm.c b/drivers/hid/hid-gfrm.c
index 699186ff2349..d2a56bf92b41 100644
--- a/drivers/hid/hid-gfrm.c
+++ b/drivers/hid/hid-gfrm.c
@@ -66,7 +66,7 @@ static int gfrm_raw_event(struct hid_device *hdev, struct hid_report *report,
switch (data[1]) {
case GFRM100_SEARCH_KEY_DOWN:
ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, search_key_dn,
- sizeof(search_key_dn), 1);
+ sizeof(search_key_dn), sizeof(search_key_dn), 1);
break;
case GFRM100_SEARCH_KEY_AUDIO_DATA:
@@ -74,7 +74,7 @@ static int gfrm_raw_event(struct hid_device *hdev, struct hid_report *report,
case GFRM100_SEARCH_KEY_UP:
ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, search_key_up,
- sizeof(search_key_up), 1);
+ sizeof(search_key_up), sizeof(search_key_up), 1);
break;
default:
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 339a227c457e..113307157a27 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3692,7 +3692,7 @@ static int hidpp10_consumer_keys_raw_event(struct hidpp_device *hidpp,
memcpy(&consumer_report[1], &data[3], 4);
/* We are called from atomic context */
hid_report_raw_event(hidpp->hid_dev, HID_INPUT_REPORT,
- consumer_report, 5, 1);
+ consumer_report, sizeof(consumer_report), 5, 1);
return 1;
}
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 003950894362..6c04eed0a464 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -479,7 +479,7 @@ static void mt_get_feature(struct hid_device *hdev, struct hid_report *report)
}
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, buf,
- size, 0);
+ size, size, 0);
if (ret)
dev_warn(&hdev->dev, "failed to report feature\n");
}
diff --git a/drivers/hid/hid-primax.c b/drivers/hid/hid-primax.c
index 1e6413d07cae..16e2a811eda9 100644
--- a/drivers/hid/hid-primax.c
+++ b/drivers/hid/hid-primax.c
@@ -44,7 +44,7 @@ static int px_raw_event(struct hid_device *hid, struct hid_report *report,
data[0] |= (1 << (data[idx] - 0xE0));
data[idx] = 0;
}
- hid_report_raw_event(hid, HID_INPUT_REPORT, data, size, 0);
+ hid_report_raw_event(hid, HID_INPUT_REPORT, data, size, size, 0);
return 1;
default: /* unknown report */
diff --git a/drivers/hid/hid-vivaldi-common.c b/drivers/hid/hid-vivaldi-common.c
index b0af2be94895..7fb986615768 100644
--- a/drivers/hid/hid-vivaldi-common.c
+++ b/drivers/hid/hid-vivaldi-common.c
@@ -85,7 +85,7 @@ void vivaldi_feature_mapping(struct hid_device *hdev,
}
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, report_data,
- report_len, 0);
+ report_len, report_len, 0);
if (ret) {
dev_warn(&hdev->dev, "failed to report feature %d\n",
field->report->id);
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 52011503ff3b..52b7f474d866 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -74,7 +74,7 @@ static void wacom_wac_queue_flush(struct hid_device *hdev,
int err;
size = kfifo_out(fifo, buf, sizeof(buf));
- err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, false);
+ err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, size, false);
if (err) {
hid_warn(hdev, "%s: unable to flush event due to error %d\n",
__func__, err);
@@ -319,7 +319,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
data, n, WAC_CMD_RETRIES);
if (ret == n && features->type == HID_GENERIC) {
ret = hid_report_raw_event(hdev,
- HID_FEATURE_REPORT, data, n, 0);
+ HID_FEATURE_REPORT, data, n, n, 0);
} else if (ret == 2 && features->type != HID_GENERIC) {
features->touch_max = data[1];
} else {
@@ -380,7 +380,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
data, n, WAC_CMD_RETRIES);
if (ret == n) {
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT,
- data, n, 0);
+ data, n, n, 0);
} else {
hid_warn(hdev, "%s: could not retrieve sensor offsets\n",
__func__);
diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c
index 15335c38cb26..e761411ccf64 100644
--- a/drivers/staging/greybus/hid.c
+++ b/drivers/staging/greybus/hid.c
@@ -201,7 +201,7 @@ static void gb_hid_init_report(struct gb_hid *ghid, struct hid_report *report)
* we just need to setup the input fields, so using
* hid_report_raw_event is safe.
*/
- hid_report_raw_event(ghid->hid, report->type, ghid->inbuf, size, 1);
+ hid_report_raw_event(ghid->hid, report->type, ghid->inbuf, ghid->bufsize, size, 1);
}
static void gb_hid_init_reports(struct gb_hid *ghid)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index f4bdaf1b8f41..a9857fdfc327 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -1205,8 +1205,8 @@ static inline u32 hid_report_len(struct hid_report *report)
return DIV_ROUND_UP(report->size, 8) + (report->id > 0);
}
-int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
- int interrupt);
+int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
+ size_t bufsize, u32 size, int interrupt);
/* HID quirks API */
unsigned long hid_lookup_quirk(const struct hid_device *hdev);
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [linux-6.1.y 1/3] HID: core: Add printk_ratelimited variants to hid_warn() etc
From: Lee Jones @ 2026-06-03 16:30 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Filipe Laíns,
Bastien Nocera, Ping Cheng, Jason Gerecke, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman, linux-input,
linux-kernel, greybus-dev, linux-staging
Cc: stable, Vicki Pfau, Jiri Kosina
From: Vicki Pfau <vi@endrift.com>
hid_warn_ratelimited() is needed. Add the others as part of the block.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
(cherry picked from commit 1d64624243af8329b4b219d8c39e28ea448f9929)
Signed-off-by: Lee Jones <lee@kernel.org>
---
include/linux/hid.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 5d37e2349fae..f4bdaf1b8f41 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -1252,4 +1252,15 @@ int hid_pidff_init_with_quirks(struct hid_device *hid, __u32 initial_quirks);
#define hid_dbg_once(hid, fmt, ...) \
dev_dbg_once(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_err_ratelimited(hid, fmt, ...) \
+ dev_err_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_notice_ratelimited(hid, fmt, ...) \
+ dev_notice_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_warn_ratelimited(hid, fmt, ...) \
+ dev_warn_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_info_ratelimited(hid, fmt, ...) \
+ dev_info_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_dbg_ratelimited(hid, fmt, ...) \
+ dev_dbg_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+
#endif
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* Re: [PATCH] HID: nintendo: Fix imu_timestamp_us double increment per report
From: sashiko-bot @ 2026-06-03 15:34 UTC (permalink / raw)
To: Christos Maragkos; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260603152134.94439-1-whitetowersoftware@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing dropped packet compensation causes cumulative IMU timestamp lag.
--
commit ad128b0e7b6200fd6acd6f6287071433e2058d5a
Author: Christos Maragkos <whitetowersoftware@gmail.com>
HID: nintendo: Fix imu_timestamp_us double increment per report
This commit fixes an issue where the imu_timestamp_us variable was incremented
twice per report. It removes the redundant increment at the start of the
report handling to ensure accurate timing for userspace applications.
> diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
> --- a/drivers/hid/hid-nintendo.c
> +++ b/drivers/hid/hid-nintendo.c
> @@ -1453,7 +1453,6 @@ static void joycon_parse_imu_report(struct joycon_ctlr *ctlr,
> dropped_threshold = ctlr->imu_avg_delta_ms * 3 / 2;
> dropped_pkts = (delta - min(delta, dropped_threshold)) /
> ctlr->imu_avg_delta_ms;
> - ctlr->imu_timestamp_us += 1000 * ctlr->imu_avg_delta_ms;
> if (dropped_pkts > JC_IMU_DROPPED_PKT_WARNING) {
> hid_warn_ratelimited(ctlr->hdev,
> "compensating for %u dropped IMU reports\n",
> dropped_pkts);
> hid_warn_ratelimited(ctlr->hdev,
> "delta=%u avg_delta=%u\n",
> delta, ctlr->imu_avg_delta_ms);
> }
[Severity: High]
This is a pre-existing issue, but while the timestamp logic is being
modified here in joycon_parse_imu_report(), the code calculates dropped_pkts
and logs a warning about compensating for dropped IMU reports, but completely
lacks the logic to actually add the dropped time to imu_timestamp_us.
Because the driver only increments the timestamp for the 15ms window of
the received samples later in the function, dropped intervals are silently
omitted. Over a gaming session, will this cause the controller's timestamp
to accumulate permanent lag relative to real time, breaking sensor fusion
or gyro aiming in userspace?
Additionally, does the existing formula for dropped_pkts undercount by 1,
yielding 0 for a single dropped packet? Would it be better to correct this
formula (for example, (delta + avg / 2) / avg - 1) so it can accurately
perform the missing compensation?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260603152134.94439-1-whitetowersoftware@gmail.com?part=1
^ permalink raw reply
* [PATCH] HID: nintendo: Fix imu_timestamp_us double increment per report
From: Christos Maragkos @ 2026-06-03 15:21 UTC (permalink / raw)
To: linux-input; +Cc: djogorchock, jikos, bentiss, Christos Maragkos
Previously, the imu_timestamp_us variable was incremented twice per
report, causing it to advance by two times the desired amount.
This resulted in incorrect jumps in IMU timestamps reported using
MSC_TIMESTAMP, so userspace applications saw corrupted timing on
functions such as gyroscope-based aim and motion controls.
This is fixed by removing the redundant increment at the start of the
report handling so the remaining can account for the full report
interval.
Fixes: 4ff5b10840a88 ("HID: nintendo: add IMU support")
Signed-off-by: Christos Maragkos <whitetowersoftware@gmail.com>
---
drivers/hid/hid-nintendo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
index 29008c2cc530..a701e396ee50 100644
--- a/drivers/hid/hid-nintendo.c
+++ b/drivers/hid/hid-nintendo.c
@@ -1453,7 +1453,6 @@ static void joycon_parse_imu_report(struct joycon_ctlr *ctlr,
dropped_threshold = ctlr->imu_avg_delta_ms * 3 / 2;
dropped_pkts = (delta - min(delta, dropped_threshold)) /
ctlr->imu_avg_delta_ms;
- ctlr->imu_timestamp_us += 1000 * ctlr->imu_avg_delta_ms;
if (dropped_pkts > JC_IMU_DROPPED_PKT_WARNING) {
hid_warn_ratelimited(ctlr->hdev,
"compensating for %u dropped IMU reports\n",
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 2/2] arm64: dts: qcom: glymur-crd: Add FocalTech ft3d81 touchscreen support
From: Dmitry Baryshkov @ 2026-06-03 14:00 UTC (permalink / raw)
To: Pradyot Kumar Nayak
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Peng, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
linux-arm-msm, linux-input, devicetree, linux-kernel,
Konrad Dybcio
In-Reply-To: <20260603-arm64-dts-glymur-crd-add-reset-gpio-to-v3-2-3453ef577bcf@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 08:41:20AM +0530, Pradyot Kumar Nayak wrote:
> The touchscreen module on Glymur/Mahua CRDs is different from
> the one used on Hamoa CRDs and requires the reset-gpios to be wired to
> the device. Without this in place the reset line will remain
> permanently asserted during resume leaving the device offline and causing
> all I2C transactions to fail with -ENXIO.
>
> i2c_hid_of 3-0038: failed to change power setting.
> i2c_hid_of 3-0038: PM: dpm_run_callback():
> i2c_hid_core_pm_resume [i2c_hid] returns -6
> i2c_hid_of 3-0038: PM: failed to resume async: error -6
>
> The touchscreen on Glymur/Mahua-CRD is a focaltech ft3d81,
> which is hardware-compatible with the ft8112.
> we have added the required change in DT.
>
> Fixes: e6bf559f7eb9 ("arm64: dts: qcom: glymur-crd: Enable keyboard, trackpad and touchscreen")
> Signed-off-by: Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/glymur-crd.dts | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [linux-6.6.y 2/3] HID: pass the buffer size to hid_report_raw_event
From: sashiko-bot @ 2026-06-03 13:44 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-input, dmitry.torokhov, bpf
In-Reply-To: <20260603133140.3069226-2-lee@kernel.org>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] The patch fails to resolve the short report regression because `hid_input_report()` incorrectly defaults `bufsize` to the received payload `size`.
- [High] `wacom_wac_queue_flush()` incorrectly passes `size` instead of `sizeof(buf)` as the `bufsize` parameter.
- [Low] Incorrect format specifiers in `hid_warn_ratelimited` cause compiler warnings on 32-bit platforms.
Pre-existing issues:
- [Critical] Unbounded `memcpy` in `dispatch_hid_bpf_device_event` leads to a heap buffer overflow.
--
commit e280aff3473f90b2372da480e1f061c96bb64fd0
Author: Benjamin Tissoires <bentiss@kernel.org>
HID: pass the buffer size to hid_report_raw_event
This patch adds a buffer size parameter to hid_report_raw_event() to better
differentiate between the allocated buffer capacity and the actual payload
size. This aims to reject buffer overflow attempts while safely zero-padding
valid short reports. The changes propagate the new parameter through various
HID transport drivers.
[ Upstream commit 2c85c61d1332e1e16f020d76951baf167dcb6f7a ]
> diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
> index 7903c8638e817..e0c03942ff7c4 100644
> --- a/drivers/hid/bpf/hid_bpf_dispatch.c
> +++ b/drivers/hid/bpf/hid_bpf_dispatch.c
> @@ -47,7 +47,7 @@ __weak noinline int hid_bpf_device_event(struct hid_bpf_ctx *ctx)
>
> u8 *
> dispatch_hid_bpf_device_event(struct hid_device *hdev, enum hid_report_type type, u8 *data,
> - u32 *size, int interrupt)
> + size_t *buf_size, u32 *size, int interrupt)
> {
[Severity: Critical]
This isn't a bug introduced by this patch, but can the memcpy inside this
function cause a heap buffer overflow?
When dispatch_hid_bpf_device_event() handles incoming events, it executes:
memset(ctx_kern.data, 0, hdev->bpf.allocated_data);
memcpy(ctx_kern.data, data, *size);
If a malicious device or a compromised userspace process using /dev/uhid
injects a report with a payload up to 4096 bytes (UHID_DATA_MAX), and this
exceeds hdev->bpf.allocated_data, doesn't this unbounded memcpy overwrite
the heap?
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index e3d728d67b538..c6d98634b97e6 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
[ ... ]
> @@ -1986,24 +1986,32 @@ int __hid_request(struct hid_device *hid, struct hid_report *report,
> }
> EXPORT_SYMBOL_GPL(__hid_request);
>
> -int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
> - int interrupt)
> +int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
> + size_t bufsize, u32 size, int interrupt)
> {
> struct hid_report_enum *report_enum = hid->report_enum + type;
> struct hid_report *report;
> struct hid_driver *hdrv;
> int max_buffer_size = HID_MAX_BUFFER_SIZE;
> u32 rsize, csize = size;
> + size_t bsize = bufsize;
> u8 *cdata = data;
> int ret = 0;
>
> report = hid_get_report(report_enum, data);
> if (!report)
> - goto out;
> + return 0;
> +
> + if (unlikely(bsize < csize)) {
> + hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
> + report->id, csize, bsize);
[Severity: Low]
Does using %ld for size_t cause compiler warnings on 32-bit platforms?
Since size_t is an unsigned int on 32-bit architectures, shouldn't we use
%zu for bsize, and %u instead of %d for csize?
> + return -EINVAL;
> + }
>
[ ... ]
> @@ -2055,12 +2069,13 @@ EXPORT_SYMBOL_GPL(hid_report_raw_event);
> *
> * This is data entry for lower layers.
> */
> -int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
> - int interrupt)
> +int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data,
> + u32 size, int interrupt)
> {
> struct hid_report_enum *report_enum;
> struct hid_driver *hdrv;
> struct hid_report *report;
> + size_t bufsize = size;
[Severity: High]
Does setting bufsize to size defeat the purpose of the new bounds checks?
By initializing bufsize to the received payload size instead of the
actual buffer capacity, the new checks in hid_report_raw_event():
if (bsize < rsize) {
hid_warn_ratelimited(...);
return -EINVAL;
}
will always evaluate to true for short reports, as bsize will equal the short
payload size (csize). Will this unconditionally reject short reports and
leave the original regression unfixed for standard HID devices?
> int ret = 0;
>
[ ... ]
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 52011503ff3ba..52b7f474d8669 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -74,7 +74,7 @@ static void wacom_wac_queue_flush(struct hid_device *hdev,
> int err;
>
> size = kfifo_out(fifo, buf, sizeof(buf));
> - err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, false);
> + err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, size, false);
[Severity: High]
Should this pass sizeof(buf) as the buffer size instead of size?
Because buf is allocated as u8 buf[WACOM_PKGLEN_MAX] in this function,
passing size (the number of bytes read) as both bufsize and size means
the buffer size limit equals the payload size.
If this is a valid short report, won't it be incorrectly rejected by the
new size checks in hid_report_raw_event()?
> if (err) {
> hid_warn(hdev, "%s: unable to flush event due to error %d\n",
> __func__, err);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260603133140.3069226-2-lee@kernel.org?part=1
^ permalink raw reply
* Re: [PATCH v2 2/2] HID: nintendo: Use %pM format specifier for MAC addresses
From: Andy Shevchenko @ 2026-06-03 13:42 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Daniel J. Ogorchock, Petr Mladek, Tamir Duberstein,
linux-doc, linux-kernel, linux-input, Steven Rostedt,
Rasmus Villemoes, Sergey Senozhatsky, Jonathan Corbet, Shuah Khan,
Andrew Morton
In-Reply-To: <aiAXraQh-IrbAe0C@beelink>
On Wed, Jun 03, 2026 at 02:03:01PM +0200, Benjamin Tissoires wrote:
> On Jun 03 2026, Andy Shevchenko wrote:
> > Convert to %pM instead of using custom code.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Not sure where the first patch should land,
Up to the maintainers Petr and you, to me it makes no difference.
> so in case someone prefers having the full series through their tree:
> Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Thank you!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [linux-6.6.y 3/3] HID: core: Fix size_t specifier in hid_report_raw_event()
From: Lee Jones @ 2026-06-03 13:31 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Filipe Laíns,
Bastien Nocera, Ping Cheng, Jason Gerecke, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman, Sasha Levin,
linux-input, linux-kernel, greybus-dev, linux-staging, bpf
Cc: stable, Nathan Chancellor, Miguel Ojeda, Linus Torvalds
In-Reply-To: <20260603133140.3069226-1-lee@kernel.org>
From: Nathan Chancellor <nathan@kernel.org>
[ Upstream commit 4d3a2a466b8d68d852a1f3bbf11204b718428dc4 ]
When building for 32-bit platforms, for which 'size_t' is
'unsigned int', there are warnings around using the incorrect format
specifier to print bsize in hid_report_raw_event():
drivers/hid/hid-core.c:2054:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
2053 | hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
| ~~~
| %zu
2054 | report->id, csize, bsize);
| ^~~~~
drivers/hid/hid-core.c:2076:29: error: format specifies type 'long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
2075 | hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
| ~~~
| %zu
2076 | report->id, rsize, bsize);
| ^~~~~
Use the proper 'size_t' format specifier, '%zu', to clear up the
warnings.
Cc: stable@vger.kernel.org
Fixes: 2c85c61d1332 ("HID: pass the buffer size to hid_report_raw_event")
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://lore.kernel.org/20260516020430.110135-1-ojeda@kernel.org/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 3ab135238832446399614e7a4bb796d620717806)
Signed-off-by: Lee Jones <lee@kernel.org>
(cherry picked from commit 76606eed6cb62ec97afcc270948ef8335d02e944)
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/hid-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index c6d98634b97e..2de4d831c526 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2003,7 +2003,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
return 0;
if (unlikely(bsize < csize)) {
- hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
+ hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %zu)\n",
report->id, csize, bsize);
return -EINVAL;
}
@@ -2025,7 +2025,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
rsize = max_buffer_size;
if (bsize < rsize) {
- hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
+ hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %zu)\n",
report->id, rsize, bsize);
return -EINVAL;
}
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [linux-6.6.y 2/3] HID: pass the buffer size to hid_report_raw_event
From: Lee Jones @ 2026-06-03 13:31 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Filipe Laíns,
Bastien Nocera, Ping Cheng, Jason Gerecke, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman, Sasha Levin,
linux-input, linux-kernel, greybus-dev, linux-staging, bpf
Cc: stable, Benjamin Tissoires, Jiri Kosina
In-Reply-To: <20260603133140.3069226-1-lee@kernel.org>
From: Benjamin Tissoires <bentiss@kernel.org>
[ Upstream commit 2c85c61d1332e1e16f020d76951baf167dcb6f7a ]
commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
bogus memset()") enforced the provided data to be at least the size of
the declared buffer in the report descriptor to prevent a buffer
overflow. However, we can try to be smarter by providing both the buffer
size and the data size, meaning that hid_report_raw_event() can make
better decision whether we should plaining reject the buffer (buffer
overflow attempt) or if we can safely memset it to 0 and pass it to the
rest of the stack.
Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Acked-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Stable-dep-of: 206342541fc8 ("HID: core: introduce hid_safe_input_report()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 509c2605065004fc4cd86ee50a9350d402785307)
[Lee: Backported to linux-6.12.y and beyond]
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/bpf/hid_bpf_dispatch.c | 3 ++-
drivers/hid/hid-core.c | 35 +++++++++++++++++++++---------
drivers/hid/hid-gfrm.c | 4 ++--
drivers/hid/hid-logitech-hidpp.c | 2 +-
drivers/hid/hid-multitouch.c | 2 +-
drivers/hid/hid-primax.c | 2 +-
drivers/hid/hid-vivaldi-common.c | 2 +-
drivers/hid/wacom_sys.c | 6 ++---
drivers/staging/greybus/hid.c | 2 +-
include/linux/hid.h | 4 ++--
include/linux/hid_bpf.h | 4 ++--
11 files changed, 41 insertions(+), 25 deletions(-)
diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
index 7903c8638e81..e0c03942ff7c 100644
--- a/drivers/hid/bpf/hid_bpf_dispatch.c
+++ b/drivers/hid/bpf/hid_bpf_dispatch.c
@@ -47,7 +47,7 @@ __weak noinline int hid_bpf_device_event(struct hid_bpf_ctx *ctx)
u8 *
dispatch_hid_bpf_device_event(struct hid_device *hdev, enum hid_report_type type, u8 *data,
- u32 *size, int interrupt)
+ size_t *buf_size, u32 *size, int interrupt)
{
struct hid_bpf_ctx_kern ctx_kern = {
.ctx = {
@@ -81,6 +81,7 @@ dispatch_hid_bpf_device_event(struct hid_device *hdev, enum hid_report_type type
*size = ret;
}
+ *buf_size = ctx_kern.ctx.allocated_size;
return ctx_kern.data;
}
EXPORT_SYMBOL_GPL(dispatch_hid_bpf_device_event);
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e3d728d67b53..c6d98634b97e 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1986,24 +1986,32 @@ int __hid_request(struct hid_device *hid, struct hid_report *report,
}
EXPORT_SYMBOL_GPL(__hid_request);
-int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
- int interrupt)
+int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
+ size_t bufsize, u32 size, int interrupt)
{
struct hid_report_enum *report_enum = hid->report_enum + type;
struct hid_report *report;
struct hid_driver *hdrv;
int max_buffer_size = HID_MAX_BUFFER_SIZE;
u32 rsize, csize = size;
+ size_t bsize = bufsize;
u8 *cdata = data;
int ret = 0;
report = hid_get_report(report_enum, data);
if (!report)
- goto out;
+ return 0;
+
+ if (unlikely(bsize < csize)) {
+ hid_warn_ratelimited(hid, "Event data for report %d is incorrect (%d vs %ld)\n",
+ report->id, csize, bsize);
+ return -EINVAL;
+ }
if (report_enum->numbered) {
cdata++;
csize--;
+ bsize--;
}
rsize = hid_compute_report_size(report);
@@ -2016,9 +2024,15 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
else if (rsize > max_buffer_size)
rsize = max_buffer_size;
+ if (bsize < rsize) {
+ hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %ld)\n",
+ report->id, rsize, bsize);
+ return -EINVAL;
+ }
+
if (csize < rsize) {
dbg_hid("report %d is too short, (%d < %d)\n", report->id,
- csize, rsize);
+ csize, rsize);
memset(cdata + csize, 0, rsize - csize);
}
@@ -2027,7 +2041,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
if (hid->claimed & HID_CLAIMED_HIDRAW) {
ret = hidraw_report_event(hid, data, size);
if (ret)
- goto out;
+ return ret;
}
if (hid->claimed != HID_CLAIMED_HIDRAW && report->maxfield) {
@@ -2039,7 +2053,7 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
if (hid->claimed & HID_CLAIMED_INPUT)
hidinput_report_event(hid, report);
-out:
+
return ret;
}
EXPORT_SYMBOL_GPL(hid_report_raw_event);
@@ -2055,12 +2069,13 @@ EXPORT_SYMBOL_GPL(hid_report_raw_event);
*
* This is data entry for lower layers.
*/
-int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
- int interrupt)
+int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data,
+ u32 size, int interrupt)
{
struct hid_report_enum *report_enum;
struct hid_driver *hdrv;
struct hid_report *report;
+ size_t bufsize = size;
int ret = 0;
if (!hid)
@@ -2076,7 +2091,7 @@ int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data
report_enum = hid->report_enum + type;
hdrv = hid->driver;
- data = dispatch_hid_bpf_device_event(hid, type, data, &size, interrupt);
+ data = dispatch_hid_bpf_device_event(hid, type, data, &bufsize, &size, interrupt);
if (IS_ERR(data)) {
ret = PTR_ERR(data);
goto unlock;
@@ -2105,7 +2120,7 @@ int hid_input_report(struct hid_device *hid, enum hid_report_type type, u8 *data
goto unlock;
}
- ret = hid_report_raw_event(hid, type, data, size, interrupt);
+ ret = hid_report_raw_event(hid, type, data, bufsize, size, interrupt);
unlock:
up(&hid->driver_input_lock);
diff --git a/drivers/hid/hid-gfrm.c b/drivers/hid/hid-gfrm.c
index 699186ff2349..d2a56bf92b41 100644
--- a/drivers/hid/hid-gfrm.c
+++ b/drivers/hid/hid-gfrm.c
@@ -66,7 +66,7 @@ static int gfrm_raw_event(struct hid_device *hdev, struct hid_report *report,
switch (data[1]) {
case GFRM100_SEARCH_KEY_DOWN:
ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, search_key_dn,
- sizeof(search_key_dn), 1);
+ sizeof(search_key_dn), sizeof(search_key_dn), 1);
break;
case GFRM100_SEARCH_KEY_AUDIO_DATA:
@@ -74,7 +74,7 @@ static int gfrm_raw_event(struct hid_device *hdev, struct hid_report *report,
case GFRM100_SEARCH_KEY_UP:
ret = hid_report_raw_event(hdev, HID_INPUT_REPORT, search_key_up,
- sizeof(search_key_up), 1);
+ sizeof(search_key_up), sizeof(search_key_up), 1);
break;
default:
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 339a227c457e..113307157a27 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -3692,7 +3692,7 @@ static int hidpp10_consumer_keys_raw_event(struct hidpp_device *hidpp,
memcpy(&consumer_report[1], &data[3], 4);
/* We are called from atomic context */
hid_report_raw_event(hidpp->hid_dev, HID_INPUT_REPORT,
- consumer_report, 5, 1);
+ consumer_report, sizeof(consumer_report), 5, 1);
return 1;
}
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 003950894362..6c04eed0a464 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -479,7 +479,7 @@ static void mt_get_feature(struct hid_device *hdev, struct hid_report *report)
}
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, buf,
- size, 0);
+ size, size, 0);
if (ret)
dev_warn(&hdev->dev, "failed to report feature\n");
}
diff --git a/drivers/hid/hid-primax.c b/drivers/hid/hid-primax.c
index 1e6413d07cae..16e2a811eda9 100644
--- a/drivers/hid/hid-primax.c
+++ b/drivers/hid/hid-primax.c
@@ -44,7 +44,7 @@ static int px_raw_event(struct hid_device *hid, struct hid_report *report,
data[0] |= (1 << (data[idx] - 0xE0));
data[idx] = 0;
}
- hid_report_raw_event(hid, HID_INPUT_REPORT, data, size, 0);
+ hid_report_raw_event(hid, HID_INPUT_REPORT, data, size, size, 0);
return 1;
default: /* unknown report */
diff --git a/drivers/hid/hid-vivaldi-common.c b/drivers/hid/hid-vivaldi-common.c
index b0af2be94895..7fb986615768 100644
--- a/drivers/hid/hid-vivaldi-common.c
+++ b/drivers/hid/hid-vivaldi-common.c
@@ -85,7 +85,7 @@ void vivaldi_feature_mapping(struct hid_device *hdev,
}
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT, report_data,
- report_len, 0);
+ report_len, report_len, 0);
if (ret) {
dev_warn(&hdev->dev, "failed to report feature %d\n",
field->report->id);
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 52011503ff3b..52b7f474d866 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -74,7 +74,7 @@ static void wacom_wac_queue_flush(struct hid_device *hdev,
int err;
size = kfifo_out(fifo, buf, sizeof(buf));
- err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, false);
+ err = hid_report_raw_event(hdev, HID_INPUT_REPORT, buf, size, size, false);
if (err) {
hid_warn(hdev, "%s: unable to flush event due to error %d\n",
__func__, err);
@@ -319,7 +319,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
data, n, WAC_CMD_RETRIES);
if (ret == n && features->type == HID_GENERIC) {
ret = hid_report_raw_event(hdev,
- HID_FEATURE_REPORT, data, n, 0);
+ HID_FEATURE_REPORT, data, n, n, 0);
} else if (ret == 2 && features->type != HID_GENERIC) {
features->touch_max = data[1];
} else {
@@ -380,7 +380,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
data, n, WAC_CMD_RETRIES);
if (ret == n) {
ret = hid_report_raw_event(hdev, HID_FEATURE_REPORT,
- data, n, 0);
+ data, n, n, 0);
} else {
hid_warn(hdev, "%s: could not retrieve sensor offsets\n",
__func__);
diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c
index 15335c38cb26..e761411ccf64 100644
--- a/drivers/staging/greybus/hid.c
+++ b/drivers/staging/greybus/hid.c
@@ -201,7 +201,7 @@ static void gb_hid_init_report(struct gb_hid *ghid, struct hid_report *report)
* we just need to setup the input fields, so using
* hid_report_raw_event is safe.
*/
- hid_report_raw_event(ghid->hid, report->type, ghid->inbuf, size, 1);
+ hid_report_raw_event(ghid->hid, report->type, ghid->inbuf, ghid->bufsize, size, 1);
}
static void gb_hid_init_reports(struct gb_hid *ghid)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index f4bdaf1b8f41..a9857fdfc327 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -1205,8 +1205,8 @@ static inline u32 hid_report_len(struct hid_report *report)
return DIV_ROUND_UP(report->size, 8) + (report->id > 0);
}
-int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data, u32 size,
- int interrupt);
+int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
+ size_t bufsize, u32 size, int interrupt);
/* HID quirks API */
unsigned long hid_lookup_quirk(const struct hid_device *hdev);
diff --git a/include/linux/hid_bpf.h b/include/linux/hid_bpf.h
index e9afb61e6ee0..eafaac1109ac 100644
--- a/include/linux/hid_bpf.h
+++ b/include/linux/hid_bpf.h
@@ -147,7 +147,7 @@ struct hid_bpf_link {
#ifdef CONFIG_HID_BPF
u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
- u32 *size, int interrupt);
+ size_t *buf_size, u32 *size, int interrupt);
int hid_bpf_connect_device(struct hid_device *hdev);
void hid_bpf_disconnect_device(struct hid_device *hdev);
void hid_bpf_destroy_device(struct hid_device *hid);
@@ -155,7 +155,7 @@ void hid_bpf_device_init(struct hid_device *hid);
u8 *call_hid_bpf_rdesc_fixup(struct hid_device *hdev, u8 *rdesc, unsigned int *size);
#else /* CONFIG_HID_BPF */
static inline u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type,
- u8 *data, u32 *size, int interrupt) { return data; }
+ u8 *data, size_t *buf_size, u32 *size, int interrupt) { return data; }
static inline int hid_bpf_connect_device(struct hid_device *hdev) { return 0; }
static inline void hid_bpf_disconnect_device(struct hid_device *hdev) {}
static inline void hid_bpf_destroy_device(struct hid_device *hid) {}
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [linux-6.6.y 1/3] HID: core: Add printk_ratelimited variants to hid_warn() etc
From: Lee Jones @ 2026-06-03 13:31 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, Filipe Laíns,
Bastien Nocera, Ping Cheng, Jason Gerecke, Viresh Kumar,
Johan Hovold, Alex Elder, Greg Kroah-Hartman, Sasha Levin,
linux-input, linux-kernel, greybus-dev, linux-staging, bpf
Cc: stable, Vicki Pfau, Jiri Kosina
From: Vicki Pfau <vi@endrift.com>
hid_warn_ratelimited() is needed. Add the others as part of the block.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
(cherry picked from commit 1d64624243af8329b4b219d8c39e28ea448f9929)
Signed-off-by: Lee Jones <lee@kernel.org>
---
include/linux/hid.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 5d37e2349fae..f4bdaf1b8f41 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -1252,4 +1252,15 @@ int hid_pidff_init_with_quirks(struct hid_device *hid, __u32 initial_quirks);
#define hid_dbg_once(hid, fmt, ...) \
dev_dbg_once(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_err_ratelimited(hid, fmt, ...) \
+ dev_err_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_notice_ratelimited(hid, fmt, ...) \
+ dev_notice_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_warn_ratelimited(hid, fmt, ...) \
+ dev_warn_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_info_ratelimited(hid, fmt, ...) \
+ dev_info_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+#define hid_dbg_ratelimited(hid, fmt, ...) \
+ dev_dbg_ratelimited(&(hid)->dev, fmt, ##__VA_ARGS__)
+
#endif
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* Re: [PATCH v2 2/3] HID: i2c-hid: Move common ACPI _DSM helper into core
From: Benjamin Tissoires @ 2026-06-03 13:30 UTC (permalink / raw)
To: Hans de Goede
Cc: 谢致邦 (XIE Zhibang), linux-input,
dmitry.torokhov, dianders, jikos, linux-kernel, superm1,
Pin-yen Lin, Xu Rao, Kwok Kin Ming, Dan Carpenter
In-Reply-To: <45b88710-7c67-414d-8ebc-2abafa80a760@kernel.org>
On Jun 03 2026, Hans de Goede wrote:
> Hi,
>
> On 3-Jun-26 1:59 PM, Benjamin Tissoires wrote:
> > On Jun 03 2026, Hans de Goede wrote:
> >> Hi Benjamin,
> >>
> >> On 3-Jun-26 11:43 AM, Benjamin Tissoires wrote:
> >>> On Jun 01 2026, 谢致邦 (XIE Zhibang) wrote:
> >>>> Move the _DSM call that gets the HID descriptor address from
> >>>> i2c-hid-acpi.c to a shared helper in i2c-hid-core.c so both
> >>>> i2c-hid-acpi.c and i2c-hid-of.c can use it.
> >>>>
> >>>> Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
> >>>> ---
> >>>> drivers/hid/i2c-hid/i2c-hid-acpi.c | 32 ++++-----------------------
> >>>> drivers/hid/i2c-hid/i2c-hid-core.c | 35 ++++++++++++++++++++++++++++++
> >>>
> >>> I'm not a big fan of removing 25% of the i2c-hid-acpi.c code and inject
> >>> it in i2c-hid-core.c.
> >>
> >> It is only 35 new lines in i2c-hid-core.c, so it is not that big / much code.
> >
> > My concern is not so much about these 35 lines of code, but the fact
> > that i2c-hid-acpi.c is now down to only 3 functions:
> > - i2c_hid_acpi_probe()
> > - i2c_hid_acpi_shutdown_tail()
> > - i2c_hid_acpi_restore_sequence()
> >
> > So then, what's the point of keeping it as a separate driver? (more
> > rethorical question than anything).
> >
> >>
> >>> There's something I can't really understand in the problem:
> >>> - we are talking about non arm architecture, which should not have OF in
> >>> them
> >>> - the current compatible hid-over-i2c loads the OF version?
> >>> - how can you make the device working without the couple of ACPI
> >>> functions that are in the i2c-hid-acpi.c driver for powering up and
> >>> down the device?
> >>>
> >>> If the platform is indeed ACPI + x86(_64), then shouldn't we tackle the
> >>> problem in the i2c-hid-acpi driver, or add a secondary leaf driver for
> >>> this particular platform/device? Kind of what we have with
> >>> i2c-hid-of-elan.c
> >>
> >> As part of the work to use ACPI on ARM systems, it is possible now a days
> >> to inject DT snippets into ACPI tables.
> >>
> >> The problem on these Loongson laptops is that they have created this
> >> very ugly mixed-mode where they put a PRP0001 ACPI HID on the ACPI
> >> node for the touchscreen, which means it contains an embedded DT
> >> snippet and in that snipped out "compatible=hid-over-i2c" but NOT
> >> also "i2c-hid-descr-addr=x". To get the i2c-hid descriptor address
> >> the implemented the ACPI _DSM on the same ACPI device/fwnode.
> >>
> >> The ACPI core sees HID=PRP0001 so it creates an of-compatible
> >> modalias / match and not an ACPI one, so the i2c-hid-of driver will
> >> bind.
> >
> > But if this fix is for just one platform, why not keeping the design
> > clean and have a dmi_match instead in a separate driver, like the
> > i2c-hid-of-elan does for Elan touchpads/touchscreens?
> > i2c-hid-acpi-loongson.c for instance.
>
> Ok, so let me see if I've got this right:
>
> 1. We create a i2c-hid-acpi-loongson.c with a DMI
> MODULE_DEVICE_TABLE() for auto-module-loading
Yes
>
> 2. This will have a struct of_device_id table with
> the "hid-over-i2c" compatible. But *no* / without a
> MODULE_DEVICE_TABLE() for this so that it will not
> autoload on regular DT platforms with regular
> "hid-over-i2c" compatible touchscreens.
Yes
>
> 3. We will rely on i2c-hid-of.c error-ing out
> due to the missing "hid-descr-addr" and we are ok
> with the dev_err() this logs.
Yes, if we want the big fat warning that Dmitry was mentioning.
Otherwise we could also have a deny list table, but that's more work :)
>
> 4. The new i2c-hid-acpi-loongson.c will in essence
> be a copy of i2c-hid-acpi.c without the acpi_match
> and with the DMI id + of match as described above.
Sort of, yeah
>
> Yes I think that should work, do you want to just copy
> i2c_hid_acpi_get_descriptor() or do you want
> i2c-hid-acpi to export this and have i2c-hid-acpi-longsoon
> depend on i2c-hid-acpi for this ?
Export i2c_hid_acpi_get_descriptor() from i2c-hid-acpi and have
i2c-hid-acpi-longsoon depend on it.
Also, this would have the good side effect of being able to set the post
power and post reset delays based on the DMI. Kind of like a compatible
driver in the DT world.
>
> >> Note these "fixed" (as in we cannot fix them) ACPI tables use
> >> the generic i2c-over-hid OF/DT compatible _not_ something
> >> more specific so we can also not do a more specific driver like
> >> i2c-hid-of-elan.c.
> >
> > Do they use anything else than the compatible DT entry? regulators and
> > others? If not, then the device is pure ACPI, and should not be handled
> > by i2c-hid-of.c at all, no?
>
> No they don't use anything other then the compatible. This is
> really just a very bad / messy decision by whomever created
> the ACPI tables for these 2 laptops. But they are out there, so
> we somehow have to deal with them.
Yeah, so I think we better have this special driver for the Loongson
platform, and have device crap handled in this place without polluting
the rest.
Cheers,
Benjamin
>
> <snip>
>
> > so far :)
>
> True, see above.
>
> Regards,
>
> Hans
>
>
>
>
^ permalink raw reply
* Re: [PATCH v2 2/3] HID: i2c-hid: Move common ACPI _DSM helper into core
From: Hans de Goede @ 2026-06-03 13:12 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: 谢致邦 (XIE Zhibang), linux-input,
dmitry.torokhov, dianders, jikos, linux-kernel, superm1,
Pin-yen Lin, Xu Rao, Kwok Kin Ming, Dan Carpenter
In-Reply-To: <aiAW9sSLVqmT6l87@beelink>
Hi,
On 3-Jun-26 1:59 PM, Benjamin Tissoires wrote:
> On Jun 03 2026, Hans de Goede wrote:
>> Hi Benjamin,
>>
>> On 3-Jun-26 11:43 AM, Benjamin Tissoires wrote:
>>> On Jun 01 2026, 谢致邦 (XIE Zhibang) wrote:
>>>> Move the _DSM call that gets the HID descriptor address from
>>>> i2c-hid-acpi.c to a shared helper in i2c-hid-core.c so both
>>>> i2c-hid-acpi.c and i2c-hid-of.c can use it.
>>>>
>>>> Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
>>>> ---
>>>> drivers/hid/i2c-hid/i2c-hid-acpi.c | 32 ++++-----------------------
>>>> drivers/hid/i2c-hid/i2c-hid-core.c | 35 ++++++++++++++++++++++++++++++
>>>
>>> I'm not a big fan of removing 25% of the i2c-hid-acpi.c code and inject
>>> it in i2c-hid-core.c.
>>
>> It is only 35 new lines in i2c-hid-core.c, so it is not that big / much code.
>
> My concern is not so much about these 35 lines of code, but the fact
> that i2c-hid-acpi.c is now down to only 3 functions:
> - i2c_hid_acpi_probe()
> - i2c_hid_acpi_shutdown_tail()
> - i2c_hid_acpi_restore_sequence()
>
> So then, what's the point of keeping it as a separate driver? (more
> rethorical question than anything).
>
>>
>>> There's something I can't really understand in the problem:
>>> - we are talking about non arm architecture, which should not have OF in
>>> them
>>> - the current compatible hid-over-i2c loads the OF version?
>>> - how can you make the device working without the couple of ACPI
>>> functions that are in the i2c-hid-acpi.c driver for powering up and
>>> down the device?
>>>
>>> If the platform is indeed ACPI + x86(_64), then shouldn't we tackle the
>>> problem in the i2c-hid-acpi driver, or add a secondary leaf driver for
>>> this particular platform/device? Kind of what we have with
>>> i2c-hid-of-elan.c
>>
>> As part of the work to use ACPI on ARM systems, it is possible now a days
>> to inject DT snippets into ACPI tables.
>>
>> The problem on these Loongson laptops is that they have created this
>> very ugly mixed-mode where they put a PRP0001 ACPI HID on the ACPI
>> node for the touchscreen, which means it contains an embedded DT
>> snippet and in that snipped out "compatible=hid-over-i2c" but NOT
>> also "i2c-hid-descr-addr=x". To get the i2c-hid descriptor address
>> the implemented the ACPI _DSM on the same ACPI device/fwnode.
>>
>> The ACPI core sees HID=PRP0001 so it creates an of-compatible
>> modalias / match and not an ACPI one, so the i2c-hid-of driver will
>> bind.
>
> But if this fix is for just one platform, why not keeping the design
> clean and have a dmi_match instead in a separate driver, like the
> i2c-hid-of-elan does for Elan touchpads/touchscreens?
> i2c-hid-acpi-loongson.c for instance.
Ok, so let me see if I've got this right:
1. We create a i2c-hid-acpi-loongson.c with a DMI
MODULE_DEVICE_TABLE() for auto-module-loading
2. This will have a struct of_device_id table with
the "hid-over-i2c" compatible. But *no* / without a
MODULE_DEVICE_TABLE() for this so that it will not
autoload on regular DT platforms with regular
"hid-over-i2c" compatible touchscreens.
3. We will rely on i2c-hid-of.c error-ing out
due to the missing "hid-descr-addr" and we are ok
with the dev_err() this logs.
4. The new i2c-hid-acpi-loongson.c will in essence
be a copy of i2c-hid-acpi.c without the acpi_match
and with the DMI id + of match as described above.
Yes I think that should work, do you want to just copy
i2c_hid_acpi_get_descriptor() or do you want
i2c-hid-acpi to export this and have i2c-hid-acpi-longsoon
depend on i2c-hid-acpi for this ?
>> Note these "fixed" (as in we cannot fix them) ACPI tables use
>> the generic i2c-over-hid OF/DT compatible _not_ something
>> more specific so we can also not do a more specific driver like
>> i2c-hid-of-elan.c.
>
> Do they use anything else than the compatible DT entry? regulators and
> others? If not, then the device is pure ACPI, and should not be handled
> by i2c-hid-of.c at all, no?
No they don't use anything other then the compatible. This is
really just a very bad / messy decision by whomever created
the ACPI tables for these 2 laptops. But they are out there, so
we somehow have to deal with them.
<snip>
> so far :)
True, see above.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v2] HID: wacom: fix slab-out-of-bounds write in wacom_wac_queue_insert
From: Jiri Kosina @ 2026-06-03 12:24 UTC (permalink / raw)
To: Jinmo Yang; +Cc: linux-input, dmitry.torokhov, benjamin.tissoires, stable
In-Reply-To: <20260528175945.2987781-1-jinmo44.yang@gmail.com>
On Fri, 29 May 2026, Jinmo Yang wrote:
> wacom_wac_queue_insert() calls kfifo_skip() in a loop when the kfifo
> doesn't have enough space for the incoming report. If the kfifo is
> empty, kfifo_skip() reads stale data left in the kmalloc'd buffer
> via __kfifo_peek_n() and interprets it as a record length, advancing
> fifo->out by that garbage value. This corrupts the internal kfifo
> state, causing kfifo_unused() to return a value much larger than the
> actual buffer size, which bypasses __kfifo_in_r()'s guard:
>
> if (len + recsize > kfifo_unused(fifo))
> return 0;
>
> kfifo_copy_in() then performs an out-of-bounds memcpy, writing up to
> 3842 bytes past the 256-byte buffer.
>
> Add a !kfifo_is_empty() condition to the while loop so kfifo_skip()
> is never called on an empty fifo, and check the return value of
> kfifo_in() to reject reports that are too large for the fifo.
>
> Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Fixes: 5e013ad20689 ("HID: wacom: Remove static WACOM_PKGLEN_MAX limit")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jinmo Yang <jinmo44.yang@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: wacom: stop hardware after post-start probe failures
From: Jiri Kosina @ 2026-06-03 12:22 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Myeonghun Pak, Ping Cheng, Jason Gerecke, Benjamin Tissoires,
linux-input, linux-kernel, stable, Ijae Kim
In-Reply-To: <ahdE9G8I7kd_OoGW@google.com>
On Wed, 27 May 2026, Dmitry Torokhov wrote:
> > wacom_parse_and_register() starts HID hardware before registering inputs
> > and initializing pad LEDs/remotes. Those later steps can fail, but their
> > error paths currently release Wacom resources without stopping the HID
> > hardware.
> >
> > Route post-hid_hw_start() failures through hid_hw_stop() before
> > releasing driver resources.
> >
> > This issue was identified during our ongoing static-analysis research while
> > reviewing kernel code.
> >
> > Fixes: c1d6708bf0d3 ("HID: wacom: Do not register input devices until after hid_hw_start")
> > Cc: stable@vger.kernel.org
> > Co-developed-by: Ijae Kim <ae878000@gmail.com>
> > Signed-off-by: Ijae Kim <ae878000@gmail.com>
> > Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> > ---
> > drivers/hid/wacom_sys.c | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> > index 0d1c6d90fe..c824d9c224 100644
> > --- a/drivers/hid/wacom_sys.c
> > +++ b/drivers/hid/wacom_sys.c
> > @@ -2456,16 +2456,16 @@ static int wacom_parse_and_register(struct wacom *wacom, bool wireless)
> >
> > error = wacom_register_inputs(wacom);
> > if (error)
> > - goto fail;
> > + goto fail_hw_stop;
> >
> > if (wacom->wacom_wac.features.device_type & WACOM_DEVICETYPE_PAD) {
> > error = wacom_initialize_leds(wacom);
> > if (error)
> > - goto fail;
> > + goto fail_hw_stop;
> >
> > error = wacom_initialize_remotes(wacom);
> > if (error)
> > - goto fail;
> > + goto fail_hw_stop;
> > }
> >
> > if (!wireless) {
> > @@ -2496,6 +2496,7 @@ static int wacom_parse_and_register(struct wacom *wacom, bool wireless)
> > return 0;
> >
> > fail_quirks:
> > +fail_hw_stop:
> > hid_hw_stop(hdev);
> > fail:
> > wacom_release_resources(wacom);
>
> I'd get rid of 'fail_quirks' and use 'fail_hw_stop' everywhere,
Agreed. Myeonghun, will you send v2 please?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: hid-lenovo-go: cancel cfg_setup work in hid_go_cfg_remove()
From: Jiri Kosina @ 2026-06-03 12:19 UTC (permalink / raw)
To: Manish Khadka
Cc: linux-input, Derek J . Clark, Mark Pearson, Benjamin Tissoires,
linux-kernel
In-Reply-To: <20260515153607.76175-1-maskmemanish@gmail.com>
On Fri, 15 May 2026, Manish Khadka wrote:
> hid_go_cfg_probe() initialises drvdata.go_cfg_setup and schedules it
> to run 2 ms later:
>
> INIT_DELAYED_WORK(&drvdata.go_cfg_setup, &cfg_setup);
> schedule_delayed_work(&drvdata.go_cfg_setup, msecs_to_jiffies(2));
>
> cfg_setup() dereferences drvdata.hdev to issue MCU command requests.
> hid_go_cfg_remove() tears down sysfs and stops the HID device, ending
> with hid_set_drvdata(hdev, NULL), but never drains the delayed work.
> If the device is unbound within the 2 ms scheduling delay (a probe
> failure rolling back via remove, or a fast rmmod after probe), the
> work fires after hid_set_drvdata(NULL) has cleared the back pointer,
> leaving cfg_setup() with a NULL or stale drvdata.hdev.
>
> Mirror the sibling driver hid-lenovo-go-s.c, whose hid_gos_cfg_remove()
> already calls cancel_delayed_work_sync() on its analogous work, and
> drain go_cfg_setup at the top of hid_go_cfg_remove(). The cancel
> must come before guard(mutex)(&drvdata.cfg_mutex) because cfg_setup()
> acquires that mutex; reversing the order would deadlock.
>
> Fixes: d69ccfcbc955 ("HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Manish Khadka <maskmemanish@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 2/2] HID: nintendo: Use %pM format specifier for MAC addresses
From: Benjamin Tissoires @ 2026-06-03 12:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jiri Kosina, Daniel J. Ogorchock, Petr Mladek, Tamir Duberstein,
linux-doc, linux-kernel, linux-input, Steven Rostedt,
Rasmus Villemoes, Sergey Senozhatsky, Jonathan Corbet, Shuah Khan,
Andrew Morton
In-Reply-To: <20260603104351.152085-3-andriy.shevchenko@linux.intel.com>
On Jun 03 2026, Andy Shevchenko wrote:
> Convert to %pM instead of using custom code.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Not sure where the first patch should land, so in case someone prefers
having the full series through their tree:
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Cheers,
Benjamin
> ---
> drivers/hid/hid-nintendo.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hid/hid-nintendo.c b/drivers/hid/hid-nintendo.c
> index 29008c2cc530..05c50f2530ef 100644
> --- a/drivers/hid/hid-nintendo.c
> +++ b/drivers/hid/hid-nintendo.c
> @@ -2431,14 +2431,8 @@ static int joycon_read_info(struct joycon_ctlr *ctlr)
> for (i = 4, j = 0; j < 6; i++, j++)
> ctlr->mac_addr[j] = report->subcmd_reply.data[i];
>
> - ctlr->mac_addr_str = devm_kasprintf(&ctlr->hdev->dev, GFP_KERNEL,
> - "%02X:%02X:%02X:%02X:%02X:%02X",
> - ctlr->mac_addr[0],
> - ctlr->mac_addr[1],
> - ctlr->mac_addr[2],
> - ctlr->mac_addr[3],
> - ctlr->mac_addr[4],
> - ctlr->mac_addr[5]);
> + ctlr->mac_addr_str = devm_kasprintf(&ctlr->hdev->dev, GFP_KERNEL, "%pMU",
> + ctlr->mac_addr);
> if (!ctlr->mac_addr_str)
> return -ENOMEM;
> hid_info(ctlr->hdev, "controller MAC = %s\n", ctlr->mac_addr_str);
> --
> 2.50.1
>
>
^ permalink raw reply
* Re: [PATCH v2 2/3] HID: i2c-hid: Move common ACPI _DSM helper into core
From: Benjamin Tissoires @ 2026-06-03 11:59 UTC (permalink / raw)
To: Hans de Goede
Cc: 谢致邦 (XIE Zhibang), linux-input,
dmitry.torokhov, dianders, jikos, linux-kernel, superm1,
Pin-yen Lin, Xu Rao, Kwok Kin Ming, Dan Carpenter
In-Reply-To: <7ff8529d-6b20-4088-aa10-77b304da49b4@kernel.org>
On Jun 03 2026, Hans de Goede wrote:
> Hi Benjamin,
>
> On 3-Jun-26 11:43 AM, Benjamin Tissoires wrote:
> > On Jun 01 2026, 谢致邦 (XIE Zhibang) wrote:
> >> Move the _DSM call that gets the HID descriptor address from
> >> i2c-hid-acpi.c to a shared helper in i2c-hid-core.c so both
> >> i2c-hid-acpi.c and i2c-hid-of.c can use it.
> >>
> >> Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
> >> ---
> >> drivers/hid/i2c-hid/i2c-hid-acpi.c | 32 ++++-----------------------
> >> drivers/hid/i2c-hid/i2c-hid-core.c | 35 ++++++++++++++++++++++++++++++
> >
> > I'm not a big fan of removing 25% of the i2c-hid-acpi.c code and inject
> > it in i2c-hid-core.c.
>
> It is only 35 new lines in i2c-hid-core.c, so it is not that big / much code.
My concern is not so much about these 35 lines of code, but the fact
that i2c-hid-acpi.c is now down to only 3 functions:
- i2c_hid_acpi_probe()
- i2c_hid_acpi_shutdown_tail()
- i2c_hid_acpi_restore_sequence()
So then, what's the point of keeping it as a separate driver? (more
rethorical question than anything).
>
> > There's something I can't really understand in the problem:
> > - we are talking about non arm architecture, which should not have OF in
> > them
> > - the current compatible hid-over-i2c loads the OF version?
> > - how can you make the device working without the couple of ACPI
> > functions that are in the i2c-hid-acpi.c driver for powering up and
> > down the device?
> >
> > If the platform is indeed ACPI + x86(_64), then shouldn't we tackle the
> > problem in the i2c-hid-acpi driver, or add a secondary leaf driver for
> > this particular platform/device? Kind of what we have with
> > i2c-hid-of-elan.c
>
> As part of the work to use ACPI on ARM systems, it is possible now a days
> to inject DT snippets into ACPI tables.
>
> The problem on these Loongson laptops is that they have created this
> very ugly mixed-mode where they put a PRP0001 ACPI HID on the ACPI
> node for the touchscreen, which means it contains an embedded DT
> snippet and in that snipped out "compatible=hid-over-i2c" but NOT
> also "i2c-hid-descr-addr=x". To get the i2c-hid descriptor address
> the implemented the ACPI _DSM on the same ACPI device/fwnode.
>
> The ACPI core sees HID=PRP0001 so it creates an of-compatible
> modalias / match and not an ACPI one, so the i2c-hid-of driver will
> bind.
But if this fix is for just one platform, why not keeping the design
clean and have a dmi_match instead in a separate driver, like the
i2c-hid-of-elan does for Elan touchpads/touchscreens?
i2c-hid-acpi-loongson.c for instance.
>
> Note these "fixed" (as in we cannot fix them) ACPI tables use
> the generic i2c-over-hid OF/DT compatible _not_ something
> more specific so we can also not do a more specific driver like
> i2c-hid-of-elan.c.
Do they use anything else than the compatible DT entry? regulators and
others? If not, then the device is pure ACPI, and should not be handled
by i2c-hid-of.c at all, no?
> If we could fix the ACPI tables we would just
> change the ACPI HID to the standard PNPxxxx ACPI HID for i2c-hid
> devices.
>
> The first version of this patch-set added an of match table
> to i2c-hid-acpi making it also load and probe i2c-hid devices
> described in devicetree on devicetree only systems which IMHO
> is very messy.
Yeah, this one is slightly less messy than the previous versions. It is
just sad to mess up with a clean separation and make the i2c-hid-acpi
driver just a placeholder for a probe function.
>
> So this new series is the least ugly way to deal with this.
so far :)
Cheers,
Benjamin
^ 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