* Re: [PATCH 15/61] trace: Prefer IS_ERR_OR_NULL over manual NULL check
From: Steven Rostedt @ 2026-03-11 14:03 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Philipp Hahn, 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, Mathieu Desnoyers
In-Reply-To: <20260311141332.b611237d36b61b2409e66cb3@kernel.org>
On Wed, 11 Mar 2026 14:13:32 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> Hmm, now IS_ERR_OR_NULL() is an inline function, so it is safe.
> But if you want to use IS_ERR_OR_NULL() here, it will be better something like
>
> node = rhashtable_walk_next(&iter);
> while (!IS_ERR_OR_NULL(node)) {
> fprobe_remove_node_in_module(mod, node, &alist);
> node = rhashtable_walk_next(&iter);
> }
But now you need to have a duplicate code in order to acquire "node"
I think the patch just makes the code worse.
-- Steve
^ permalink raw reply
* Re: [PATCH 15/61] trace: Prefer IS_ERR_OR_NULL over manual NULL check
From: Geert Uytterhoeven @ 2026-03-11 14:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu (Google), Philipp Hahn, 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,
Mathieu Desnoyers
In-Reply-To: <20260311100332.6a2ce4b1@gandalf.local.home>
Hi Steven,
On Wed, 11 Mar 2026 at 15:03, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 11 Mar 2026 14:13:32 +0900
> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
>
> > Hmm, now IS_ERR_OR_NULL() is an inline function, so it is safe.
> > But if you want to use IS_ERR_OR_NULL() here, it will be better something like
> >
> > node = rhashtable_walk_next(&iter);
> > while (!IS_ERR_OR_NULL(node)) {
> > fprobe_remove_node_in_module(mod, node, &alist);
> > node = rhashtable_walk_next(&iter);
> > }
>
> But now you need to have a duplicate code in order to acquire "node"
>
> I think the patch just makes the code worse.
Obviously we need a new for_each_*() helper hiding all the gory internals?
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: [PATCH v4 4/4] Input: charlieplex_keypad: add GPIO charlieplex keypad
From: Hugo Villeneuve @ 2026-03-11 14:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dmitry Torokhov, robin, andy, geert, robh, krzk+dt, conor+dt,
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: <abBugQOUWG_FTs4f@ashevche-desk.local>
Hi Andy,
On Tue, 10 Mar 2026 21:18:25 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Mar 10, 2026 at 06:37:34PM +0000, Dmitry Torokhov wrote:
> > On Fri, Mar 06, 2026 at 04:21:09PM +0200, Andy Shevchenko wrote:
> > > On Thu, Mar 05, 2026 at 02:20:50PM -0500, Hugo Villeneuve wrote:
>
> ...
>
> > > > + int oline;
> > >
> > > Why signed?
> > >
> > > > + int code;
> > > > +
> > > > + for (code = 0, oline = 0; oline < keypad->nlines; oline++) {
> > >
> > > Can be like
> > >
> > > code = 0;
> > > for (unsigned int oline = 0; oline < keypad->nlines; oline++) {
> > >
> > > as iterator is not used outside the loop.
> > >
> > > > + DECLARE_BITMAP(values, MATRIX_MAX_ROWS);
> > >
> > > > + int iline;
> > >
> > > Why signed?
> >
> > Does it make any difference given practical limits on nlines?
>
> Maybe not, but might lead to interesting bugs in the future in case if used in
> some arithmetics.
I'll fix this in next version.
Hugo.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH 1/2] HID: input: Drop Asus UX550* touchscreen ignore battery quirks
From: Jiri Kosina @ 2026-03-11 14:27 UTC (permalink / raw)
To: Hans de Goede; +Cc: Benjamin Tissoires, Dmitry Torokhov, linux-input
In-Reply-To: <20260228145258.76937-1-johannes.goede@oss.qualcomm.com>
Both patches are now in hid.git#for-7.0/upstream-fixes
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH v8 0/3] TrackPoint doubletap enablement and user control
From: Vishnu Sankar @ 2026-03-11 14:31 UTC (permalink / raw)
To: mpearson-lenovo, dmitry.torokhov, hmh, hansg, corbet,
derekjohn.clark, ilpo.jarvinen
Cc: linux-input, linux-kernel, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar, Vishnu Sankar
This patch series adds support for TrackPoint doubletap with a clear and
simple separation of responsibilities between drivers:
1. Firmware enablement (trackpoint.c):
Automatically enables doubletap on capable hardware during device
detection.
2. User control (thinkpad_acpi.c):
Provides a sysfs interface to enable or disable delivery of doubletap
events to userspace.
The approach follows the KISS principle:
- The TrackPoint driver enables hardware functionality by default.
- The thinkpad_acpi driver controls whether ACPI doubletap events are
delivered, using existing hotkey filtering infrastructure.
- No cross-driver APIs or dual filtering paths are introduced.
Changes in v8:
- Added linux/array_size.h and linux/strings.h to the include lists for
ARRAY_SIZE() and strstarts() respectively.
- Better formatting.
- Fix indentation in doubletap_enable sysfs documentation.
Changes in v7:
- Removed unwanted comments and logs
Changes in v6:
- Documentation: fix formatting of the doubletap_enable sysfs attribute
description (separate "Values" list)
Changes in v5:
- Rename sysfs attribute from doubletap_filter to doubletap_enable to
reflect actual behavior.
- Fix inverted logic so events are delivered only when doubletap is
enabled.
- Suppress ACPI hotkey delivery instead of injecting or filtering input
events.
- Register the sysfs attribute via hotkey_attributes[] instead of
device_create_file().
- Drop unnecessary helper wrappers and debug logging.
- Update Documentation to reflect the new naming and semantics.
Changes in v4:
- Complete redesign based on reviewer feedback.
- trackpoint.c: Simplified to only enable doubletap by default.
- trackpoint.c: Removed all sysfs attributes and global variables.
- trackpoint.c: Uses firmware ID detection with deny list.
- thinkpad_acpi.c: Added sysfs interface for kernel-level event control.
- thinkpad_acpi.c: No cross-driver dependencies.
- Documentation: Updated to reflect simplified sysfs approach.
Changes in v3:
- No changes.
Changes in v2:
- Improved commit messages.
- Removed unnecessary comments and debug messages.
- Switched to strstarts() usage.
- Simplified firmware capability detection logic.
This version addresses the remaining review feedback by correcting the
naming and logic inversion, aligning sysfs semantics with behavior, and
fully integrating with existing thinkpad_acpi hotkey handling.
Vishnu Sankar (3):
input: trackpoint - Enable doubletap by default on capable devices
platform/x86: thinkpad_acpi: Add sysfs control for TrackPoint
double-tap
Documentation: thinkpad-acpi - Document doubletap_enable attribute
.../admin-guide/laptops/thinkpad-acpi.rst | 21 +++++++++
drivers/input/mouse/trackpoint.c | 46 +++++++++++++++++++
drivers/input/mouse/trackpoint.h | 5 ++
drivers/platform/x86/lenovo/thinkpad_acpi.c | 42 ++++++++++++++---
4 files changed, 107 insertions(+), 7 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH v8 1/3] input: trackpoint - Enable doubletap by default on capable devices
From: Vishnu Sankar @ 2026-03-11 14:31 UTC (permalink / raw)
To: mpearson-lenovo, dmitry.torokhov, hmh, hansg, corbet,
derekjohn.clark, ilpo.jarvinen
Cc: linux-input, linux-kernel, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar, Vishnu Sankar
In-Reply-To: <20260311143144.482145-1-vishnuocv@gmail.com>
Enable doubletap functionality by default on TrackPoint devices that
support it. The feature is detected using firmware ID pattern matching
(PNP: LEN03xxx) with a deny list of incompatible devices.
This provides immediate doubletap functionality without requiring
userspace configuration. The hardware is enabled during device
detection, while event filtering continues to be handled by the
thinkpad_acpi driver as before.
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
Changes in v8:
- Added missing includes (strings.h and array_size.h)
- Better formatting
Changes in v7:
- Removed unwanted comments
- Removed psmouse_info ()
Changes in v6:
- No Changes
Changes in v5:
- Renamed function to trackpoint_is_dt_capable()
- Simplified string comparison without sscanf()
- Removed wrapper function as suggested
- Fixed missing period in comment
Changes in v4:
- Simplified approach: removed all sysfs attributes and user interface
- Enable doubletap by default during device detection
- Removed global variables and complex attribute infrastructure
- Uses minimal firmware ID detection with deny list
- Follows KISS principle as suggested by reviewers
Changes in v3:
- No changes
Changes in v2:
- Improve commit messages
- Sysfs attributes moved to trackpoint.c
- Removed unnecessary comments
- Removed unnecessary debug messages
- Using strstarts() instead of strcmp()
- is_trackpoint_dt_capable() modified
- Removed _BIT suffix and used BIT() define
- Reverse the trackpoint_doubletap_status() logic to return error first
- Removed export functions as a result of the design change
- Changed trackpoint_dev->psmouse to parent_psmouse
- The path of trackpoint.h is not changed
---
drivers/input/mouse/trackpoint.c | 46 ++++++++++++++++++++++++++++++++
drivers/input/mouse/trackpoint.h | 5 ++++
2 files changed, 51 insertions(+)
diff --git a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
index b06c7ad721fe..3bd8fdf56cd3 100644
--- a/drivers/input/mouse/trackpoint.c
+++ b/drivers/input/mouse/trackpoint.c
@@ -5,6 +5,7 @@
* Trademarks are the property of their respective owners.
*/
+#include <linux/array_size.h>
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/serio.h>
@@ -12,6 +13,7 @@
#include <linux/input.h>
#include <linux/libps2.h>
#include <linux/proc_fs.h>
+#include <linux/string.h>
#include <linux/uaccess.h>
#include "psmouse.h"
#include "trackpoint.h"
@@ -393,6 +395,44 @@ static int trackpoint_reconnect(struct psmouse *psmouse)
return 0;
}
+/* List of known incapable device PNP IDs */
+static const char * const dt_incompatible_devices[] = {
+ "LEN0304",
+ "LEN0306",
+ "LEN0317",
+ "LEN031A",
+ "LEN031B",
+ "LEN031C",
+ "LEN031D",
+};
+
+/*
+ * Checks if it's a doubletap capable device.
+ * The PNP ID format is "PNP: LEN030d PNP0f13".
+ */
+static bool trackpoint_is_dt_capable(const char *pnp_id)
+{
+ size_t i;
+
+ if (!pnp_id)
+ return false;
+
+ /* Must start with "PNP: LEN03" */
+ if (!strstarts(pnp_id, "PNP: LEN03"))
+ return false;
+
+ /* Ensure enough length before comparing */
+ if (strlen(pnp_id) < 12)
+ return false;
+
+ /* Check deny-list */
+ for (i = 0; i < ARRAY_SIZE(dt_incompatible_devices); i++) {
+ if (!strncmp(pnp_id + 5, dt_incompatible_devices[i], 7))
+ return false;
+ }
+ return true;
+}
+
int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
{
struct ps2dev *ps2dev = &psmouse->ps2dev;
@@ -470,6 +510,12 @@ int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
psmouse->vendor, firmware_id,
(button_info & 0xf0) >> 4, button_info & 0x0f);
+ if (trackpoint_is_dt_capable(ps2dev->serio->firmware_id)) {
+ error = trackpoint_write(ps2dev, TP_DOUBLETAP, TP_DOUBLETAP_ENABLE);
+ if (error)
+ psmouse_warn(psmouse, "Failed to enable doubletap: %d\n", error);
+ }
+
return 0;
}
diff --git a/drivers/input/mouse/trackpoint.h b/drivers/input/mouse/trackpoint.h
index eb5412904fe0..3e03cdb39449 100644
--- a/drivers/input/mouse/trackpoint.h
+++ b/drivers/input/mouse/trackpoint.h
@@ -69,6 +69,8 @@
/* (how hard it is to drag */
/* with Z-axis pressed) */
+#define TP_DOUBLETAP 0x58 /* TrackPoint doubletap register */
+
#define TP_MINDRAG 0x59 /* Minimum amount of force needed */
/* to trigger dragging */
@@ -110,6 +112,9 @@
external device will be forced to 1 */
#define TP_MASK_EXT_TAG 0x04
+/* Doubletap register values */
+#define TP_DOUBLETAP_ENABLE 0xFF /* Enable value */
+#define TP_DOUBLETAP_DISABLE 0xFE /* Disable value */
/* Power on Self Test Results */
#define TP_POR_SUCCESS 0x3B
--
2.51.0
^ permalink raw reply related
* [PATCH v8 2/3] platform/x86: thinkpad_acpi: Add sysfs control for TrackPoint double-tap
From: Vishnu Sankar @ 2026-03-11 14:31 UTC (permalink / raw)
To: mpearson-lenovo, dmitry.torokhov, hmh, hansg, corbet,
derekjohn.clark, ilpo.jarvinen
Cc: linux-input, linux-kernel, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar, Vishnu Sankar
In-Reply-To: <20260311143144.482145-1-vishnuocv@gmail.com>
Add a sysfs attribute to enable or disable TrackPoint double-tap hotkey
events at the kernel level.
The TrackPoint firmware enables double-tap support automatically. This
interface allows userspace to control whether double-tap events are
forwarded to userspace.
The attribute is available at:
/sys/devices/platform/thinkpad_acpi/doubletap_enable
0 - Disable double-tap hotkey events
1 - Enable double-tap hotkey events (default)
Filtering is implemented by suppressing ACPI hotkey delivery without
injecting synthetic input events.
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
---
Changes in v2:
- Updated commit message to clarify dependency on trackpoint driver
- Now handling sysfs read/write of trackpoint driver using file read/write
- Removed sysfs attribute creation of trackpoint double tap here
- Reversed the logic and return false right away
- Dropped unnecessary debug messages
- Using dev_dbg() instead of pr_xxxx()
Changes in v3:
- No changes
Changes in v4:
- Simplified approach: single sysfs attribute for user control
- Clear naming: doubletap_filter instead of doubletap_enabled
- Intuitive behavior: 0=process events, 1=filter events
- No cross-driver dependencies or complex interactions
- Minimal code changes using existing thinkpad_acpi infrastructure
Changes in v5:
- Rename doubletap_filter to doubletap_enable to match actual behavior
- Fix inverted logic so events are emitted only when doubletap is enabled
- Register sysfs attribute via hotkey_attributes[] (no device_create_file)
---
---
drivers/platform/x86/lenovo/thinkpad_acpi.c | 42 +++++++++++++++++----
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/x86/lenovo/thinkpad_acpi.c b/drivers/platform/x86/lenovo/thinkpad_acpi.c
index 8982d92dfd97..1b29f1067d8f 100644
--- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
+++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
@@ -374,7 +374,7 @@ static struct {
u32 hotkey_poll_active:1;
u32 has_adaptive_kbd:1;
u32 kbd_lang:1;
- u32 trackpoint_doubletap:1;
+ u32 trackpoint_doubletap_enable:1;
struct quirk_entry *quirks;
} tp_features;
@@ -3019,6 +3019,31 @@ static const struct attribute_group adaptive_kbd_attr_group = {
.attrs = adaptive_kbd_attributes,
};
+/* sysfs doubletap enable --------------------------------------------- */
+static ssize_t doubletap_enable_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ return sysfs_emit(buf, "%d\n", tp_features.trackpoint_doubletap_enable);
+}
+
+static ssize_t doubletap_enable_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ bool enable;
+ int err;
+
+ err = kstrtobool(buf, &enable);
+ if (err)
+ return err;
+
+ tp_features.trackpoint_doubletap_enable = enable;
+ return count;
+}
+
+static DEVICE_ATTR_RW(doubletap_enable);
+
/* --------------------------------------------------------------------- */
static struct attribute *hotkey_attributes[] = {
@@ -3033,6 +3058,7 @@ static struct attribute *hotkey_attributes[] = {
&dev_attr_hotkey_recommended_mask.attr,
&dev_attr_hotkey_tablet_mode.attr,
&dev_attr_hotkey_radio_sw.attr,
+ &dev_attr_doubletap_enable.attr,
#ifdef CONFIG_THINKPAD_ACPI_HOTKEY_POLL
&dev_attr_hotkey_source_mask.attr,
&dev_attr_hotkey_poll_freq.attr,
@@ -3558,8 +3584,8 @@ static int __init hotkey_init(struct ibm_init_struct *iibm)
hotkey_poll_setup_safe(true);
- /* Enable doubletap by default */
- tp_features.trackpoint_doubletap = 1;
+ /* Enable TrackPoint doubletap event reporting by default. */
+ tp_features.trackpoint_doubletap_enable = 1;
return 0;
}
@@ -3864,9 +3890,9 @@ static bool hotkey_notify_8xxx(const u32 hkey, bool *send_acpi_ev)
{
switch (hkey) {
case TP_HKEY_EV_TRACK_DOUBLETAP:
- if (tp_features.trackpoint_doubletap)
- tpacpi_input_send_key(hkey, send_acpi_ev);
-
+ /* Only send event if doubletap is enabled */
+ if (!tp_features.trackpoint_doubletap_enable)
+ *send_acpi_ev = false;
return true;
default:
return false;
@@ -11488,7 +11514,9 @@ static bool tpacpi_driver_event(const unsigned int hkey_event)
mutex_unlock(&tpacpi_inputdev_send_mutex);
return true;
case TP_HKEY_EV_DOUBLETAP_TOGGLE:
- tp_features.trackpoint_doubletap = !tp_features.trackpoint_doubletap;
+ /* Toggle kernel-level doubletap event filtering */
+ tp_features.trackpoint_doubletap_enable =
+ !tp_features.trackpoint_doubletap_enable;
return true;
case TP_HKEY_EV_PROFILE_TOGGLE:
case TP_HKEY_EV_PROFILE_TOGGLE2:
--
2.51.0
^ permalink raw reply related
* [PATCH v8 3/3] Documentation: thinkpad-acpi - Document doubletap_enable attribute
From: Vishnu Sankar @ 2026-03-11 14:31 UTC (permalink / raw)
To: mpearson-lenovo, dmitry.torokhov, hmh, hansg, corbet,
derekjohn.clark, ilpo.jarvinen
Cc: linux-input, linux-kernel, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar, Vishnu Sankar
In-Reply-To: <20260311143144.482145-1-vishnuocv@gmail.com>
Document the doubletap_enable sysfs attribute for ThinkPad ACPI driver.
Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
---
Changes in v8:
- Fixes indentation
Changes in v7:
- Fix formatting
Changes in v6:
- Fix formatting of doubletap_enable sysfs documentation (separate Values list)
---
.../admin-guide/laptops/thinkpad-acpi.rst | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/Documentation/admin-guide/laptops/thinkpad-acpi.rst b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
index 03951ed6b628..f874db31801d 100644
--- a/Documentation/admin-guide/laptops/thinkpad-acpi.rst
+++ b/Documentation/admin-guide/laptops/thinkpad-acpi.rst
@@ -1522,6 +1522,27 @@ Currently 2 antenna types are supported as mentioned below:
The property is read-only. If the platform doesn't have support the sysfs
class is not created.
+doubletap_enable
+----------------
+
+sysfs: doubletap_enable
+
+Controls whether TrackPoint doubletap events are filtered out. Doubletap is a
+feature where quickly tapping the TrackPoint twice triggers a special function key event.
+
+The available commands are::
+
+ cat /sys/devices/platform/thinkpad_acpi/doubletap_enable
+ echo 1 | sudo tee /sys/devices/platform/thinkpad_acpi/doubletap_enable
+ echo 0 | sudo tee /sys/devices/platform/thinkpad_acpi/doubletap_enable
+
+Values:
+
+ * 1 - doubletap events are processed (default)
+ * 0 - doubletap events are filtered out (ignored)
+
+ This setting can also be toggled via the Fn+doubletap hotkey.
+
Auxmac
------
--
2.51.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-11 15:09 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, kernel test robot, oe-kbuild-all, linux-kernel, x86,
Thomas Gleixner
In-Reply-To: <202603111558.KLCIxsZB-lkp@intel.com>
Hi Jiri and Benjamin,
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.
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 01/61] Coccinelle: Prefer IS_ERR_OR_NULL over manual NULL check
From: Markus Elfring @ 2026-03-11 15:12 UTC (permalink / raw)
To: Philipp Hahn, cocci, Julia Lawall, Nicolas Palix
Cc: amd-gfx, apparmor, bpf, ceph-devel, 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-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,
LKML
In-Reply-To: <20260310-b4-is_err_or_null-v1-1-bd63b656022d@avm.de>
…
> +// Confidence: High
Some contributors presented discerning comments for this change approach.
Thus I became also curious how much they can eventually be taken better into account
by the means of the semantic patch language (Coccinelle software).
…
+@p1 depends on patch@
+expression E;
+@@
+(
> +- E != NULL && !IS_ERR(E)
> ++ !IS_ERR_OR_NULL(E)
> +|
> +- E == NULL || IS_ERR(E)
> ++ IS_ERR_OR_NULL(E)
> +|
> +- !IS_ERR(E) && E != NULL
> ++ !IS_ERR_OR_NULL(E)
> +|
> +- IS_ERR(E) || E == NULL
> ++ IS_ERR_OR_NULL(E)
> +)
Several detected expressions should refer to return values from function calls.
https://en.wikipedia.org/wiki/Return_statement
* Do any development challenges hinder still the determination of corresponding
failure predicates?
* How will interests evolve to improve data processing any further for such
use cases?
Regards,
Markus
^ 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-11 17:05 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: <20260311160618-dbfa08f6-8cfa-4f81-94a2-d6d97f79ae93@linutronix.de>
On Mar 11 2026, Thomas Weißschuh wrote:
> Hi Jiri and Benjamin,
>
> 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.
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?
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 paged out how we can ignore selftests based on the .config, so if you
have any hints, that would be nice :)
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] Input: uinput - fix circular locking dependency with ff-core
From: mikhail.v.gavrilov @ 2026-03-11 17:47 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20260228223628.472208-1-mikhail.v.gavrilov@gmail.com>
On Sun, 2026-03-01 at 03:36 +0500, Mikhail Gavrilov wrote:
> A lockdep circular locking dependency warning can be triggered
> reproducibly when using a force-feedback gamepad with uinput (for
> example, playing ELDEN RING under Wine with a Flydigi Vader 5
> controller):
>
> ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex
>
> The cycle is caused by four lock acquisition paths:
>
> 1. ff upload: input_ff_upload() holds ff->mutex and calls
> uinput_dev_upload_effect() -> uinput_request_submit() ->
> uinput_request_send(), which acquires udev->mutex.
>
> 2. device create: uinput_ioctl_handler() holds udev->mutex and calls
> uinput_create_device() -> input_register_device(), which acquires
> input_mutex.
>
> 3. device register: input_register_device() holds input_mutex and
> calls kbd_connect() -> input_register_handle(), which acquires
> dev->mutex.
>
> 4. evdev release: evdev_release() calls input_flush_device() under
> dev->mutex, which calls input_ff_flush() acquiring ff->mutex.
>
>
>
Hi Dmitry,
Friendly ping on this patch. It fixes a reproducible lockdep circular
dependency warning in uinput with force-feedback gamepads under
Wine/Proton, tested on 7.0-rc1.
I realize I should have included:
Fixes: ff462551235d ("Input: uinput - switch to the new FF
interface")
Cc: stable@vger.kernel.org
Should I resend as v2 with these tags, or can you add them when
applying?
--
Best Regards,
Mike Gavrilov.
^ permalink raw reply
* Re: [PATCH] Input: uinput - fix circular locking dependency with ff-core
From: Dmitry Torokhov @ 2026-03-11 17:50 UTC (permalink / raw)
To: mikhail.v.gavrilov; +Cc: linux-input, linux-kernel
In-Reply-To: <e28527adc34ace88462f2fcce53ab8586dc760a7.camel@gmail.com>
On Wed, Mar 11, 2026 at 10:47:25PM +0500, mikhail.v.gavrilov@gmail.com wrote:
> On Sun, 2026-03-01 at 03:36 +0500, Mikhail Gavrilov wrote:
> > A lockdep circular locking dependency warning can be triggered
> > reproducibly when using a force-feedback gamepad with uinput (for
> > example, playing ELDEN RING under Wine with a Flydigi Vader 5
> > controller):
> >
> > ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex
> >
> > The cycle is caused by four lock acquisition paths:
> >
> > 1. ff upload: input_ff_upload() holds ff->mutex and calls
> > uinput_dev_upload_effect() -> uinput_request_submit() ->
> > uinput_request_send(), which acquires udev->mutex.
> >
> > 2. device create: uinput_ioctl_handler() holds udev->mutex and calls
> > uinput_create_device() -> input_register_device(), which acquires
> > input_mutex.
> >
> > 3. device register: input_register_device() holds input_mutex and
> > calls kbd_connect() -> input_register_handle(), which acquires
> > dev->mutex.
> >
> > 4. evdev release: evdev_release() calls input_flush_device() under
> > dev->mutex, which calls input_ff_flush() acquiring ff->mutex.
> >
> >
> >
> Hi Dmitry,
>
> Friendly ping on this patch. It fixes a reproducible lockdep circular
> dependency warning in uinput with force-feedback gamepads under
> Wine/Proton, tested on 7.0-rc1.
>
> I realize I should have included:
>
> Fixes: ff462551235d ("Input: uinput - switch to the new FF
> interface")
> Cc: stable@vger.kernel.org
>
> Should I resend as v2 with these tags, or can you add them when
> applying?
Sorry I need a bit more time to evaluate the patch. I think what you
proposed makes sense, just give me a couple more days.
If there are no changes needed I can add necessary tags on my end.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] HID: logitech-hidpp: Enable MX Master 4 over bluetooth
From: Adrian Freund @ 2026-03-11 19:19 UTC (permalink / raw)
To: linux-kernel, linux-input; +Cc: Jiri Kosina, Benjamin Tissoires, Adrian Freund
The Logitech MX Master 4 can be connected over bluetooth or through a
Logitech Bolt receiver. This change adds support for non-standard HID
features, such as high resolution scrolling when the mouse is connected
over bluetooth.
Because no Logitech Bolt receiver driver exists yet those features
won't be available when the mouse is connected through the receiver.
Signed-off-by: Adrian Freund <adrian@freund.io>
---
drivers/hid/hid-logitech-hidpp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index d40932809ce1..cf07660bd85b 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4668,6 +4668,8 @@ static const struct hid_device_id hidpp_devices[] = {
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
{ /* Slim Solar+ K980 Keyboard over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb391) },
+ { /* MX Master 4 mouse over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb042) },
{}
};
--
2.53.0
^ permalink raw reply related
* [PATCH] xpad: Add RedOctane Games vendor id
From: Sanjay Govind @ 2026-03-11 21:31 UTC (permalink / raw)
To: Dmitry Torokhov, Vicki Pfau, Sanjay Govind, Nilton Perim Neto,
Mario Limonciello, Lode Willems
Cc: Pierre-Loup A. Griffais, linux-input, linux-kernel
Add vendor ID for RedOctane Games to xpad
Signed-off-by: Sanjay Govind <sanjay.govind9@gmail.com>
---
drivers/input/joystick/xpad.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index bf4accf3f581..e97ff270d978 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -585,6 +585,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOX360_VENDOR(0x3651), /* CRKD Controllers */
XPAD_XBOXONE_VENDOR(0x366c), /* ByoWave controllers */
XPAD_XBOX360_VENDOR(0x37d7), /* Flydigi Controllers */
+ XPAD_XBOX360_VENDOR(0x3958), /* RedOctane Games Controllers */
XPAD_XBOX360_VENDOR(0x413d), /* Black Shark Green Ghost Controller */
{ }
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 49/61] media: Prefer IS_ERR_OR_NULL over manual NULL check
From: Kieran Bingham @ 2026-03-11 23:03 UTC (permalink / raw)
To: Philipp Hahn, 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, lin
Cc: Shuah Khan, Mauro Carvalho Chehab
In-Reply-To: <20260310-b4-is_err_or_null-v1-49-bd63b656022d@avm.de>
Quoting Philipp Hahn (2026-03-10 11:49:15)
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Shuah Khan <skhan@linuxfoundation.org>
> To: Kieran Bingham <kieran.bingham@ideasonboard.com>
> To: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: linux-media@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/media/test-drivers/vimc/vimc-streamer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/test-drivers/vimc/vimc-streamer.c b/drivers/media/test-drivers/vimc/vimc-streamer.c
> index 15d863f97cbf96b7ca7fbf3d7b6b6ec39fcc8ae3..da5aca50bcb4990c06f28e5a883eb398606991e9 100644
> --- a/drivers/media/test-drivers/vimc/vimc-streamer.c
> +++ b/drivers/media/test-drivers/vimc/vimc-streamer.c
> @@ -167,7 +167,7 @@ static int vimc_streamer_thread(void *data)
> for (i = stream->pipe_size - 1; i >= 0; i--) {
> frame = stream->ved_pipeline[i]->process_frame(
> stream->ved_pipeline[i], frame);
> - if (!frame || IS_ERR(frame))
> + if (IS_ERR_OR_NULL(frame))
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> break;
> }
> //wait for 60hz
>
> --
> 2.43.0
>
^ permalink raw reply
* Fwd: [PATCH 09/12] dt-bindings: input: Document hid-over-spi DT schema
From: Jingyuan Liang @ 2026-03-12 0:58 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: <CAEe3GZHSqepvjjopLwrWX3_n4+RnCeVVQnAO=Swixgu2z3OpUw@mail.gmail.com>
(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.
>
> > +
> > + 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 v6 16/19] HID: Add documentation for Lenovo Legion Go drivers
From: Akira Yokosawa @ 2026-03-12 2:44 UTC (permalink / raw)
To: derekjohn.clark
Cc: bentiss, hughsient, jikos, linux-doc, linux-input, linux-kernel,
mario.limonciello, mpearson-lenovo, pgriffais, shaohz1, zhangzx36
In-Reply-To: <20260310072937.3295875-17-derekjohn.clark@gmail.com>
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
^ 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-12 6:46 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: <abGeK0FpNn5uXi8B@beelink>
Hi Benjamin,
thanks for the quick response.
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?
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] HID: logitech-hidpp: Enable MX Master 4 over bluetooth
From: Jiri Kosina @ 2026-03-12 12:44 UTC (permalink / raw)
To: Adrian Freund; +Cc: linux-kernel, linux-input, Benjamin Tissoires
In-Reply-To: <20260311191933.81007-1-adrian@freund.io>
On Wed, 11 Mar 2026, Adrian Freund wrote:
> The Logitech MX Master 4 can be connected over bluetooth or through a
> Logitech Bolt receiver. This change adds support for non-standard HID
> features, such as high resolution scrolling when the mouse is connected
> over bluetooth.
> Because no Logitech Bolt receiver driver exists yet those features
> won't be available when the mouse is connected through the receiver.
>
> Signed-off-by: Adrian Freund <adrian@freund.io>
Applied to hid.git#for-7.0/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v6 0/3] HID: Add support for multiple batteries per device
From: Jiri Kosina @ 2026-03-12 12:55 UTC (permalink / raw)
To: Lucas Zampieri
Cc: linux-input, linux-kernel, Benjamin Tissoires, Sebastian Reichel,
Bastien Nocera, linux-pm, lcasmz54
In-Reply-To: <20251226111019.31243-1-lzampier@redhat.com>
On Fri, 26 Dec 2025, Lucas Zampieri wrote:
> This series adds support for HID devices with multiple batteries.
>
> Currently, the HID battery reporting subsystem only supports one battery per
> device. There are several devices with multiple batteries that would benefit
> from this support:
> - Gaming headsets with batteries in both the headset and charging dock
> - Wireless earbuds with per-earbud batteries plus charging case
> - Split keyboards with per-side batteries
Lucas,
I've gone through this v6 and it looks good to me.
There are some simple conflicts with the current codebase through. So
instead of me fixing them without testing, could you please look into
rebasing it once more on top of hid.git, and I'll then merge it?
Thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: quirks: really enable the intended work around for appledisplay
From: Jiri Kosina @ 2026-03-12 12:56 UTC (permalink / raw)
To: René Rebe
Cc: Lukas Bulwahn, Benjamin Tissoires, linux-input, kernel-janitors,
linux-kernel, Lukas Bulwahn
In-Reply-To: <9pos2s83-p7q0-oq36-oqo3-s555o07p31n9@xreary.bet>
On Sat, 21 Feb 2026, Jiri Kosina wrote:
> > > Commit c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for
> > > appledisplay") intends to add a quirk for kernels built with Apple Cinema
> > > Display support, but it refers to the non-existing config option
> > > CONFIG_APPLEDISPLAY, whereas the config option for Apple Cinema Display
> > > support is named CONFIG_USB_APPLEDISPLAY.
> > >
> > > Refer to the intended config option CONFIG_USB_APPLEDISPLAY in the ifdef
> > > directive.
> > >
> > > Fixes: c7fabe4ad921 ("HID: quirks: work around VID/PID conflict for appledisplay")
> > > Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
> > > ---
> > >
> > > Note this fix suggests that the patch of commit c7fabe4ad921 in this form
> > > was never effectively tested, checking the effect that the commit message
> > > claims it would have.
> >
> > Thanks for spotting this. It was tested when I did this years ago. Though, maybe I
> > tested before adding the #if IS_ENABLED, anciently hit some key in Vim, o
> > something was renamed since then.
> >
> > Either way, I’ll get the display out of the basement and re-test it the coming days.
>
> Is there any results of this testing, please?
Friendly ping on this one :)
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 00/61] treewide: Use IS_ERR_OR_NULL over manual NULL check - refactor
From: Jason Gunthorpe @ 2026-03-12 12:57 UTC (permalink / raw)
To: Kuan-Wei Chiu
Cc: Philipp Hahn, 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
In-Reply-To: <abBlpGKO842B3yl9@google.com>
On Wed, Mar 11, 2026 at 02:40:36AM +0800, Kuan-Wei Chiu wrote:
> IMHO, the necessity of IS_ERR_OR_NULL() often highlights a confusing or
> flawed API design. It usually implies that the caller is unsure whether
> a failure results in an error pointer or a NULL pointer.
+1
IS_ERR_OR_NULL() should always be looked on with suspicion. Very
little should be returning some tri-state 'ERR' 'NULL' 'SUCCESS'
pointer. What does the middle condition even mean? IS_ERR_OR_NULL()
implies ERR and NULL are semanticly the same, so fix the things to
always use ERR.
If you want to improve things work to get rid of the NULL checks this
script identifies. Remove ERR or NULL because only one can ever
happen, or fix the source to consistently return ERR.
Jason
^ permalink raw reply
* Re: [PATCH] HID: appletb-kbd: add .resume method in PM
From: Jiri Kosina @ 2026-03-12 13:03 UTC (permalink / raw)
To: Aditya Garg; +Cc: Benjamin Tissoires, linux-input, linux-kernel, stable
In-Reply-To: <MAUPR01MB115468D46765D7DF8C2882B4CB86CA@MAUPR01MB11546.INDPRD01.PROD.OUTLOOK.COM>
On Tue, 17 Feb 2026, Aditya Garg wrote:
> Upon resuming from suspend, the Touch Bar driver was missing a resume
> method in order to restore the original mode the Touch Bar was on before
> suspending. It is the same as the reset_resume method.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Aditya Garg <gargaditya08@live.com>
Now in hid.git#for-7.0/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: mcp2221: Add module parameter to enfoce GPIO mode
From: Jiri Kosina @ 2026-03-12 13:05 UTC (permalink / raw)
To: Linus Walleij; +Cc: Rishi Gupta, Benjamin Tissoires, linux-input, linux-gpio
In-Reply-To: <20260218-hid-mcp2221-gpio-v1-1-a2ba53867354@kernel.org>
On Wed, 18 Feb 2026, Linus Walleij wrote:
> Add a module parameter to MCP2221 to enfor GPIO mode on the
> general purpose pins GP0 thru GP3.
>
> If I plug a device of this type into my machine, it will use the
> GP0, GP1, GP2 and GP3 pins for IIO voltage readings by default
> if CONFIG_IIO is set.
>
> However there may be cases where IIO is available but we want to
> use the GP0 thru GP3 lines for GPIO anyway.
>
> Example use:
>
> insmode hid-mcp2221.ko gpio_mode_enforce=1
>
> Result in dmesg:
> mcp2221 0003:04D8:00DD.0005: GPIO 0 not in gpio mode
> mcp2221 0003:04D8:00DD.0005: GPIO 1 not in gpio mode
> mcp2221 0003:04D8:00DD.0005: GPIO 2 not in gpio mode
> mcp2221 0003:04D8:00DD.0005: GPIO 3 not in gpio mode
> mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 0!
> mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 1!
> mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 2!
> mcp2221 0003:04D8:00DD.0005: Set GPIO mode for gpio pin 3!
>
> After this the gpiolib tools such as gpioset can be used to alter
> the GPIO line values successfully.
>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
Applied to hid.git#for-7.1/mcp2221, thanks.
--
Jiri Kosina
SUSE Labs
^ 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