* [PATCH 6.12 139/265] HID: Add HID_CLAIMED_INPUT guards in raw_event callbacks missing them
From: Greg Kroah-Hartman @ 2026-03-12 20:08 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, Jiri Kosina, Benjamin Tissoires,
Bastien Nocera, linux-input, stable
In-Reply-To: <20260312201018.128816016@linuxfoundation.org>
6.12-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] dt-bindings: touchscreen: trivial-touch: Move allOf: after required:
From: Marek Vasut @ 2026-03-12 22:49 UTC (permalink / raw)
To: devicetree
Cc: Marek Vasut, Conor Dooley, Dmitry Torokhov, Frank Li, Job Noorman,
Krzysztof Kozlowski, Rob Herring, linux-input, linux-renesas-soc
Majority of schemas place allOf: after required: . Documentation
Documentation/devicetree/bindings/writing-schema.rst also hints at
this ordering. Trivially update this schema. No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
NOTE: This comes from https://lore.kernel.org/all/20260117-grinning-heavy-crab-11f245@quoll/
where krzk comments "allOf: should be placed after required: block."
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Job Noorman <job@noorman.info>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
.../bindings/input/touchscreen/trivial-touch.yaml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml b/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
index 6441d21223caf..6316a8d32f39b 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
@@ -53,14 +53,14 @@ properties:
wakeup-source: true
-allOf:
- - $ref: touchscreen.yaml
-
required:
- compatible
- reg
- interrupts
+allOf:
+ - $ref: touchscreen.yaml
+
unevaluatedProperties: false
examples:
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v6 16/19] HID: Add documentation for Lenovo Legion Go drivers
From: Derek John Clark @ 2026-03-12 22:57 UTC (permalink / raw)
To: Akira Yokosawa
Cc: bentiss, hughsient, jikos, linux-doc, linux-input, linux-kernel,
mario.limonciello, mpearson-lenovo, pgriffais, shaohz1, zhangzx36
In-Reply-To: <7dc9bd14-b21f-461a-9794-070f43db4826@gmail.com>
On Wed, Mar 11, 2026 at 7:44 PM Akira Yokosawa <akiyks@gmail.com> wrote:
>
> Hi,
>
> On Tue, 10 Mar 2026 07:29:34 +0000, Derek J. Clark wrote:
> > Adds ABI documentation for the hid-lenovo-go-s and hid-lenovo-go
> > drivers.
> >
> > Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
> > Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
> > ---
> > v3:
> > - Remove excess + from every line of patch.
> > ---
> > .../ABI/testing/sysfs-driver-hid-lenovo-go | 724 ++++++++++++++++++
> > .../ABI/testing/sysfs-driver-hid-lenovo-go-s | 304 ++++++++
> > MAINTAINERS | 2 +
> > 3 files changed, 1030 insertions(+)
> > create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-lenovo-go
> > create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s
>
> This (commit 168c91839139 in next-20260311) causes a lot of new warnings
> in "make htmldocs" such as:
>
> WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode is defined 2 times: /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:364; /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:234
> WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/os_mode_index is defined 2 times: /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:373; /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:243
> WARNING: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/touchpad/enabled is defined 2 times: /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go:636; /<...>/Documentation/ABI/testing/sysfs-driver-hid-lenovo-go-s:252
> [snip]
>
> Please fix.
>
> Thanks, Akira
Akira,
What would an appropriate solution look like? There are two separate
drivers in this series that are modeled to provide a sysfs that is as
close to each other as possible. Because of that, they do end up
having identical attributes for many of the implemented features. In
most cases they are prefixed in the sysfs by a different component
name, but that isn't the case for os_mode or touchpad/enabled. I could
combine documentation for both drivers and de-duplicate, but I'm not
sure what that would be called, sysfs-driver-hid-lenovo-go? Add them
all to hid-lenovo docs?
If I do that there are some additional de-duplication that could
reduce the total number of lines. I.E
What: /sys/class/leds/[go|go_s]:rgb:joystick_rings/effect
Would that syntax be alright? Some of them get a little excessive, for
example the auto sleep time is defined three times and would be
combined to something like this:
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config
num>.<interface
num>/<hid-bus>:<vendor-id>:<product-id>.<num>/[left_handle|right_handle|gamepad]/auto_sleep_time
Otherwise, is there some way to flag the same attribute defined in two
separate documents provided by two drivers as not being duplicates?
Thanks,
Derek
^ permalink raw reply
* Re: [PATCH 09/12] dt-bindings: input: Document hid-over-spi DT schema
From: Jingyuan Liang @ 2026-03-13 1:00 UTC (permalink / raw)
To: Val Packett
Cc: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, linux-doc, linux-kernel, linux-spi,
linux-trace-kernel, devicetree, hbarnor, Dmitry Antipov,
Jarrett Schultz
In-Reply-To: <1cc6de61-8b56-492e-ab78-e3aa448f58ad@packett.cool>
On Fri, Mar 6, 2026 at 11:25 PM Val Packett <val@packett.cool> wrote:
>
>
> On 3/3/26 3:13 AM, Jingyuan Liang wrote:
> > Documentation describes the required and optional properties for
> > implementing Device Tree for a Microsoft G6 Touch Digitizer that
> > supports HID over SPI Protocol 1.0 specification.
> > […]
> > +properties:
> > + compatible:
> > + oneOf:
> > + - items:
> > + - enum:
> > + - microsoft,g6-touch-digitizer
> > + - const: hid-over-spi
> > + - description: Just "hid-over-spi" alone is allowed, but not recommended.
> > […]
> > +required:
> > + - compatible
> > + - interrupts
> > + - reset-gpios
>
> Why is reset required? Is it so implausible on some device implementing
> the spec there wouldn't be a reset gpio?
>
> > + - vdd-supply
> Linux makes up a dummy regulator if DT doesn't provide one, so can
> regulators even be required?
> > […]
> > + compatible = "hid-over-spi";
> Not following your own recommendation from above :)
Thanks! I will fix this in v2.
> > + reg = <0x0>;
> > + interrupts-extended = <&gpio 42 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
> > + vdd-supply = <&pm8350c_l3>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ts_d6_reset_assert &ts_d6_int_bias>;
>
> Heh, "reset_assert" is a name implying it would actually set the value
> from the pinctrl properties, which is what had to be done before
> reset-gpios were supported. But now reset-gpios are supported.
Taken from the original patch. Will fix this in v2.
>
>
> Thanks,
> ~val
>
>
> P.S. happy to see work on this happen again!
>
^ permalink raw reply
* Re: [PATCH 09/12] dt-bindings: input: Document hid-over-spi DT schema
From: Jingyuan Liang @ 2026-03-13 1:14 UTC (permalink / raw)
To: Rob Herring
Cc: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley, linux-input,
linux-doc, LKML, linux-spi, linux-trace-kernel, devicetree,
Henry Barnor, Dmitry Antipov, Jarrett Schultz
In-Reply-To: <CAEe3GZE_79Lqtzv4ZRi6zWuV_DgkCREBDcZJjpR+X9OaGZCA2g@mail.gmail.com>
On Wed, Mar 11, 2026 at 5:58 PM Jingyuan Liang <jingyliang@chromium.org> wrote:
>
> (Resending to the list. Apologies, I accidentally dropped the CCs on
> my initial reply!)
>
> On Tue, Mar 3, 2026 at 5:53 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, Mar 3, 2026 at 12:14 AM Jingyuan Liang <jingyliang@chromium.org> wrote:
> > >
> > > Documentation describes the required and optional properties for
> > > implementing Device Tree for a Microsoft G6 Touch Digitizer that
> > > supports HID over SPI Protocol 1.0 specification.
> > >
> > > The properties are common to HID over SPI.
> > >
> > > Signed-off-by: Dmitry Antipov <dmanti@microsoft.com>
> > > Signed-off-by: Jarrett Schultz <jaschultz@microsoft.com>
> > > Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> > > ---
> > > .../devicetree/bindings/input/hid-over-spi.yaml | 153 +++++++++++++++++++++
> > > 1 file changed, 153 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/hid-over-spi.yaml b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > > new file mode 100644
> > > index 000000000000..b623629ed9d3
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/hid-over-spi.yaml
> > > @@ -0,0 +1,153 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/input/hid-over-spi.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: HID over SPI Devices
> > > +
> > > +maintainers:
> > > + - Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > + - Jiri Kosina <jkosina@suse.cz>
> > > +
> > > +description: |+
> > > + HID over SPI provides support for various Human Interface Devices over the
> > > + SPI bus. These devices can be for example touchpads, keyboards, touch screens
> > > + or sensors.
> > > +
> > > + The specification has been written by Microsoft and is currently available here:
> > > + https://www.microsoft.com/en-us/download/details.aspx?id=103325
> > > +
> > > + If this binding is used, the kernel module spi-hid will handle the communication
> > > + with the device and the generic hid core layer will handle the protocol.
> > > +
> > > +allOf:
> > > + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > + oneOf:
> > > + - items:
> > > + - enum:
> > > + - microsoft,g6-touch-digitizer
> > > + - const: hid-over-spi
> > > + - description: Just "hid-over-spi" alone is allowed, but not recommended.
> > > + const: hid-over-spi
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > + reset-gpios:
> > > + maxItems: 1
> > > + description:
> > > + GPIO specifier for the digitizer's reset pin (active low). The line must
> > > + be flagged with GPIO_ACTIVE_LOW.
> > > +
> > > + vdd-supply:
> > > + description:
> > > + Regulator for the VDD supply voltage.
> >
> > Is this part of the spec? This won't scale for multiple devices with
> > different power rails.
>
> This is not part of the spec but is needed for power management. Is it okay I
> mark it as optional? Thank you.
>
> >
> > > +
> > > + input-report-header-address:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + minimum: 0
> > > + maximum: 0xffffff
> > > + description:
> > > + A value to be included in the Read Approval packet, listing an address of
> > > + the input report header to be put on the SPI bus. This address has 24
> > > + bits.
> > > +
> > > + input-report-body-address:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + minimum: 0
> > > + maximum: 0xffffff
> > > + description:
> > > + A value to be included in the Read Approval packet, listing an address of
> > > + the input report body to be put on the SPI bus. This address has 24 bits.
> > > +
> > > + output-report-address:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + minimum: 0
> > > + maximum: 0xffffff
> > > + description:
> > > + A value to be included in the Output Report sent by the host, listing an
> > > + address where the output report on the SPI bus is to be written to. This
> > > + address has 24 bits.
> > > +
> > > + post-power-on-delay-ms:
> > > + description:
> > > + Optional time in ms required by the device after enabling its regulators
> > > + or powering it on, before it is ready for communication.
> >
> > Drop. This should be implied by the compatible.
>
> Thank you, I will fix this in v2.
>
> >
> > > +
> > > + minimal-reset-delay-ms:
> > > + description:
> > > + Optional minimum amount of time in ms that device needs to be in reset
> > > + state for the reset to take effect.
> >
> > Drop. This should be implied by the compatible.
>
> I will fix this in v2.
>
> >
> > > +
> > > + read-opcode:
> > > + $ref: /schemas/types.yaml#/definitions/uint8
> > > + description:
> > > + Value to be used in Read Approval packets. 1 byte.
> > > +
> > > + write-opcode:
> > > + $ref: /schemas/types.yaml#/definitions/uint8
> > > + description:
> > > + Value to be used in Write Approval packets. 1 byte.
> >
> > Why are these and the address properties above not defined by the
> > spec? Do they vary for a specific device? If not, then they should be
> > implied by the compatible.
>
> These properties are not defined by the spec:
>
> "The Input Report Address (header or body) and READ opcode are retrieved
> from ACPI."
>
> Same for the output report address and write opcode. I will drop these in v2.
Hi Rob,
Please disregard my previous reply about dropping the read/write opcodes and
input/output addresses. The spec does not define these fields. Instead, it says
these values are retrieved from ACPI _DSM methods. If we remove them from
the binding, the driver is not very generic. Would it be okay to keep them?
>
> >
> > > +
> > > + hid-over-spi-flags:
> > > + $ref: /schemas/types.yaml#/definitions/uint16
> > > + description:
> > > + 16 bits.
> > > + Bits 0-12 - Reserved (must be 0)
> > > + Bit 13 - SPI Write Mode. Possible values -
> > > + * 0b0- Writes are carried out in Single-SPI mode
> > > + * 0b1- Writes are carried out in the Multi-SPI mode specified by bits
> > > + 14-15
> > > + Bits 14-15 - Multi-SPI Mode. Possible values -
> > > + * 0b00- Single SPI
> > > + * 0b01- Dual SPI
> > > + * 0b10- Quad SPI
> >
> > We already have SPI properties to define the bus width for read and write.
>
> Will fix this in v2.
>
> >
> > > +
> > > +required:
> > > + - compatible
> > > + - interrupts
> > > + - reset-gpios
> > > + - vdd-supply
> > > + - input-report-header-address
> > > + - input-report-body-address
> > > + - output-report-address
> > > + - read-opcode
> > > + - write-opcode
> > > + - hid-over-spi-flags
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + #include <dt-bindings/interrupt-controller/irq.h>
> > > + #include <dt-bindings/gpio/gpio.h>
> > > +
> > > + spi {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + hid@0 {
> > > + compatible = "hid-over-spi";
> > > + reg = <0x0>;
> > > + interrupts-extended = <&gpio 42 IRQ_TYPE_EDGE_FALLING>;
> > > + reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
> > > + vdd-supply = <&pm8350c_l3>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&ts_d6_reset_assert &ts_d6_int_bias>;
> > > + input-report-header-address = <0x1000>;
> > > + input-report-body-address = <0x1004>;
> > > + output-report-address = <0x2000>;
> > > + read-opcode = <0x0b>;
> > > + write-opcode = <0x02>;
> > > + hid-over-spi-flags = <0x0000>;
> > > + post-power-on-delay-ms = <5>;
> > > + minimal-reset-delay-ms = <5>;
> > > + };
> > > + };
> > > \ No newline at end of file
> >
> > Fix this.
>
> Will fix this in v2.
>
> >
> > Rob
^ permalink raw reply
* Re: [PATCH 07/12] HID: spi_hid: add ACPI support for SPI over HID
From: Jingyuan Liang @ 2026-03-13 1:24 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Benjamin Tissoires, Jonathan Corbet, Mark Brown,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-input, linux-doc,
linux-kernel, linux-spi, linux-trace-kernel, devicetree, hbarnor,
Angela Czubak
In-Reply-To: <abD6RJZa5D7LN3x0@google.com>
On Tue, Mar 10, 2026 at 10:27 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> On Tue, Mar 03, 2026 at 06:12:59AM +0000, Jingyuan Liang wrote:
> > From: Angela Czubak <acz@semihalf.com>
> >
> > Detect SPI HID devices described in ACPI.
> >
> > Signed-off-by: Angela Czubak <acz@semihalf.com>
> > Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
> > ---
> > drivers/hid/spi-hid/Kconfig | 15 +++
> > drivers/hid/spi-hid/Makefile | 1 +
> > drivers/hid/spi-hid/spi-hid-acpi.c | 253 +++++++++++++++++++++++++++++++++++++
> > drivers/hid/spi-hid/spi-hid-core.c | 27 +---
> > drivers/hid/spi-hid/spi-hid.h | 44 +++++++
> > 5 files changed, 316 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/hid/spi-hid/Kconfig b/drivers/hid/spi-hid/Kconfig
> > index 836fdefe8345..114b1e00da39 100644
> > --- a/drivers/hid/spi-hid/Kconfig
> > +++ b/drivers/hid/spi-hid/Kconfig
> > @@ -10,6 +10,21 @@ menuconfig SPI_HID
> >
> > if SPI_HID
> >
> > +config SPI_HID_ACPI
> > + tristate "HID over SPI transport layer ACPI driver"
> > + depends on ACPI
> > + select SPI_HID_CORE
> > + help
> > + Say Y here if you use a keyboard, a touchpad, a touchscreen, or any
> > + other HID based devices which are connected to your computer via SPI.
> > + This driver supports ACPI-based systems.
> > +
> > + If unsure, say N.
> > +
> > + This support is also available as a module. If so, the module
> > + will be called spi-hid-acpi. It will also build/depend on the
> > + module spi-hid.
> > +
> > config SPI_HID_CORE
> > tristate
> > endif
> > diff --git a/drivers/hid/spi-hid/Makefile b/drivers/hid/spi-hid/Makefile
> > index 92e24cddbfc2..753c7b7a7844 100644
> > --- a/drivers/hid/spi-hid/Makefile
> > +++ b/drivers/hid/spi-hid/Makefile
> > @@ -7,3 +7,4 @@
> >
> > obj-$(CONFIG_SPI_HID_CORE) += spi-hid.o
> > spi-hid-objs = spi-hid-core.o
> > +obj-$(CONFIG_SPI_HID_ACPI) += spi-hid-acpi.o
> > diff --git a/drivers/hid/spi-hid/spi-hid-acpi.c b/drivers/hid/spi-hid/spi-hid-acpi.c
> > new file mode 100644
> > index 000000000000..612e74fe72f9
> > --- /dev/null
> > +++ b/drivers/hid/spi-hid/spi-hid-acpi.c
> > @@ -0,0 +1,253 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * HID over SPI protocol, ACPI related code
> > + *
> > + * Copyright (c) 2021 Microsoft Corporation
> > + * Copyright (c) 2026 Google LLC
> > + *
> > + * This code was forked out of the HID over SPI core code, which is partially
> > + * based on "HID over I2C protocol implementation:
> > + *
> > + * Copyright (c) 2012 Benjamin Tissoires <benjamin.tissoires@gmail.com>
> > + * Copyright (c) 2012 Ecole Nationale de l'Aviation Civile, France
> > + * Copyright (c) 2012 Red Hat, Inc
> > + *
> > + * which in turn is partially based on "USB HID support for Linux":
> > + *
> > + * Copyright (c) 1999 Andreas Gal
> > + * Copyright (c) 2000-2005 Vojtech Pavlik <vojtech@suse.cz>
> > + * Copyright (c) 2005 Michael Haboustak <mike-@cinci.rr.com> for Concept2, Inc
> > + * Copyright (c) 2007-2008 Oliver Neukum
> > + * Copyright (c) 2006-2010 Jiri Kosina
> > + */
> > +
> > +#include <linux/acpi.h>
> > +#include <linux/delay.h>
> > +#include <linux/device.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/reset.h>
> > +#include <linux/uuid.h>
> > +
> > +#include "spi-hid.h"
> > +
> > +/* Config structure is filled with data from ACPI */
> > +struct spi_hid_acpi_config {
> > + struct spihid_ops ops;
> > +
> > + struct spi_hid_conf property_conf;
> > + u32 post_power_on_delay_ms;
> > + u32 minimal_reset_delay_ms;
> > + struct acpi_device *adev;
> > +};
> > +
> > +/* HID SPI Device: 6e2ac436-0fcf41af-a265-b32a220dcfab */
> > +static guid_t spi_hid_guid =
> > + GUID_INIT(0x6E2AC436, 0x0FCF, 0x41AF,
> > + 0xA2, 0x65, 0xB3, 0x2A, 0x22, 0x0D, 0xCF, 0xAB);
> > +
> > +static int spi_hid_acpi_populate_config(struct spi_hid_acpi_config *conf,
> > + struct acpi_device *adev)
> > +{
> > + acpi_handle handle = acpi_device_handle(adev);
> > + union acpi_object *obj;
> > +
> > + conf->adev = adev;
> > +
> > + /* Revision 3 for HID over SPI V1, see specification. */
> > + obj = acpi_evaluate_dsm_typed(handle, &spi_hid_guid, 3, 1, NULL,
> > + ACPI_TYPE_INTEGER);
> > + if (!obj) {
> > + acpi_handle_err(handle,
> > + "Error _DSM call to get HID input report header address failed");
> > + return -ENODEV;
> > + }
> > + conf->property_conf.input_report_header_address = obj->integer.value;
> > + ACPI_FREE(obj);
> > +
> > + obj = acpi_evaluate_dsm_typed(handle, &spi_hid_guid, 3, 2, NULL,
> > + ACPI_TYPE_INTEGER);
> > + if (!obj) {
> > + acpi_handle_err(handle,
> > + "Error _DSM call to get HID input report body address failed");
> > + return -ENODEV;
> > + }
> > + conf->property_conf.input_report_body_address = obj->integer.value;
> > + ACPI_FREE(obj);
> > +
> > + obj = acpi_evaluate_dsm_typed(handle, &spi_hid_guid, 3, 3, NULL,
> > + ACPI_TYPE_INTEGER);
> > + if (!obj) {
> > + acpi_handle_err(handle,
> > + "Error _DSM call to get HID output report header address failed");
> > + return -ENODEV;
> > + }
> > + conf->property_conf.output_report_address = obj->integer.value;
> > + ACPI_FREE(obj);
> > +
> > + obj = acpi_evaluate_dsm_typed(handle, &spi_hid_guid, 3, 4, NULL,
> > + ACPI_TYPE_BUFFER);
> > + if (!obj) {
> > + acpi_handle_err(handle,
> > + "Error _DSM call to get HID read opcode failed");
> > + return -ENODEV;
> > + }
> > + if (obj->buffer.length == 1) {
> > + conf->property_conf.read_opcode = obj->buffer.pointer[0];
> > + } else {
> > + acpi_handle_err(handle,
> > + "Error _DSM call to get HID read opcode, too long buffer");
> > + ACPI_FREE(obj);
> > + return -ENODEV;
> > + }
> > + ACPI_FREE(obj);
> > +
> > + obj = acpi_evaluate_dsm_typed(handle, &spi_hid_guid, 3, 5, NULL,
> > + ACPI_TYPE_BUFFER);
> > + if (!obj) {
> > + acpi_handle_err(handle,
> > + "Error _DSM call to get HID write opcode failed");
> > + return -ENODEV;
> > + }
> > + if (obj->buffer.length == 1) {
> > + conf->property_conf.write_opcode = obj->buffer.pointer[0];
> > + } else {
> > + acpi_handle_err(handle,
> > + "Error _DSM call to get HID write opcode, too long buffer");
> > + ACPI_FREE(obj);
> > + return -ENODEV;
> > + }
> > + ACPI_FREE(obj);
> > +
> > + /* Value not provided in ACPI,*/
> > + conf->post_power_on_delay_ms = 5;
> > + conf->minimal_reset_delay_ms = 150;
> > +
> > + if (!acpi_has_method(handle, "_RST")) {
> > + acpi_handle_err(handle, "No reset method for acpi handle");
> > + return -ENODEV;
>
> I would return -EINVAL as we have the device with right _DSM but without
> mandated by the spec _RST.
Thanks! Will fix this in v2.
>
> > + }
> > +
> > + /* FIXME: not reading hid-over-spi-flags, multi-SPI not supported */
> > +
> > + return 0;
> > +}
> > +
> > +static int spi_hid_acpi_power_none(struct spihid_ops *ops)
> > +{
> > + return 0;
> > +}
> > +
> > +static int spi_hid_acpi_power_down(struct spihid_ops *ops)
> > +{
> > + struct spi_hid_acpi_config *conf = container_of(ops,
> > + struct spi_hid_acpi_config,
> > + ops);
> > +
> > + return acpi_device_set_power(conf->adev, ACPI_STATE_D3);
> > +}
> > +
> > +static int spi_hid_acpi_power_up(struct spihid_ops *ops)
> > +{
> > + struct spi_hid_acpi_config *conf = container_of(ops,
> > + struct spi_hid_acpi_config,
> > + ops);
> > + int error;
> > +
> > + error = acpi_device_set_power(conf->adev, ACPI_STATE_D0);
> > + if (error) {
> > + dev_err(&conf->adev->dev, "Error could not power up ACPI device: %d.", error);
> > + return error;
> > + }
> > +
> > + if (conf->post_power_on_delay_ms)
> > + msleep(conf->post_power_on_delay_ms);
> > +
> > + return 0;
> > +}
> > +
> > +static int spi_hid_acpi_assert_reset(struct spihid_ops *ops)
> > +{
> > + return 0;
> > +}
> > +
> > +static int spi_hid_acpi_deassert_reset(struct spihid_ops *ops)
> > +{
> > + struct spi_hid_acpi_config *conf = container_of(ops,
> > + struct spi_hid_acpi_config,
> > + ops);
> > +
> > + return device_reset(&conf->adev->dev);
> > +}
> > +
> > +static void spi_hid_acpi_sleep_minimal_reset_delay(struct spihid_ops *ops)
> > +{
> > + struct spi_hid_acpi_config *conf = container_of(ops,
> > + struct spi_hid_acpi_config,
> > + ops);
> > + usleep_range(1000 * conf->minimal_reset_delay_ms,
> > + 1000 * (conf->minimal_reset_delay_ms + 1));
>
> I'd probably use "fsleep(conf->minimal_reset_delay_ms * 1000)".
I will fix this in v2. And do the same for the of driver.
>
> > +}
> > +
> > +static int spi_hid_acpi_probe(struct spi_device *spi)
> > +{
> > + struct device *dev = &spi->dev;
> > + struct acpi_device *adev;
> > + struct spi_hid_acpi_config *config;
> > + int error;
> > +
> > + adev = ACPI_COMPANION(dev);
> > + if (!adev) {
> > + dev_err(dev, "Error could not get ACPI device.");
> > + return -ENODEV;
> > + }
> > +
> > + config = devm_kzalloc(dev, sizeof(struct spi_hid_acpi_config),
> > + GFP_KERNEL);
> > + if (!config)
> > + return -ENOMEM;
> > +
> > + if (acpi_device_power_manageable(adev)) {
> > + config->ops.power_up = spi_hid_acpi_power_up;
> > + config->ops.power_down = spi_hid_acpi_power_down;
> > + } else {
> > + config->ops.power_up = spi_hid_acpi_power_none;
> > + config->ops.power_down = spi_hid_acpi_power_none;
> > + }
> > + config->ops.assert_reset = spi_hid_acpi_assert_reset;
> > + config->ops.deassert_reset = spi_hid_acpi_deassert_reset;
> > + config->ops.sleep_minimal_reset_delay =
> > + spi_hid_acpi_sleep_minimal_reset_delay;
> > +
> > + error = spi_hid_acpi_populate_config(config, adev);
> > + if (error) {
> > + dev_err(dev, "%s: unable to populate config data.", __func__);
> > + return error;
> > + }
>
> I would add a blank line.
Sure! Will fix this in v2.
>
> > + return spi_hid_core_probe(spi, &config->ops, &config->property_conf);
> > +}
> > +
> > +static const struct acpi_device_id spi_hid_acpi_match[] = {
> > + { "ACPI0C51", 0 },
> > + { "PNP0C51", 0 },
> > + { },
>
> No comma on sentinels.
Will fix this in v2.
>
> > +};
> > +MODULE_DEVICE_TABLE(acpi, spi_hid_acpi_match);
> > +
> > +static struct spi_driver spi_hid_acpi_driver = {
> > + .driver = {
> > + .name = "spi_hid_acpi",
> > + .owner = THIS_MODULE,
> > + .acpi_match_table = ACPI_PTR(spi_hid_acpi_match),
>
> This is dependent on ACPI, so no need to sue ACPI_PTR().
Will fix this in v2 and remove of_match_ptr in the of driver as well.
>
> > + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> > + .dev_groups = spi_hid_groups,
> > + },
> > + .probe = spi_hid_acpi_probe,
> > + .remove = spi_hid_core_remove,
> > +};
> > +
> > +module_spi_driver(spi_hid_acpi_driver);
> > +
> > +MODULE_DESCRIPTION("HID over SPI ACPI transport driver");
> > +MODULE_AUTHOR("Angela Czubak <aczubak@google.com>");
> > +MODULE_LICENSE("GPL");
> > diff --git a/drivers/hid/spi-hid/spi-hid-core.c b/drivers/hid/spi-hid/spi-hid-core.c
> > index e3273846267e..02beb209a92d 100644
> > --- a/drivers/hid/spi-hid/spi-hid-core.c
> > +++ b/drivers/hid/spi-hid/spi-hid-core.c
> > @@ -43,6 +43,9 @@
> > #include <linux/wait.h>
> > #include <linux/workqueue.h>
> >
> > +#include "spi-hid.h"
> > +#include "spi-hid-core.h"
> > +
> > /* Protocol constants */
> > #define SPI_HID_READ_APPROVAL_CONSTANT 0xff
> > #define SPI_HID_INPUT_HEADER_SYNC_BYTE 0x5a
> > @@ -105,30 +108,6 @@ struct spi_hid_output_report {
> > u8 *content;
> > };
> >
> > -/* struct spi_hid_conf - Conf provided to the core */
> > -struct spi_hid_conf {
> > - u32 input_report_header_address;
> > - u32 input_report_body_address;
> > - u32 output_report_address;
> > - u8 read_opcode;
> > - u8 write_opcode;
> > -};
> > -
> > -/**
> > - * struct spihid_ops - Ops provided to the core
> > - * @power_up: do sequencing to power up the device
> > - * @power_down: do sequencing to power down the device
> > - * @assert_reset: do sequencing to assert the reset line
> > - * @deassert_reset: do sequencing to deassert the reset line
> > - */
> > -struct spihid_ops {
> > - int (*power_up)(struct spihid_ops *ops);
> > - int (*power_down)(struct spihid_ops *ops);
> > - int (*assert_reset)(struct spihid_ops *ops);
> > - int (*deassert_reset)(struct spihid_ops *ops);
> > - void (*sleep_minimal_reset_delay)(struct spihid_ops *ops);
> > -};
> > -
> > static struct hid_ll_driver spi_hid_ll_driver;
> >
> > static void spi_hid_populate_read_approvals(const struct spi_hid_conf *conf,
> > diff --git a/drivers/hid/spi-hid/spi-hid.h b/drivers/hid/spi-hid/spi-hid.h
> > new file mode 100644
> > index 000000000000..1fdd45262647
> > --- /dev/null
> > +++ b/drivers/hid/spi-hid/spi-hid.h
> > @@ -0,0 +1,44 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * Copyright (c) 2021 Microsoft Corporation
> > + * Copyright (c) 2026 Google LLC
> > + */
> > +
> > +#ifndef SPI_HID_H
> > +#define SPI_HID_H
> > +
> > +#include <linux/spi/spi.h>
> > +#include <linux/sysfs.h>
> > +
> > +/* struct spi_hid_conf - Conf provided to the core */
> > +struct spi_hid_conf {
> > + u32 input_report_header_address;
> > + u32 input_report_body_address;
> > + u32 output_report_address;
> > + u8 read_opcode;
> > + u8 write_opcode;
> > +};
> > +
> > +/**
> > + * struct spihid_ops - Ops provided to the core
> > + * @power_up: do sequencing to power up the device
> > + * @power_down: do sequencing to power down the device
> > + * @assert_reset: do sequencing to assert the reset line
> > + * @deassert_reset: do sequencing to deassert the reset line
> > + */
> > +struct spihid_ops {
> > + int (*power_up)(struct spihid_ops *ops);
> > + int (*power_down)(struct spihid_ops *ops);
> > + int (*assert_reset)(struct spihid_ops *ops);
> > + int (*deassert_reset)(struct spihid_ops *ops);
> > + void (*sleep_minimal_reset_delay)(struct spihid_ops *ops);
> > +};
> > +
> > +int spi_hid_core_probe(struct spi_device *spi, struct spihid_ops *ops,
> > + struct spi_hid_conf *conf);
> > +
> > +void spi_hid_core_remove(struct spi_device *spi);
> > +
> > +extern const struct attribute_group *spi_hid_groups[];
> > +
> > +#endif /* SPI_HID_H */
>
> I am not sure if this belongs to this patch or if it should be better in
> the patch introducing the main driver from the beginning.
These definitions were in spi-hid-core.c in the previous patch introducing
the main driver because it was only used in one .c file. This patch introduces
spi-hid-acpi.c and now two .c files need it so I created a separate .h
file here.
>
> For the ACPI part:
>
> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* [PATCH 0/2] Input: ft5x06: Add support for FocalTech FT3519
From: Bhushan Shah @ 2026-03-13 6:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-input, devicetree, linux-kernel, Bhushan Shah
This touchscreen supports upto 10 touch points, add devicetree bindings
and compatible in driver for it.
Signed-off-by: Bhushan Shah <bhushan.shah@machinesoul.in>
---
Bhushan Shah (2):
dt-bindings: input: touchscreen: edt-ft5x06: Add FocalTech FT3519
Input: edt-ft5x06 - add support for FocalTech FT3519
Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 1 +
drivers/input/touchscreen/edt-ft5x06.c | 6 ++++++
2 files changed, 7 insertions(+)
---
base-commit: 0257f64bdac7fdca30fa3cae0df8b9ecbec7733a
change-id: 20260313-edt-ft3519-b3e2a33e88ee
Best regards,
--
Bhushan Shah <bhushan.shah@machinesoul.in>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: input: touchscreen: edt-ft5x06: Add FocalTech FT3519
From: Bhushan Shah @ 2026-03-13 6:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-input, devicetree, linux-kernel, Bhushan Shah
In-Reply-To: <20260313-edt-ft3519-v1-0-fe5ffc632fd2@machinesoul.in>
Document FocalTech FT3519 support by adding the compatible. It's 10
point touchscreen, which works with same driver.
Signed-off-by: Bhushan Shah <bhushan.shah@machinesoul.in>
---
Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
index 6f90522de8c0..34161af90156 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml
@@ -40,6 +40,7 @@ properties:
- edt,edt-ft5506
- evervision,ev-ft5726
- focaltech,ft3518
+ - focaltech,ft3519
- focaltech,ft5426
- focaltech,ft5452
- focaltech,ft6236
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] Input: edt-ft5x06 - add support for FocalTech FT3519
From: Bhushan Shah @ 2026-03-13 6:39 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-input, devicetree, linux-kernel, Bhushan Shah
In-Reply-To: <20260313-edt-ft3519-v1-0-fe5ffc632fd2@machinesoul.in>
This driver is compatible with the FocalTech FT3519 touchscreen, which
supports up to 10 concurrent touch points. Add a compatible for it.
Signed-off-by: Bhushan Shah <bhushan.shah@machinesoul.in>
---
drivers/input/touchscreen/edt-ft5x06.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index d0ab644be006..52188e1aa9bc 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1479,6 +1479,10 @@ static const struct edt_i2c_chip_data edt_ft3518_data = {
.max_support_points = 10,
};
+static const struct edt_i2c_chip_data edt_ft3519_data = {
+ .max_support_points = 10,
+};
+
static const struct edt_i2c_chip_data edt_ft5452_data = {
.max_support_points = 5,
};
@@ -1508,6 +1512,7 @@ static const struct i2c_device_id edt_ft5x06_ts_id[] = {
{ .name = "edt-ft5506", .driver_data = (long)&edt_ft5506_data },
{ .name = "ev-ft5726", .driver_data = (long)&edt_ft5506_data },
{ .name = "ft3518", .driver_data = (long)&edt_ft3518_data },
+ { .name = "ft3519", .driver_data = (long)&edt_ft3519_data },
{ .name = "ft5452", .driver_data = (long)&edt_ft5452_data },
/* Note no edt- prefix for compatibility with the ft6236.c driver */
{ .name = "ft6236", .driver_data = (long)&edt_ft6236_data },
@@ -1525,6 +1530,7 @@ static const struct of_device_id edt_ft5x06_of_match[] = {
{ .compatible = "edt,edt-ft5506", .data = &edt_ft5506_data },
{ .compatible = "evervision,ev-ft5726", .data = &edt_ft5506_data },
{ .compatible = "focaltech,ft3518", .data = &edt_ft3518_data },
+ { .compatible = "focaltech,ft3519", .data = &edt_ft3519_data },
{ .compatible = "focaltech,ft5426", .data = &edt_ft5506_data },
{ .compatible = "focaltech,ft5452", .data = &edt_ft5452_data },
/* Note focaltech vendor prefix for compatibility with ft6236.c */
--
2.53.0
^ permalink raw reply related
* [PATCH 0/4] HID: bpf fixes for 7.0/7.1
From: Benjamin Tissoires @ 2026-03-13 7:40 UTC (permalink / raw)
To: Jiri Kosina, Shuah Khan
Cc: linux-input, linux-kselftest, linux-kernel, Benjamin Tissoires,
kernel test robot, stable
Hi,
This is a series that targets a few HID-BPF issues I discovered or I've
been reported:
- first 2 patches should go to for-7.0/upstream-fixes:
- 1/4 fixes a compilation issue when HID is not enabled
- 2/4 is a nasty bug which allows a HID-BPF to crash the running
kernel, so not critical (you need special permissions to load the
HID-BPF program), but not great as you don't expect tinkering with
HID-BPF would crash
- last 2 patches are more 7.1 material: basically the LEDs on the
keyboards are bypassing HID-BPF, and then that made me realize that
the fallback calls in case of an unnumbered report is not correct (and
likely unnoticed because I don't think I've seen unnumbered reports on
anything else than USB devices)
Cheers,
Benjamin
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
---
Benjamin Tissoires (4):
selftests/hid: fix compilation when bpf_wq and hid_device are not exported
HID: bpf: prevent buffer overflow in hid_hw_request
HID: fix LEDs when report is unnumbered
HID: do not bypass HID-BPF when setting LEDs
drivers/hid/bpf/hid_bpf_dispatch.c | 2 ++
drivers/hid/hid-input.c | 16 +++++++++-------
tools/testing/selftests/hid/progs/hid_bpf_helpers.h | 12 ++++++++++++
3 files changed, 23 insertions(+), 7 deletions(-)
---
base-commit: 48976c0eba2ff3a3b893c35853bdf27369b16655
change-id: 20260313-wip-bpf-fixes-2fe794000870
Best regards,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* [PATCH 1/4] selftests/hid: fix compilation when bpf_wq and hid_device are not exported
From: Benjamin Tissoires @ 2026-03-13 7:40 UTC (permalink / raw)
To: Jiri Kosina, Shuah Khan
Cc: linux-input, linux-kselftest, linux-kernel, Benjamin Tissoires,
kernel test robot, stable
In-Reply-To: <20260313-wip-bpf-fixes-v1-0-74b860315060@kernel.org>
This can happen in situations when CONFIG_HID_SUPPORT is set to no, or
some complex situations where struct bpf_wq is not exported.
So do the usual dance of hiding them before including vmlinux.h, and
then redefining them and make use of CO-RE to have the correct offsets.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603111558.KLCIxsZB-lkp@intel.com/
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
---
tools/testing/selftests/hid/progs/hid_bpf_helpers.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
index 80ab60905865..2c6ec907dd05 100644
--- a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
+++ b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
@@ -8,9 +8,11 @@
/* "undefine" structs and enums in vmlinux.h, because we "override" them below */
#define hid_bpf_ctx hid_bpf_ctx___not_used
#define hid_bpf_ops hid_bpf_ops___not_used
+#define hid_device hid_device___not_used
#define hid_report_type hid_report_type___not_used
#define hid_class_request hid_class_request___not_used
#define hid_bpf_attach_flags hid_bpf_attach_flags___not_used
+#define bpf_wq bpf_wq___not_used
#define HID_INPUT_REPORT HID_INPUT_REPORT___not_used
#define HID_OUTPUT_REPORT HID_OUTPUT_REPORT___not_used
#define HID_FEATURE_REPORT HID_FEATURE_REPORT___not_used
@@ -29,9 +31,11 @@
#undef hid_bpf_ctx
#undef hid_bpf_ops
+#undef hid_device
#undef hid_report_type
#undef hid_class_request
#undef hid_bpf_attach_flags
+#undef bpf_wq
#undef HID_INPUT_REPORT
#undef HID_OUTPUT_REPORT
#undef HID_FEATURE_REPORT
@@ -55,6 +59,14 @@ enum hid_report_type {
HID_REPORT_TYPES,
};
+struct hid_device {
+ unsigned int id;
+} __attribute__((preserve_access_index));
+
+struct bpf_wq {
+ __u64 __opaque[2];
+};
+
struct hid_bpf_ctx {
struct hid_device *hid;
__u32 allocated_size;
--
2.52.0
^ permalink raw reply related
* [PATCH 2/4] HID: bpf: prevent buffer overflow in hid_hw_request
From: Benjamin Tissoires @ 2026-03-13 7:40 UTC (permalink / raw)
To: Jiri Kosina, Shuah Khan
Cc: linux-input, linux-kselftest, linux-kernel, Benjamin Tissoires,
stable
In-Reply-To: <20260313-wip-bpf-fixes-v1-0-74b860315060@kernel.org>
right now the returned value is considered to be always valid. However,
when playing with HID-BPF, the return value can be arbitrary big,
because it's the return value of dispatch_hid_bpf_raw_requests(), which
calls the struct_ops and we have no guarantees that the value makes
sense.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
---
drivers/hid/bpf/hid_bpf_dispatch.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/bpf/hid_bpf_dispatch.c b/drivers/hid/bpf/hid_bpf_dispatch.c
index f3d15994ca1e..50c7b45c59e3 100644
--- a/drivers/hid/bpf/hid_bpf_dispatch.c
+++ b/drivers/hid/bpf/hid_bpf_dispatch.c
@@ -444,6 +444,8 @@ hid_bpf_hw_request(struct hid_bpf_ctx *ctx, __u8 *buf, size_t buf__sz,
(u64)(long)ctx,
true); /* prevent infinite recursions */
+ if (ret > size)
+ ret = size;
if (ret > 0)
memcpy(buf, dma_data, ret);
--
2.52.0
^ permalink raw reply related
* [PATCH 3/4] HID: fix LEDs when report is unnumbered
From: Benjamin Tissoires @ 2026-03-13 7:40 UTC (permalink / raw)
To: Jiri Kosina, Shuah Khan
Cc: linux-input, linux-kselftest, linux-kernel, Benjamin Tissoires
In-Reply-To: <20260313-wip-bpf-fixes-v1-0-74b860315060@kernel.org>
Both usbhid and i2c-hid are expecting the first byte of the incoming
data to be the report ID. It should be set to 0 when the report ID is
not used. Currently, we are not enforcing this, which means that if we
enforce HID-BPF for LEDs, we will not be able to send them.
Note that the allocated buffer takes into account that extra byte, so
this is safe to shift the data buffer by one.
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
---
drivers/hid/hid-input.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index d5308adb2894..eb84f63c51b8 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1830,9 +1830,9 @@ static void hidinput_led_worker(struct work_struct *work)
led_work);
struct hid_field *field;
struct hid_report *report;
+ __u8 *buf, *data;
int ret;
u32 len;
- __u8 *buf;
field = hidinput_get_led_field(hid);
if (!field)
@@ -1863,7 +1863,14 @@ static void hidinput_led_worker(struct work_struct *work)
if (!buf)
return;
- hid_output_report(report, buf);
+ data = buf;
+ if (!report->id) {
+ data = &buf[1];
+ len++;
+ }
+
+ hid_output_report(report, data);
+
/* synchronous output report */
ret = hid_hw_output_report(hid, buf, len);
if (ret == -ENOSYS)
--
2.52.0
^ permalink raw reply related
* [PATCH 4/4] HID: do not bypass HID-BPF when setting LEDs
From: Benjamin Tissoires @ 2026-03-13 7:40 UTC (permalink / raw)
To: Jiri Kosina, Shuah Khan
Cc: linux-input, linux-kselftest, linux-kernel, Benjamin Tissoires
In-Reply-To: <20260313-wip-bpf-fixes-v1-0-74b860315060@kernel.org>
Right now LED workers are using the special .request() which is
asynchronous but bypasses entirely HID-BPF. This means we can not tweak
a HID keyboard.
Drop the asynchronous (only used by usbhid), and rely on the common
implementation.
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
---
drivers/hid/hid-input.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index eb84f63c51b8..f0a77a4b2a42 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1853,11 +1853,6 @@ static void hidinput_led_worker(struct work_struct *work)
report = field->report;
- /* use custom SET_REPORT request if possible (asynchronous) */
- if (hid->ll_driver->request)
- return hid->ll_driver->request(hid, report, HID_REQ_SET_REPORT);
-
- /* fall back to generic raw-output-report */
len = hid_report_len(report);
buf = hid_alloc_report_buf(report, GFP_KERNEL);
if (!buf)
--
2.52.0
^ permalink raw reply related
* Re: [tip:timers/vdso 37/45] progs/hid_bpf_helpers.h:117:31: error: declaration of 'struct bpf_wq' will not be visible outside of this function
From: Thomas Weißschuh @ 2026-03-13 8:20 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, linux-input, kernel test robot, oe-kbuild-all,
linux-kernel, x86, Thomas Gleixner
In-Reply-To: <abL184dNU_lO2JsP@beelink>
On Thu, Mar 12, 2026 at 06:34:15PM +0100, Benjamin Tissoires wrote:
> On Mar 12 2026, Thomas Weißschuh wrote:
> > On Wed, Mar 11, 2026 at 06:05:25PM +0100, Benjamin Tissoires wrote:
> > > On Mar 11 2026, Thomas Wei�schuh wrote:
> > > > could you take a look at the report below?
> > > > This looks like an issue in the HID BPF subsystem, surfaced by my
> > > > unrelated change. Does this ring a bell for you?
> > > >
> > > > I wasn't able to reproduce it so far, but will continue looking into it.
> > >
> > > Both struct bpf_wq and struct hid_device should be generated in the
> > > vmlinux.h that we include in the selftests. So this is definitely not
> > > related to your patch AFAICT.
> >
> > Ack. To be sure I sent this branch again through 0day and will see if it
> > breaks on the same commit.
> >
> > > Looking in the config, we have `# CONFIG_HID_SUPPORT is not set` -> so
> > > that would explain why struct hid_device is not available. But in that
> > > case, why are the HID selftests even built?
> >
> > CONFIG_DEBUG_INFO_BTF is also not set. So there should be no vmlinux.h
> > at all in the first. Which is exactly what happens in my attempts
> > to reproduce the issue. But even when fixing that up, the issue persists.
> >
> > > The bpf_wq bits should be related to a similar-ish issue where one
> > > config setting is not set and so it's not included in the final BTF.
> >
> > I'll look into how exactly things end up in vmlinux.h.
> > At least the headers for 'struct bpf_wq' are always included somewhere.
> > But maybe the type also needs to be used to define some structure.
> >
> > > I paged out how we can ignore selftests based on the .config, so if you
> > > have any hints, that would be nice :)
> >
> > Inspecting the kernel configuration might be hard, as there might be no file
> > for it available. Could you use vmlinux.h itself for feature detection?
> >
>
> Actually I think I remember the rationale:
> - because working with config is hard, we just hide any struct
> definition we need in progs/hid_bpf_helpers.h before including
> vmlinux.h
> - then we manually define them
>
> So it looks like this is a step I forgot to make when I added the last
> few bits: redefine struct bpf_wq and struct hid_device.
That makes sense. Thanks for checking.
> Technically we shouldn't even need to redefine the entire struct, but
> only the bits we are accessing, because bpf with CO-RE will do the
> offsets for us :)
>
> Would the following patch fixes the issue?:
I expect so. However none of the other bot (re-b)builds reproduced this
issue, so I can't validate it. I'll put this down as some sort of fluke
that it occurred while building my patch, especially given all the other
weirdness in that report. Your patch should fix it for good.
> ---
> From bf4030f8116a4bcafe9f8d84f3d03dd2eedc58a4 Mon Sep 17 00:00:00 2001
> From: Benjamin Tissoires <bentiss@kernel.org>
> Date: Thu, 12 Mar 2026 18:29:40 +0100
> Subject: [PATCH] selftests/hid: fix compilation when bpf_wq and hid_device are
> not exported
>
> This can happen in situations when CONFIG_HID_SUPPORT is set to no, or
> some complex situations where struct bpf_wq is not exported.
>
> So do the usual dance of hiding them before including vmlinux.h, and
> then redefining them and make use of CO-RE to have the correct offsets.
>
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> ---
> tools/testing/selftests/hid/progs/hid_bpf_helpers.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> index 80ab60905865..2c6ec907dd05 100644
> --- a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> +++ b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> @@ -8,9 +8,11 @@
> /* "undefine" structs and enums in vmlinux.h, because we "override" them below */
> #define hid_bpf_ctx hid_bpf_ctx___not_used
> #define hid_bpf_ops hid_bpf_ops___not_used
> +#define hid_device hid_device___not_used
> #define hid_report_type hid_report_type___not_used
> #define hid_class_request hid_class_request___not_used
> #define hid_bpf_attach_flags hid_bpf_attach_flags___not_used
> +#define bpf_wq bpf_wq___not_used
> #define HID_INPUT_REPORT HID_INPUT_REPORT___not_used
> #define HID_OUTPUT_REPORT HID_OUTPUT_REPORT___not_used
> #define HID_FEATURE_REPORT HID_FEATURE_REPORT___not_used
> @@ -29,9 +31,11 @@
>
> #undef hid_bpf_ctx
> #undef hid_bpf_ops
> +#undef hid_device
> #undef hid_report_type
> #undef hid_class_request
> #undef hid_bpf_attach_flags
> +#undef bpf_wq
> #undef HID_INPUT_REPORT
> #undef HID_OUTPUT_REPORT
> #undef HID_FEATURE_REPORT
> @@ -55,6 +59,14 @@ enum hid_report_type {
> HID_REPORT_TYPES,
> };
>
> +struct hid_device {
> + unsigned int id;
> +} __attribute__((preserve_access_index));
> +
> +struct bpf_wq {
> + __u64 __opaque[2];
> +};
> +
> struct hid_bpf_ctx {
> struct hid_device *hid;
> __u32 allocated_size;
> --
> 2.52.0
> ---
>
> Cheers,
> Benjamin
>
> >
> > Thomas
> >
> > > > On Wed, Mar 11, 2026 at 03:29:54PM +0100, kernel test robot wrote:
> > > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/vdso
> > > > > head: f7178f159b2a36d070fd43b0d751e4e4415ec39e
> > > > > commit: 912632a7fd4cc1eac2778828d92e8fe46939d6bd [37/45] vdso/datapage: Trim down unnecessary includes
> > > > > config: riscv-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260311/202603111558.KLCIxsZB-lkp@intel.com/config)
> > > > > compiler: riscv64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
> > > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260311/202603111558.KLCIxsZB-lkp@intel.com/reproduce)
> > > > >
> > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > > > the same patch/commit), kindly add following tags
> > > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202603111558.KLCIxsZB-lkp@intel.com/
> > > > >
> > > > > All errors (new ones prefixed by >>):
> > > > >
> > > > > In file included from progs/hid.c:3:
> > > > > >> progs/hid_bpf_helpers.h:117:31: error: declaration of 'struct bpf_wq' will not be visible outside of this function [-Werror,-Wvisibility]
> > > > > 117 | extern int bpf_wq_init(struct bpf_wq *wq, void *p__map, unsigned int flags) __weak __ksym;
> > > > > | ^
> > > > > progs/hid_bpf_helpers.h:118:32: error: declaration of 'struct bpf_wq' will not be visible outside of this function [-Werror,-Wvisibility]
> > > > > 118 | extern int bpf_wq_start(struct bpf_wq *wq, unsigned int flags) __weak __ksym;
> > > > > | ^
> > > > > progs/hid_bpf_helpers.h:119:39: error: declaration of 'struct bpf_wq' will not be visible outside of this function [-Werror,-Wvisibility]
> > > > > 119 | extern int bpf_wq_set_callback(struct bpf_wq *wq,
> > > > > | ^
> > > > > >> progs/hid.c:448:16: error: field has incomplete type 'struct bpf_wq'
> > > > > 448 | struct bpf_wq work;
> > > > > | ^
> > > > > progs/hid.c:448:9: note: forward declaration of 'struct bpf_wq'
> > > > > 448 | struct bpf_wq work;
> > > > > | ^
> > > > > >> progs/hid.c:487:18: error: incompatible pointer types passing 'struct bpf_wq *' to parameter of type 'struct bpf_wq *' [-Wincompatible-pointer-types]
> > > > > 487 | if (bpf_wq_init(wq, &hmap, 0) != 0)
> > > > > | ^~
> > > > > progs/hid_bpf_helpers.h:117:39: note: passing argument to parameter 'wq' here
> > > > > 117 | extern int bpf_wq_init(struct bpf_wq *wq, void *p__map, unsigned int flags) __weak __ksym;
> > > > > | ^
> > > > > progs/hid.c:490:26: error: incompatible pointer types passing 'struct bpf_wq *' to parameter of type 'struct bpf_wq *' [-Wincompatible-pointer-types]
> > > > > 490 | if (bpf_wq_set_callback(wq, wq_cb_sleepable, 0))
> > > > > | ^~
> > > > > progs/hid_bpf_helpers.h:119:47: note: passing argument to parameter 'wq' here
> > > > > 119 | extern int bpf_wq_set_callback(struct bpf_wq *wq,
> > > > > | ^
> > > > > progs/hid.c:493:19: error: incompatible pointer types passing 'struct bpf_wq *' to parameter of type 'struct bpf_wq *' [-Wincompatible-pointer-types]
> > > > > 493 | if (bpf_wq_start(wq, 0))
> > > > > | ^~
> > > > > progs/hid_bpf_helpers.h:118:40: note: passing argument to parameter 'wq' here
> > > > > 118 | extern int bpf_wq_start(struct bpf_wq *wq, unsigned int flags) __weak __ksym;
> > > > > | ^
> > > > > progs/hid.c:503:24: error: incomplete definition of type 'struct hid_device'
> > > > > 503 | int hid = hid_ctx->hid->id;
> > > > > | ~~~~~~~~~~~~^
> > > > > progs/hid_bpf_helpers.h:59:9: note: forward declaration of 'struct hid_device'
> > > > > 59 | struct hid_device *hid;
> > > > > | ^
> > > > > 8 errors generated.
> > > > >
> > > > > --
> > > > > 0-DAY CI Kernel Test Service
> > > > > https://github.com/intel/lkp-tests/wiki
> > > >
> >
^ permalink raw reply
* Re: [PATCH v4 2/2] arm: dts: renesas: r8a7740-armadillo800eva: Add wakeup-source to st1232
From: Geert Uytterhoeven @ 2026-03-13 8:41 UTC (permalink / raw)
To: phucduc.bui
Cc: krzk+dt, krzk, krzysztof.kozlowski, conor+dt, devicetree,
dmitry.torokhov, hechtb, javier.carrasco, jeff, linux-input,
linux-kernel, linux-renesas-soc, magnus.damm, robh, wsa+renesas
In-Reply-To: <20260309000319.74880-3-phucduc.bui@gmail.com>
On Mon, 9 Mar 2026 at 01:04, <phucduc.bui@gmail.com> wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Add the wakeup-source property to the ST1232 touchscreen node
> in the device tree so that the touchscreen interrupt can wake
> the system from suspend when the panel is touched.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [tip:timers/vdso 37/45] progs/hid_bpf_helpers.h:117:31: error: declaration of 'struct bpf_wq' will not be visible outside of this function
From: Benjamin Tissoires @ 2026-03-13 8:51 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Jiri Kosina, linux-input, kernel test robot, oe-kbuild-all,
linux-kernel, x86, Thomas Gleixner
In-Reply-To: <20260313091537-26f300e2-7595-40c8-8890-be4413b0adc0@linutronix.de>
On Mar 13 2026, Thomas Weißschuh wrote:
> On Thu, Mar 12, 2026 at 06:34:15PM +0100, Benjamin Tissoires wrote:
> > On Mar 12 2026, Thomas Wei�schuh wrote:
> > > On Wed, Mar 11, 2026 at 06:05:25PM +0100, Benjamin Tissoires wrote:
> > > > On Mar 11 2026, Thomas Wei�schuh wrote:
> > > > > could you take a look at the report below?
> > > > > This looks like an issue in the HID BPF subsystem, surfaced by my
> > > > > unrelated change. Does this ring a bell for you?
> > > > >
> > > > > I wasn't able to reproduce it so far, but will continue looking into it.
> > > >
> > > > Both struct bpf_wq and struct hid_device should be generated in the
> > > > vmlinux.h that we include in the selftests. So this is definitely not
> > > > related to your patch AFAICT.
> > >
> > > Ack. To be sure I sent this branch again through 0day and will see if it
> > > breaks on the same commit.
> > >
> > > > Looking in the config, we have `# CONFIG_HID_SUPPORT is not set` -> so
> > > > that would explain why struct hid_device is not available. But in that
> > > > case, why are the HID selftests even built?
> > >
> > > CONFIG_DEBUG_INFO_BTF is also not set. So there should be no vmlinux.h
> > > at all in the first. Which is exactly what happens in my attempts
> > > to reproduce the issue. But even when fixing that up, the issue persists.
> > >
> > > > The bpf_wq bits should be related to a similar-ish issue where one
> > > > config setting is not set and so it's not included in the final BTF.
> > >
> > > I'll look into how exactly things end up in vmlinux.h.
> > > At least the headers for 'struct bpf_wq' are always included somewhere.
> > > But maybe the type also needs to be used to define some structure.
> > >
> > > > I paged out how we can ignore selftests based on the .config, so if you
> > > > have any hints, that would be nice :)
> > >
> > > Inspecting the kernel configuration might be hard, as there might be no file
> > > for it available. Could you use vmlinux.h itself for feature detection?
> > >
> >
> > Actually I think I remember the rationale:
> > - because working with config is hard, we just hide any struct
> > definition we need in progs/hid_bpf_helpers.h before including
> > vmlinux.h
> > - then we manually define them
> >
> > So it looks like this is a step I forgot to make when I added the last
> > few bits: redefine struct bpf_wq and struct hid_device.
>
> That makes sense. Thanks for checking.
>
> > Technically we shouldn't even need to redefine the entire struct, but
> > only the bits we are accessing, because bpf with CO-RE will do the
> > offsets for us :)
> >
> > Would the following patch fixes the issue?:
>
> I expect so. However none of the other bot (re-b)builds reproduced this
> issue, so I can't validate it. I'll put this down as some sort of fluke
> that it occurred while building my patch, especially given all the other
> weirdness in that report. Your patch should fix it for good.
Thanks.
For reference, submitted here:
https://lore.kernel.org/linux-input/20260313-wip-bpf-fixes-v1-1-74b860315060@kernel.org/T/#u
Cheers,
Benjamin
>
> > ---
> > From bf4030f8116a4bcafe9f8d84f3d03dd2eedc58a4 Mon Sep 17 00:00:00 2001
> > From: Benjamin Tissoires <bentiss@kernel.org>
> > Date: Thu, 12 Mar 2026 18:29:40 +0100
> > Subject: [PATCH] selftests/hid: fix compilation when bpf_wq and hid_device are
> > not exported
> >
> > This can happen in situations when CONFIG_HID_SUPPORT is set to no, or
> > some complex situations where struct bpf_wq is not exported.
> >
> > So do the usual dance of hiding them before including vmlinux.h, and
> > then redefining them and make use of CO-RE to have the correct offsets.
> >
> > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > ---
> > tools/testing/selftests/hid/progs/hid_bpf_helpers.h | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> > index 80ab60905865..2c6ec907dd05 100644
> > --- a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> > +++ b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> > @@ -8,9 +8,11 @@
> > /* "undefine" structs and enums in vmlinux.h, because we "override" them below */
> > #define hid_bpf_ctx hid_bpf_ctx___not_used
> > #define hid_bpf_ops hid_bpf_ops___not_used
> > +#define hid_device hid_device___not_used
> > #define hid_report_type hid_report_type___not_used
> > #define hid_class_request hid_class_request___not_used
> > #define hid_bpf_attach_flags hid_bpf_attach_flags___not_used
> > +#define bpf_wq bpf_wq___not_used
> > #define HID_INPUT_REPORT HID_INPUT_REPORT___not_used
> > #define HID_OUTPUT_REPORT HID_OUTPUT_REPORT___not_used
> > #define HID_FEATURE_REPORT HID_FEATURE_REPORT___not_used
> > @@ -29,9 +31,11 @@
> >
> > #undef hid_bpf_ctx
> > #undef hid_bpf_ops
> > +#undef hid_device
> > #undef hid_report_type
> > #undef hid_class_request
> > #undef hid_bpf_attach_flags
> > +#undef bpf_wq
> > #undef HID_INPUT_REPORT
> > #undef HID_OUTPUT_REPORT
> > #undef HID_FEATURE_REPORT
> > @@ -55,6 +59,14 @@ enum hid_report_type {
> > HID_REPORT_TYPES,
> > };
> >
> > +struct hid_device {
> > + unsigned int id;
> > +} __attribute__((preserve_access_index));
> > +
> > +struct bpf_wq {
> > + __u64 __opaque[2];
> > +};
> > +
> > struct hid_bpf_ctx {
> > struct hid_device *hid;
> > __u32 allocated_size;
> > --
> > 2.52.0
> > ---
> >
> > Cheers,
> > Benjamin
> >
> > >
> > > Thomas
> > >
> > > > > On Wed, Mar 11, 2026 at 03:29:54PM +0100, kernel test robot wrote:
> > > > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/vdso
> > > > > > head: f7178f159b2a36d070fd43b0d751e4e4415ec39e
> > > > > > commit: 912632a7fd4cc1eac2778828d92e8fe46939d6bd [37/45] vdso/datapage: Trim down unnecessary includes
> > > > > > config: riscv-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260311/202603111558.KLCIxsZB-lkp@intel.com/config)
> > > > > > compiler: riscv64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
> > > > > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260311/202603111558.KLCIxsZB-lkp@intel.com/reproduce)
> > > > > >
> > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > > > > the same patch/commit), kindly add following tags
> > > > > > | Reported-by: kernel test robot <lkp@intel.com>
> > > > > > | Closes: https://lore.kernel.org/oe-kbuild-all/202603111558.KLCIxsZB-lkp@intel.com/
> > > > > >
> > > > > > All errors (new ones prefixed by >>):
> > > > > >
> > > > > > In file included from progs/hid.c:3:
> > > > > > >> progs/hid_bpf_helpers.h:117:31: error: declaration of 'struct bpf_wq' will not be visible outside of this function [-Werror,-Wvisibility]
> > > > > > 117 | extern int bpf_wq_init(struct bpf_wq *wq, void *p__map, unsigned int flags) __weak __ksym;
> > > > > > | ^
> > > > > > progs/hid_bpf_helpers.h:118:32: error: declaration of 'struct bpf_wq' will not be visible outside of this function [-Werror,-Wvisibility]
> > > > > > 118 | extern int bpf_wq_start(struct bpf_wq *wq, unsigned int flags) __weak __ksym;
> > > > > > | ^
> > > > > > progs/hid_bpf_helpers.h:119:39: error: declaration of 'struct bpf_wq' will not be visible outside of this function [-Werror,-Wvisibility]
> > > > > > 119 | extern int bpf_wq_set_callback(struct bpf_wq *wq,
> > > > > > | ^
> > > > > > >> progs/hid.c:448:16: error: field has incomplete type 'struct bpf_wq'
> > > > > > 448 | struct bpf_wq work;
> > > > > > | ^
> > > > > > progs/hid.c:448:9: note: forward declaration of 'struct bpf_wq'
> > > > > > 448 | struct bpf_wq work;
> > > > > > | ^
> > > > > > >> progs/hid.c:487:18: error: incompatible pointer types passing 'struct bpf_wq *' to parameter of type 'struct bpf_wq *' [-Wincompatible-pointer-types]
> > > > > > 487 | if (bpf_wq_init(wq, &hmap, 0) != 0)
> > > > > > | ^~
> > > > > > progs/hid_bpf_helpers.h:117:39: note: passing argument to parameter 'wq' here
> > > > > > 117 | extern int bpf_wq_init(struct bpf_wq *wq, void *p__map, unsigned int flags) __weak __ksym;
> > > > > > | ^
> > > > > > progs/hid.c:490:26: error: incompatible pointer types passing 'struct bpf_wq *' to parameter of type 'struct bpf_wq *' [-Wincompatible-pointer-types]
> > > > > > 490 | if (bpf_wq_set_callback(wq, wq_cb_sleepable, 0))
> > > > > > | ^~
> > > > > > progs/hid_bpf_helpers.h:119:47: note: passing argument to parameter 'wq' here
> > > > > > 119 | extern int bpf_wq_set_callback(struct bpf_wq *wq,
> > > > > > | ^
> > > > > > progs/hid.c:493:19: error: incompatible pointer types passing 'struct bpf_wq *' to parameter of type 'struct bpf_wq *' [-Wincompatible-pointer-types]
> > > > > > 493 | if (bpf_wq_start(wq, 0))
> > > > > > | ^~
> > > > > > progs/hid_bpf_helpers.h:118:40: note: passing argument to parameter 'wq' here
> > > > > > 118 | extern int bpf_wq_start(struct bpf_wq *wq, unsigned int flags) __weak __ksym;
> > > > > > | ^
> > > > > > progs/hid.c:503:24: error: incomplete definition of type 'struct hid_device'
> > > > > > 503 | int hid = hid_ctx->hid->id;
> > > > > > | ~~~~~~~~~~~~^
> > > > > > progs/hid_bpf_helpers.h:59:9: note: forward declaration of 'struct hid_device'
> > > > > > 59 | struct hid_device *hid;
> > > > > > | ^
> > > > > > 8 errors generated.
> > > > > >
> > > > > > --
> > > > > > 0-DAY CI Kernel Test Service
> > > > > > https://github.com/intel/lkp-tests/wiki
> > > > >
> > >
>
^ permalink raw reply
* Re: [PATCH 1/4] selftests/hid: fix compilation when bpf_wq and hid_device are not exported
From: Thomas Weißschuh @ 2026-03-13 9:02 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Shuah Khan, linux-input, linux-kselftest,
linux-kernel, kernel test robot, stable
In-Reply-To: <20260313-wip-bpf-fixes-v1-1-74b860315060@kernel.org>
On Fri, Mar 13, 2026 at 08:40:24AM +0100, Benjamin Tissoires wrote:
> This can happen in situations when CONFIG_HID_SUPPORT is set to no, or
> some complex situations where struct bpf_wq is not exported.
>
> So do the usual dance of hiding them before including vmlinux.h, and
> then redefining them and make use of CO-RE to have the correct offsets.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202603111558.KLCIxsZB-lkp@intel.com/
> Cc: stable@vger.kernel.org
'Fixes' missing? Also for patch 2 in the series.
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
(Some nits below, feel free to ignore them)
> ---
> tools/testing/selftests/hid/progs/hid_bpf_helpers.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> index 80ab60905865..2c6ec907dd05 100644
> --- a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> +++ b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> @@ -8,9 +8,11 @@
> /* "undefine" structs and enums in vmlinux.h, because we "override" them below */
> #define hid_bpf_ctx hid_bpf_ctx___not_used
> #define hid_bpf_ops hid_bpf_ops___not_used
> +#define hid_device hid_device___not_used
> #define hid_report_type hid_report_type___not_used
> #define hid_class_request hid_class_request___not_used
> #define hid_bpf_attach_flags hid_bpf_attach_flags___not_used
> +#define bpf_wq bpf_wq___not_used
'bpf' would sort before 'hid' alphabetically.
> #define HID_INPUT_REPORT HID_INPUT_REPORT___not_used
> #define HID_OUTPUT_REPORT HID_OUTPUT_REPORT___not_used
> #define HID_FEATURE_REPORT HID_FEATURE_REPORT___not_used
> @@ -29,9 +31,11 @@
>
> #undef hid_bpf_ctx
> #undef hid_bpf_ops
> +#undef hid_device
> #undef hid_report_type
> #undef hid_class_request
> #undef hid_bpf_attach_flags
> +#undef bpf_wq
> #undef HID_INPUT_REPORT
> #undef HID_OUTPUT_REPORT
> #undef HID_FEATURE_REPORT
> @@ -55,6 +59,14 @@ enum hid_report_type {
> HID_REPORT_TYPES,
> };
>
> +struct hid_device {
> + unsigned int id;
> +} __attribute__((preserve_access_index));
> +
> +struct bpf_wq {
> + __u64 __opaque[2];
> +};
The fields are never used, would a forward-declaration be sufficient?
struct bpf_wq;
Then you could also avoid the #define dance for that struct.
> +
> struct hid_bpf_ctx {
> struct hid_device *hid;
> __u32 allocated_size;
>
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH v5 0/4] input: add GPIO-based charlieplex keypad
From: Andy Shevchenko @ 2026-03-13 9:21 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: robin, andy, geert, robh, krzk+dt, conor+dt, dmitry.torokhov,
hvilleneuve, mkorpershoek, matthias.bgg,
angelogioacchino.delregno, lee, alexander.sverdlin, marek.vasut,
akurz, devicetree, linux-kernel, linux-input, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260312180304.3865850-1-hugo@hugovil.com>
On Thu, Mar 12, 2026 at 02:00:54PM -0400, Hugo Villeneuve wrote:
> Hello, this patch series add a new GPIO charlieplex keypad driver.
>
> The first two patches simply commonize two properties that are present in
> a few bindings, so that the actual patches for the charlieplex keypad driver
> can reuse them instead of also redefining them.
>
> I have tested the driver on a custom board with a Solidrun RZ/G2LC SOM
> with three charlieplex keyboards, all connected thru a single PCAL6416 I2C GPIO
> expander.
Based on the review of this series I have a question to Dmitry.
Are we going to have Documentation/process/maintainer-input.rst with the
preferences of input subsystem in style and other undocumented things? When?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5 4/4] Input: charlieplex_keypad: add GPIO charlieplex keypad
From: Andy Shevchenko @ 2026-03-13 9:22 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: robin, andy, geert, robh, krzk+dt, conor+dt, dmitry.torokhov,
hvilleneuve, mkorpershoek, matthias.bgg,
angelogioacchino.delregno, lee, alexander.sverdlin, marek.vasut,
akurz, devicetree, linux-kernel, linux-input, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260312180304.3865850-5-hugo@hugovil.com>
On Thu, Mar 12, 2026 at 02:00:58PM -0400, Hugo Villeneuve wrote:
>
> Add support for GPIO-based charlieplex keypad, allowing to control
> N^2-N keys using N GPIO lines.
>
> Reuse matrix keypad keymap to simplify, even if there is no concept
> of rows and columns in this type of keyboard.
LGTM,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/4] selftests/hid: fix compilation when bpf_wq and hid_device are not exported
From: Benjamin Tissoires @ 2026-03-13 13:28 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Jiri Kosina, Shuah Khan, linux-input, linux-kselftest,
linux-kernel, kernel test robot, stable
In-Reply-To: <20260313095731-682bbab2-5861-4aea-bc83-420492400c19@linutronix.de>
On Mar 13 2026, Thomas Weißschuh wrote:
> On Fri, Mar 13, 2026 at 08:40:24AM +0100, Benjamin Tissoires wrote:
> > This can happen in situations when CONFIG_HID_SUPPORT is set to no, or
> > some complex situations where struct bpf_wq is not exported.
> >
> > So do the usual dance of hiding them before including vmlinux.h, and
> > then redefining them and make use of CO-RE to have the correct offsets.
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202603111558.KLCIxsZB-lkp@intel.com/
> > Cc: stable@vger.kernel.org
>
> 'Fixes' missing? Also for patch 2 in the series.
>
> > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
>
> Reviewed-by: Thomas Wei�schuh <thomas.weissschuh@linutronix.de>
Thanks!
>
> (Some nits below, feel free to ignore them)
>
> > ---
> > tools/testing/selftests/hid/progs/hid_bpf_helpers.h | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> > index 80ab60905865..2c6ec907dd05 100644
> > --- a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> > +++ b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
> > @@ -8,9 +8,11 @@
> > /* "undefine" structs and enums in vmlinux.h, because we "override" them below */
> > #define hid_bpf_ctx hid_bpf_ctx___not_used
> > #define hid_bpf_ops hid_bpf_ops___not_used
> > +#define hid_device hid_device___not_used
> > #define hid_report_type hid_report_type___not_used
> > #define hid_class_request hid_class_request___not_used
> > #define hid_bpf_attach_flags hid_bpf_attach_flags___not_used
> > +#define bpf_wq bpf_wq___not_used
>
> 'bpf' would sort before 'hid' alphabetically.
ack (note that the last 3 are not sorted, oops).
>
> > #define HID_INPUT_REPORT HID_INPUT_REPORT___not_used
> > #define HID_OUTPUT_REPORT HID_OUTPUT_REPORT___not_used
> > #define HID_FEATURE_REPORT HID_FEATURE_REPORT___not_used
> > @@ -29,9 +31,11 @@
> >
> > #undef hid_bpf_ctx
> > #undef hid_bpf_ops
> > +#undef hid_device
> > #undef hid_report_type
> > #undef hid_class_request
> > #undef hid_bpf_attach_flags
> > +#undef bpf_wq
> > #undef HID_INPUT_REPORT
> > #undef HID_OUTPUT_REPORT
> > #undef HID_FEATURE_REPORT
> > @@ -55,6 +59,14 @@ enum hid_report_type {
> > HID_REPORT_TYPES,
> > };
> >
> > +struct hid_device {
> > + unsigned int id;
> > +} __attribute__((preserve_access_index));
> > +
> > +struct bpf_wq {
> > + __u64 __opaque[2];
> > +};
>
> The fields are never used, would a forward-declaration be sufficient?
>
> struct bpf_wq;
>
> Then you could also avoid the #define dance for that struct.
Unfortunately no. The fields are not used, but the struct is stored in
struct elem, and we use that struct size to compute the size of the map
elements. So we need to tell the compiler how much memory it needs to
be.
Cheers,
Benjamin
>
> > +
> > struct hid_bpf_ctx {
> > struct hid_device *hid;
> > __u32 allocated_size;
> >
> > --
> > 2.52.0
> >
>
^ permalink raw reply
* [PATCH] HID: intel-thc-hid: Set HID_PHYS with PCI BDF
From: Daniel Schaefer @ 2026-03-13 13:39 UTC (permalink / raw)
To: linux-input
Cc: Daniel Schaefer, Even Xu, Xinpeng Sun, Jiri Kosina,
Benjamin Tissoires, Sakari Ailus
Currently HID_PHYS is empty, which means userspace tools (e.g. fwupd)
that depend on it for distinguishing the devices, are unable to do so.
Other drivers like i2c-hid, usbhid, surface-hid, all populate it.
With this change it's set to, for example: HID_PHYS=0000:00:10.0
Each function has just a single HID device, as far as I can tell, so
there is no need to add a suffix.
Tested with fwupd 2.1.1, can avoid https://github.com/fwupd/fwupd/pull/9995
Cc: Even Xu <even.xu@intel.com>
Cc: Xinpeng Sun <xinpeng.sun@intel.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Daniel Schaefer <git@danielschaefer.me>
---
drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-hid.c | 1 +
drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-hid.c b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-hid.c
index f9fcb398673b..8075992e8732 100644
--- a/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-hid.c
+++ b/drivers/hid/intel-thc-hid/intel-quicki2c/quicki2c-hid.c
@@ -127,6 +127,7 @@ int quicki2c_hid_probe(struct quicki2c_device *qcdev)
hid->product = le16_to_cpu(qcdev->dev_desc.product_id);
snprintf(hid->name, sizeof(hid->name), "%s %04X:%04X", "quicki2c-hid",
hid->vendor, hid->product);
+ strscpy(hid->phys, dev_name(qcdev->dev), sizeof(hid->phys));
ret = hid_add_device(hid);
if (ret) {
diff --git a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c
index 82c72bfa2795..91d5807b4a83 100644
--- a/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c
+++ b/drivers/hid/intel-thc-hid/intel-quickspi/quickspi-hid.c
@@ -118,6 +118,7 @@ int quickspi_hid_probe(struct quickspi_device *qsdev)
hid->product = le16_to_cpu(qsdev->dev_desc.product_id);
snprintf(hid->name, sizeof(hid->name), "%s %04X:%04X", "quickspi-hid",
hid->vendor, hid->product);
+ strscpy(hid->phys, dev_name(qsdev->dev), sizeof(hid->phys));
ret = hid_add_device(hid);
if (ret) {
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Vineeth Remanan Pillai @ 2026-03-13 14:02 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrii Nakryiko, Mathieu Desnoyers, Peter Zijlstra,
Dmitry Ilvokhin, Masami Hiramatsu, 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, 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, linux-trace-kernel, linux-kernel
In-Reply-To: <20260312130255.6476e560@gandalf.local.home>
On Thu, Mar 12, 2026 at 1:03 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 12 Mar 2026 09:54:29 -0700
> Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> > > > emit_trace_foo()
> > > > __trace_foo()
> >
> > this seems like the best approach, IMO. double-underscored variants
> > are usually used for some specialized/internal version of a function
> > when we know that some conditions are correct (e.g., lock is already
> > taken, or something like that). Which fits here: trace_xxx() will
> > check if tracepoint is enabled, while __trace_xxx() will not check and
> > just invoke the tracepoint? It's short, it's distinct, and it says "I
> > know what I am doing".
>
> Honestly, I consider double underscore as internal only and not something
> anyone but the subsystem maintainers use.
>
> This, is a normal function where it's just saying: If you have it already
> enabled, then you can use this. Thus, I don't think it qualifies as a "you
> know what you are doing".
>
> Perhaps: call_trace_foo() ?
>
call_trace_foo has one collision with the tracepoint
sched_update_nr_running and a function
call_trace_sched_update_nr_running. I had considered this and later
moved to trace_invoke_foo() because of the collision. But I can rename
call_trace_sched_update_nr_running to something else if call_trace_foo
is the general consensus.
Thanks,
Vineeth
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: input: touchscreen: convert fsl-mx25-tcq.txt to yaml
From: Rob Herring @ 2026-03-13 14:12 UTC (permalink / raw)
To: Frank Li
Cc: Dmitry Torokhov, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones, linux-input,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260211-yaml_mfd-v1-1-05cb48bc6f09@nxp.com>
On Wed, Feb 11, 2026 at 04:41:04PM -0500, Frank Li wrote:
> Convert fsl-mx25-tcq.txt to yaml.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../bindings/input/touchscreen/fsl,imx25-tcq.yaml | 69 ++++++++++++++++++++++
> .../bindings/input/touchscreen/fsl-mx25-tcq.txt | 34 -----------
> 2 files changed, 69 insertions(+), 34 deletions(-)
Linux-next is broken as the MFD binding has been picked up without this
one, so I've applied it.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: touchscreen: trivial-touch: Move allOf: after required:
From: Frank Li @ 2026-03-13 14:56 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Conor Dooley, Dmitry Torokhov, Job Noorman,
Krzysztof Kozlowski, Rob Herring, linux-input, linux-renesas-soc
In-Reply-To: <20260312224925.186077-1-marek.vasut+renesas@mailbox.org>
On Thu, Mar 12, 2026 at 11:49:01PM +0100, Marek Vasut wrote:
> Majority of schemas place allOf: after required: . Documentation
Nit: If there special char, suggest use 'allOf:' 'required:'. "Documentation"
is reduntant.
Just said "writing-schema.rst hints this order".
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Documentation/devicetree/bindings/writing-schema.rst also hints at
> this ordering. Trivially update this schema. No functional change.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> NOTE: This comes from https://lore.kernel.org/all/20260117-grinning-heavy-crab-11f245@quoll/
> where krzk comments "allOf: should be placed after required: block."
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Frank Li <Frank.Li@nxp.com>
> Cc: Job Noorman <job@noorman.info>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-input@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> .../bindings/input/touchscreen/trivial-touch.yaml | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml b/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
> index 6441d21223caf..6316a8d32f39b 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/trivial-touch.yaml
> @@ -53,14 +53,14 @@ properties:
>
> wakeup-source: true
>
> -allOf:
> - - $ref: touchscreen.yaml
> -
> required:
> - compatible
> - reg
> - interrupts
>
> +allOf:
> + - $ref: touchscreen.yaml
> +
> unevaluatedProperties: false
>
> examples:
> --
> 2.51.0
>
^ 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