* [PATCH v2] dt-bindings: touchscreen: trivial-touch: Move allOf: after required:
From: Marek Vasut @ 2026-03-13 19:33 UTC (permalink / raw)
To: devicetree
Cc: Marek Vasut, Conor Dooley, Frank Li, Conor Dooley,
Dmitry Torokhov, 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.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
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
---
V2: - Fix up the nits from Frank
- Add RB from Frank
- Add AB from Conor
---
.../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 02/61] btrfs: Prefer IS_ERR_OR_NULL over manual NULL check
From: David Sterba @ 2026-03-13 19:22 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Chris Mason, David Sterba
In-Reply-To: <20260310-b4-is_err_or_null-v1-2-bd63b656022d@avm.de>
On Tue, Mar 10, 2026 at 12:48:28PM +0100, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> IS_ERR_OR_NULL() already uses likely(!ptr) internally. checkpatch does
> not like nesting it:
> > WARNING: nested (un)?likely() calls, IS_ERR_OR_NULL already uses
> > unlikely() internally
> Remove the explicit use of likely().
>
> Change generated with coccinelle.
>
> To: Chris Mason <clm@fb.com>
> To: David Sterba <dsterba@suse.com>
> Cc: linux-btrfs@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Added to for-next, we seem to be using IS_ERR_OR_NULL() already in a
few other places so this is makes sense for consistency. Thanks.
^ permalink raw reply
* Re: [PATCH 4/4] HID: core: Export device version via HID_FIRMWARE_VERSION uevent
From: Daniel Schaefer @ 2026-03-13 18:20 UTC (permalink / raw)
To: Mario Limonciello
Cc: linux-input, Richard Hughes, Jiri Kosina, Benjamin Tissoires,
linux
In-Reply-To: <6b53a537-9989-4b34-b033-402773c871be@amd.com>
> Isn't this in
> hid.git#for-7.1/lenovo-v2
Oh yes okay, I with this already in place, I should make my patches
set hdev->firmware_version instead of hdev->version.
Will send another series and drop my last patch in favor of yours:
https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/commit/?h=for-7.1/lenovo-v2&id=6ca9029c823b7853e980585e757343e0e84227cd
On Sat, Mar 14, 2026 at 2:00 AM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
>
>
> On 3/13/2026 12:56 PM, Daniel Schaefer wrote:
> > Expose the HID device version to userspace via the new
> > HID_FIRMWARE_VERSION uevent property. This enables userspace tools
> > (such as fwupd and hidapi) to retrieve device firmware version
> > information, providing parity with Windows HidD_GetAttributes() API
> > which returns VID, PID, and VersionNumber.
> >
> > The version is exported as a 4-digit uppercase hexadecimal value
> > (e.g., "0100" for version 1.0), consistent with how USB devices
> > report bcdDevice.
> >
> > fwupd can handle this since:
> > https://github.com/fwupd/fwupd/commit/fb0d4cc98abe253003ea0e1837277fd42971e0de
> > But the kernel hasn't yet exposed this.
> >
> > hidapi patch is in-flight: https://github.com/libusb/hidapi/pull/777
> >
> > Cc: Richard Hughes <richard@hughsie.com>
> > Cc: Mario Limonciello <mario.limonciello@amd.com>
> > Cc: Jiri Kosina <jikos@kernel.org>
> > Cc: Benjamin Tissoires <bentiss@kernel.org>
> > Cc: linux@frame.work
> > Signed-off-by: Daniel Schaefer <dhs@frame.work>
> > ---
> > drivers/hid/hid-core.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> > index da57cbf0af26..c2075d5b40c3 100644
> > --- a/drivers/hid/hid-core.c
> > +++ b/drivers/hid/hid-core.c
> > @@ -2884,6 +2884,9 @@ static int hid_uevent(const struct device *dev, struct kobj_uevent_env *env)
> > if (add_uevent_var(env, "HID_UNIQ=%s", hdev->uniq))
> > return -ENOMEM;
> >
> > + if (add_uevent_var(env, "HID_FIRMWARE_VERSION=%04X", hdev->version))
> > + return -ENOMEM;
> > +
> > if (add_uevent_var(env, "MODALIAS=hid:b%04Xg%04Xv%08Xp%08X",
> > hdev->bus, hdev->group, hdev->vendor, hdev->product))
> > return -ENOMEM;
>
> Isn't this in
>
> hid.git#for-7.1/lenovo-v2
^ permalink raw reply
* Re: [PATCH 4/4] HID: core: Export device version via HID_FIRMWARE_VERSION uevent
From: Mario Limonciello @ 2026-03-13 17:59 UTC (permalink / raw)
To: Daniel Schaefer, linux-input
Cc: Richard Hughes, Jiri Kosina, Benjamin Tissoires, linux
In-Reply-To: <20260313175659.268094-5-dhs@frame.work>
On 3/13/2026 12:56 PM, Daniel Schaefer wrote:
> Expose the HID device version to userspace via the new
> HID_FIRMWARE_VERSION uevent property. This enables userspace tools
> (such as fwupd and hidapi) to retrieve device firmware version
> information, providing parity with Windows HidD_GetAttributes() API
> which returns VID, PID, and VersionNumber.
>
> The version is exported as a 4-digit uppercase hexadecimal value
> (e.g., "0100" for version 1.0), consistent with how USB devices
> report bcdDevice.
>
> fwupd can handle this since:
> https://github.com/fwupd/fwupd/commit/fb0d4cc98abe253003ea0e1837277fd42971e0de
> But the kernel hasn't yet exposed this.
>
> hidapi patch is in-flight: https://github.com/libusb/hidapi/pull/777
>
> Cc: Richard Hughes <richard@hughsie.com>
> Cc: Mario Limonciello <mario.limonciello@amd.com>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <bentiss@kernel.org>
> Cc: linux@frame.work
> Signed-off-by: Daniel Schaefer <dhs@frame.work>
> ---
> drivers/hid/hid-core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index da57cbf0af26..c2075d5b40c3 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2884,6 +2884,9 @@ static int hid_uevent(const struct device *dev, struct kobj_uevent_env *env)
> if (add_uevent_var(env, "HID_UNIQ=%s", hdev->uniq))
> return -ENOMEM;
>
> + if (add_uevent_var(env, "HID_FIRMWARE_VERSION=%04X", hdev->version))
> + return -ENOMEM;
> +
> if (add_uevent_var(env, "MODALIAS=hid:b%04Xg%04Xv%08Xp%08X",
> hdev->bus, hdev->group, hdev->vendor, hdev->product))
> return -ENOMEM;
Isn't this in
hid.git#for-7.1/lenovo-v2
^ permalink raw reply
* [PATCH 4/4] HID: core: Export device version via HID_FIRMWARE_VERSION uevent
From: Daniel Schaefer @ 2026-03-13 17:56 UTC (permalink / raw)
To: linux-input
Cc: Daniel Schaefer, Richard Hughes, Mario Limonciello, Jiri Kosina,
Benjamin Tissoires, linux
In-Reply-To: <20260313175659.268094-1-dhs@frame.work>
Expose the HID device version to userspace via the new
HID_FIRMWARE_VERSION uevent property. This enables userspace tools
(such as fwupd and hidapi) to retrieve device firmware version
information, providing parity with Windows HidD_GetAttributes() API
which returns VID, PID, and VersionNumber.
The version is exported as a 4-digit uppercase hexadecimal value
(e.g., "0100" for version 1.0), consistent with how USB devices
report bcdDevice.
fwupd can handle this since:
https://github.com/fwupd/fwupd/commit/fb0d4cc98abe253003ea0e1837277fd42971e0de
But the kernel hasn't yet exposed this.
hidapi patch is in-flight: https://github.com/libusb/hidapi/pull/777
Cc: Richard Hughes <richard@hughsie.com>
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux@frame.work
Signed-off-by: Daniel Schaefer <dhs@frame.work>
---
drivers/hid/hid-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index da57cbf0af26..c2075d5b40c3 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2884,6 +2884,9 @@ static int hid_uevent(const struct device *dev, struct kobj_uevent_env *env)
if (add_uevent_var(env, "HID_UNIQ=%s", hdev->uniq))
return -ENOMEM;
+ if (add_uevent_var(env, "HID_FIRMWARE_VERSION=%04X", hdev->version))
+ return -ENOMEM;
+
if (add_uevent_var(env, "MODALIAS=hid:b%04Xg%04Xv%08Xp%08X",
hdev->bus, hdev->group, hdev->vendor, hdev->product))
return -ENOMEM;
--
2.52.0
^ permalink raw reply related
* [PATCH 3/4] HID: surface: Use device version instead of HID spec version
From: Daniel Schaefer @ 2026-03-13 17:56 UTC (permalink / raw)
To: linux-input
Cc: Daniel Schaefer, Maximilian Luz, Jiri Kosina, Benjamin Tissoires
In-Reply-To: <20260313175659.268094-1-dhs@frame.work>
Use attrs.version instead of hid_desc.hid_version for hid->version.
The driver has two structures with version information:
- hid_desc.hid_version: HID specification version
- attrs.version: Device-specific version number
The current code incorrectly uses hid_version from the HID descriptor,
which reports the HID spec version rather than the actual device
version. This change aligns with how other HID drivers report device
version and matches the attrs structure which already provides vendor
and product IDs.
Cc: Maximilian Luz <luzmaximilian@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Signed-off-by: Daniel Schaefer <dhs@frame.work>
---
drivers/hid/surface-hid/surface_hid_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/surface-hid/surface_hid_core.c b/drivers/hid/surface-hid/surface_hid_core.c
index 6690c24f28f0..e31d6597bc9b 100644
--- a/drivers/hid/surface-hid/surface_hid_core.c
+++ b/drivers/hid/surface-hid/surface_hid_core.c
@@ -206,7 +206,7 @@ int surface_hid_device_add(struct surface_hid_device *shid)
shid->hid->bus = BUS_HOST;
shid->hid->vendor = get_unaligned_le16(&shid->attrs.vendor);
shid->hid->product = get_unaligned_le16(&shid->attrs.product);
- shid->hid->version = get_unaligned_le16(&shid->hid_desc.hid_version);
+ shid->hid->version = get_unaligned_le16(&shid->attrs.version);
shid->hid->country = shid->hid_desc.country_code;
snprintf(shid->hid->name, sizeof(shid->hid->name), "Microsoft Surface %04X:%04X",
--
2.52.0
^ permalink raw reply related
* [PATCH 2/4] HID: goodix-spi: Use version_id for device version
From: Daniel Schaefer @ 2026-03-13 17:56 UTC (permalink / raw)
To: linux-input
Cc: Daniel Schaefer, Charles Wang, Jiri Kosina, Benjamin Tissoires
In-Reply-To: <20260313175659.268094-1-dhs@frame.work>
Use version_id instead of bcd_version for hid->version. The HID
descriptor contains two version fields:
- bcd_version: HID specification version (e.g., 0x0100 for HID 1.0)
- version_id: Device-specific version number
The current code incorrectly uses bcd_version, which reports the HID
spec version rather than the actual device/firmware version.
Cc: Charles Wang <charles.goodix@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Signed-off-by: Daniel Schaefer <dhs@frame.work>
---
drivers/hid/hid-goodix-spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-goodix-spi.c b/drivers/hid/hid-goodix-spi.c
index 80c0288a3a38..cbe95e0f6ce4 100644
--- a/drivers/hid/hid-goodix-spi.c
+++ b/drivers/hid/hid-goodix-spi.c
@@ -653,7 +653,7 @@ static int goodix_hid_init(struct goodix_ts_data *ts)
hid->bus = BUS_SPI;
hid->dev.parent = &ts->spi->dev;
- hid->version = le16_to_cpu(ts->hid_desc.bcd_version);
+ hid->version = le16_to_cpu(ts->hid_desc.version_id);
hid->vendor = le16_to_cpu(ts->hid_desc.vendor_id);
hid->product = le16_to_cpu(ts->hid_desc.product_id);
snprintf(hid->name, sizeof(hid->name), "%s %04X:%04X", "hid-gdix",
--
2.52.0
^ permalink raw reply related
* [PATCH 1/4] HID: i2c-hid: Use wVersionID for device version
From: Daniel Schaefer @ 2026-03-13 17:56 UTC (permalink / raw)
To: linux-input; +Cc: Daniel Schaefer, Jiri Kosina, Benjamin Tissoires, linux
In-Reply-To: <20260313175659.268094-1-dhs@frame.work>
Use wVersionID instead of bcdVersion for hid->version. Per the HID
over I2C Protocol Specification (Rev 1.0, Section 4.2), the HID
descriptor contains two version fields with distinct purposes:
- bcdVersion: HID specification version (always 0x0100 for HID 1.0)
- wVersionID: Device-specific version number
The current code incorrectly uses bcdVersion, which always reports
the HID spec version rather than the actual device/firmware version.
This change aligns I2C HID behavior with USB HID, which correctly
uses bcdDevice (the device version) for hid->version.
Currently wVersionID is not exposed to userspace at all. It is useful
because some firmwares use this as their firmware version. It's not
possible to check those device's firmware version on Linux, only
Windows.
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Cc: linux@frame.work
Signed-off-by: Daniel Schaefer <dhs@frame.work>
---
drivers/hid/i2c-hid/i2c-hid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index 5a183af3d5c6..41327e32f359 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -1056,7 +1056,7 @@ static int __i2c_hid_core_probe(struct i2c_hid *ihid)
return ret;
}
- hid->version = le16_to_cpu(ihid->hdesc.bcdVersion);
+ hid->version = le16_to_cpu(ihid->hdesc.wVersionID);
hid->vendor = le16_to_cpu(ihid->hdesc.wVendorID);
hid->product = le16_to_cpu(ihid->hdesc.wProductID);
--
2.52.0
^ permalink raw reply related
* [PATCH 0/4] HID: Use wVersionID for device version
From: Daniel Schaefer @ 2026-03-13 17:56 UTC (permalink / raw)
To: linux-input
Cc: Daniel Schaefer, Jiri Kosina, Benjamin Tissoires, linux,
Mario Limonciello, Maximilian Luz, Richard Hughes, Charles Wang
The motivation for this patch series is that the touchpads on Framework
Laptops expose their firmware version in the I2C HID device descriptor.
So the vendor's windows tool uses that to check the firmware version,
but Linux does not expose it to userspace at all.
We have added vendor specific HID reports to newer firmware for reading
the firmware version -that means however, the old firmware still cannot
reports its version to Linux at all.
I found that Mario has been planning to add a way for the kernel to
report HID firmware versions to userspace and added support to fwupd.
There's a kernel patch in flight that also exports this:
https://lwn.net/ml/all/20260220070533.4083667-1-derekjohn.clark@gmail.com/
While adding this for I2C HID devices, I noticed that the goodix-spi and
surface drivers also expose the HID protocol version, which is not very
useful. I do not have hardware to test those
The i2c-hid and core changes were tested on Framework Laptop 16.
I also added support to hidapi for reading the new uevent, if not
provided by USB already: https://github.com/libusb/hidapi/pull/777
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <bentiss@kernel.org>
Cc: linux-input@vger.kernel.org
Cc: linux@frame.work
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Maximilian Luz <luzmaximilian@gmail.com>
Cc: Richard Hughes <richard@hughsie.com>
Cc: Charles Wang <charles.goodix@gmail.com>
Daniel Schaefer (4):
HID: i2c-hid: Use wVersionID for device version
HID: goodix-spi: Use version_id for device version
HID: surface: Use device version instead of HID spec version
HID: core: Export device version via HID_FIRMWARE_VERSION uevent
drivers/hid/hid-core.c | 3 +++
drivers/hid/hid-goodix-spi.c | 2 +-
drivers/hid/i2c-hid/i2c-hid-core.c | 2 +-
drivers/hid/surface-hid/surface_hid_core.c | 2 +-
4 files changed, 6 insertions(+), 3 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH] dt-bindings: touchscreen: trivial-touch: Move allOf: after required:
From: Conor Dooley @ 2026-03-13 17:29 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Conor Dooley, Dmitry Torokhov, Frank Li, Job Noorman,
Krzysztof Kozlowski, Rob Herring, linux-input, linux-renesas-soc
In-Reply-To: <20260312224925.186077-1-marek.vasut+renesas@mailbox.org>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
On Thu, Mar 12, 2026 at 11:49:01PM +0100, Marek Vasut wrote:
> 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."
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
Certainly not expecting a new version for the "nits" provided by Frank.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 4/4] Input: Add TouchNetix aXiom I2C Touchscreen support
From: Andrew Thomas @ 2026-03-13 17:07 UTC (permalink / raw)
To: Marco Felsch
Cc: Luis Chamberlain, Russ Weight, Greg Kroah-Hartman,
Rafael J. Wysocki, Andrew Morton, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Kamel Bouhara,
Marco Felsch, Henrik Rydberg, Danilo Krummrich, linux-kernel,
devicetree, linux-input
In-Reply-To: <20260303-v6-10-topic-touchscreen-axiom-v6-4-8ac755add12b@pengutronix.de>
On Tue, Mar 03, 2026 at 11:41:22PM +0100, Marco Felsch wrote:
>This adds the initial support for the TouchNetix AX54A touchcontroller
>which is part of TouchNetix's aXiom touchscreen controller family.
>
>The TouchNetix aXiom family provides two physical interfaces: SPI and
>I2C. This patch covers only the I2C interface.
>
>Apart the input event handling the driver supports firmware updates too.
>One firmware interface handles the touchcontroller firmware (AXFW)
>update the other handles the touchcontroller configuration (TH2CFGBIN)
>update.
>
>Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
>---
> .../testing/sysfs-driver-input-touchnetix-axiom | 80 +
> drivers/input/touchscreen/Kconfig | 17 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/touchnetix_axiom.c | 3084 ++++++++++++++++++++
> 4 files changed, 3182 insertions(+)
>
>diff --git a/Documentation/ABI/testing/sysfs-driver-input-touchnetix-axiom b/Documentation/ABI/testing/sysfs-driver-input-touchnetix-axiom
>new file mode 100644
>index 0000000000000000000000000000000000000000..8262673630557bf1e595a97ec23e66c1c5370f71
>--- /dev/null
>+++ b/Documentation/ABI/testing/sysfs-driver-input-touchnetix-axiom
>@@ -0,0 +1,80 @@
>+What: /sys/bus/i2c/devices/xxx/fw_major
>+Date: Jan 2026
>+Contact: linux-input@vger.kernel.org
>+Description:
>+ Reports the firmware major version provided by the touchscreen.
>+
>+ Access: Read
>+
>+ Valid values: Represented as string
>+
>+What: /sys/bus/i2c/devices/xxx/fw_minor
>+Date: Jan 2026
>+Contact: linux-input@vger.kernel.org
>+Description:
>+ Reports the firmware minor version provided by the touchscreen.
>+
>+ Access: Read
>+
>+ Valid values: Represented as string
>+
>+What: /sys/bus/i2c/devices/xxx/fw_rc
>+Date: Jan 2026
>+Contact: linux-input@vger.kernel.org
>+Description:
>+ Reports the firmware release canidate version provided by the touchscreen.
>+
>+ Access: Read
>+
>+ Valid values: Represented as string
>+
>+What: /sys/bus/i2c/devices/xxx/fw_status
>+Date: Jan 2026
>+Contact: linux-input@vger.kernel.org
>+Description:
>+ Reports the firmware status provided by the touchscreen. It may
>+ be either "release" or "engineering".
>+
>+ Access: Read
>+
>+ Valid values: Represented as string
>+
>+What: /sys/bus/i2c/devices/xxx/fw_variant
>+Date: Jan 2026
>+Contact: linux-input@vger.kernel.org
>+Description:
>+ Reports the firmware variant provided by the touchscreen. It may
>+ be either: "0d", "2d", "3d", "force", "xl" or "unknown".
>+
>+ Access: Read
>+
>+ Valid values: Represented as string
>+
>+What: /sys/bus/i2c/devices/xxx/device_id
>+Date: Jan 2026
>+Contact: linux-input@vger.kernel.org
>+Description:
>+ Reports the touchscreen device id, for example: "54" for the AX54A.
>+
>+ Access: Read
>+
>+ Valid values: Represented as string
>+
>+What: /sys/bus/i2c/devices/xxx/device_state
>+Date: Jan 2026
>+Contact: linux-input@vger.kernel.org
>+Description:
>+ Reports the touchscreen device current runtime state. The
>+ following values are reported:
>+
>+ discovery: Device is in discovery mode.
>+ tcp: Device is in touch-control-protocol (tcp) mode. This is
>+ the normal working mode.
>+ th2cfg-update: Device is in configuration update mode.
>+ bootloader: Device is in bootloader mode, used for firmware
>+ updates.
>+ unknown: Device mode is unknown.
>+
>+ Access: Read
>+
>+ Valid values: Represented as string
>diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
>index 196905162945d59e775c3e0bff6540a82842229a..9263dd79dab7e518e27af35364fcebbff0ba706e 100644
>--- a/drivers/input/touchscreen/Kconfig
>+++ b/drivers/input/touchscreen/Kconfig
>@@ -806,6 +806,23 @@ config TOUCHSCREEN_MIGOR
> To compile this driver as a module, choose M here: the
> module will be called migor_ts.
>
>+config TOUCHSCREEN_TOUCHNETIX_AXIOM
>+ tristate "TouchNetix aXiom based touchscreen controllers"
>+ # We need to call into panel code so if DRM=m, this can't be 'y'
>+ depends on DRM || !DRM
>+ depends on I2C
>+ select CRC16
>+ select CRC32
>+ select REGMAP_I2C
>+ help
>+ Say Y here if you have a axiom touchscreen connected to
>+ your system.
>+
>+ If unsure, say N.
>+
>+ To compile this driver as a module, choose M here: the
>+ module will be called touchnetix_axiom.
>+
> config TOUCHSCREEN_TOUCHRIGHT
> tristate "Touchright serial touchscreen"
> select SERIO
>diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
>index 97a025c6a3770fb80255246eb63c11688ebd79eb..0591cb304784699bf2a8bda204461ac5f4532bb1 100644
>--- a/drivers/input/touchscreen/Makefile
>+++ b/drivers/input/touchscreen/Makefile
>@@ -88,6 +88,7 @@ obj-$(CONFIG_TOUCHSCREEN_SUR40) += sur40.o
> obj-$(CONFIG_TOUCHSCREEN_SURFACE3_SPI) += surface3_spi.o
> obj-$(CONFIG_TOUCHSCREEN_TI_AM335X_TSC) += ti_am335x_tsc.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o
>+obj-$(CONFIG_TOUCHSCREEN_TOUCHNETIX_AXIOM) += touchnetix_axiom.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
> obj-$(CONFIG_TOUCHSCREEN_TS4800) += ts4800-ts.o
>diff --git a/drivers/input/touchscreen/touchnetix_axiom.c b/drivers/input/touchscreen/touchnetix_axiom.c
>new file mode 100644
>index 0000000000000000000000000000000000000000..d909b108ee24dfc5a56b0ba735cb8a7882612d34
>--- /dev/null
>+++ b/drivers/input/touchscreen/touchnetix_axiom.c
>@@ -0,0 +1,3084 @@
>+// SPDX-License-Identifier: GPL-2.0-only
>+/*
>+ * TouchNetix aXiom Touchscreen Driver
>+ *
>+ * Copyright (C) 2024 Pengutronix
>+ *
>+ * Marco Felsch <kernel@pengutronix.de>
>+ */
>+
>+#include <drm/drm_panel.h>
>+#include <linux/bitfield.h>
>+#include <linux/bits.h>
>+#include <linux/completion.h>
>+#include <linux/crc16.h>
>+#include <linux/crc32.h>
>+#include <linux/delay.h>
...
>+static int axiom_u02_enter_bootloader(struct axiom_data *ts)
>+{
>+ struct axiom_u02_rev1_system_manager_msg msg = { };
>+ struct device *dev = ts->dev;
>+ unsigned int val;
>+ int error;
>+
>+ if (!axiom_driver_supports_usage(ts, AXIOM_U02))
>+ return -EINVAL;
>+
>+ /*
>+ * Enter the bootloader mode requires 3 consecutive messages so we can't
>+ * check for the response.
>+ * TODO: Check if it's required to add a delay between the consecutive
>+ * CMD_ENTERBOOTLOADER cmds.
>+ */
>+ msg.command = cpu_to_le16(AXIOM_U02_REV1_CMD_ENTERBOOTLOADER);
>+ msg.parameters[0] = cpu_to_le16(AXIOM_U02_REV1_PARAM0_ENTERBOOLOADER_KEY1);
>+ error = axiom_u02_send_msg(ts, &msg, false);
As mentioned before the delay between commands is too short and the next command is sent
before u02 is ready, which means the driver fails to put axiom into the bootloader.
Have you tested with an i2c speed of 400KHz?
All you need is to put true in above to wait for the bootloader command.
error = axiom_u02_send_msg(ts, &msg, true);
Just dont do it for the last command.
I am not too sure why you are having issues with this, this is how we do it for all our devices.
>+ if (error) {
>+ dev_err(dev, "Failed to send bootloader-key1: %d\n", error);
>+ return error;
>+ }
>+
>+ msg.parameters[0] = cpu_to_le16(AXIOM_U02_REV1_PARAM0_ENTERBOOLOADER_KEY2);
>+ error = axiom_u02_send_msg(ts, &msg, false);
Here also.
>+ if (error) {
>+ dev_err(dev, "Failed to send bootloader-key2: %d\n", error);
>+ return error;
>+ }
>+
>+ msg.parameters[0] = cpu_to_le16(AXIOM_U02_REV1_PARAM0_ENTERBOOLOADER_KEY3);
>+ error = axiom_u02_send_msg(ts, &msg, false);
>+ if (error) {
>+ dev_err(dev, "Failed to send bootloader-key3: %d\n", error);
>+ return error;
>+ }
>+
>+ /* Sleep before the first read to give the device time */
>+ fsleep(250 * USEC_PER_MSEC);
>+
>+ /* Wait till the device reports it is in bootloader mode */
>+ error = regmap_read_poll_timeout(ts->regmap,
>+ AXIOM_U31_REV1_DEVICE_ID_HIGH_REG, val,
>+ FIELD_GET(AXIOM_U31_REV1_MODE_MASK, val) ==
>+ AXIOM_U31_REV1_MODE_BLP,
>+ 250 * USEC_PER_MSEC, USEC_PER_SEC);
>+ if (error)
>+ return error;
>+
>+ return 0;
>+}
>+
...
Other than the above comments I have no issues with the driver.
We can support more usages in a later patch.
Many Thanks,
Andrew
^ permalink raw reply
* Re: [PATCH 2/4] HID: bpf: prevent buffer overflow in hid_hw_request
From: Jiri Kosina @ 2026-03-13 15:58 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Shuah Khan, linux-input, linux-kselftest, linux-kernel, stable
In-Reply-To: <20260313-wip-bpf-fixes-v1-2-74b860315060@kernel.org>
On Fri, 13 Mar 2026, Benjamin Tissoires wrote:
> 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>
Acked-by: Jiri Kosina <jkosina@suse.com>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/4] selftests/hid: fix compilation when bpf_wq and hid_device are not exported
From: Jiri Kosina @ 2026-03-13 15:58 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: 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, 13 Mar 2026, 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
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Acked-by: Jiri Kosina <jkosina@suse.com>
--
Jiri Kosina
SUSE Labs
^ 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
* 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 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
* [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 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
* 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 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 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: [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 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: 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
* [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
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