* Re: [PATCH 1/2] hid: asus: add xg mobile 2023 external hardware support
From: Jiri Kosina @ 2026-02-27 13:11 UTC (permalink / raw)
To: Denis Benato
Cc: linux-kernel, linux-input, Benjamin Tissoires, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Ilpo Järvinen
In-Reply-To: <20260216175539.12415-1-denis.benato@linux.dev>
On Mon, 16 Feb 2026, Denis Benato wrote:
> XG mobile stations have the 0x5a endpoint and has to be initialized:
> add them to hid-asus.
Applied to hid.git#for-7.0/upstream-fixes.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH 1/1] HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure
From: Lee Jones @ 2026-02-27 10:09 UTC (permalink / raw)
To: lee, Filipe Laíns, Bastien Nocera, Jiri Kosina,
Benjamin Tissoires, linux-input, linux-kernel
Presently, if the force feedback initialisation fails when probing the
Logitech G920 Driving Force Racing Wheel for Xbox One, an error number
will be returned and propagated before the userspace infrastructure
(sysfs and /dev/input) has been torn down. If userspace ignores the
errors and continues to use its references to these dangling entities, a
UAF will promptly follow.
We have 2 options; continue to return the error, but ensure that all of
the infrastructure is torn down accordingly or continue to treat this
condition as a warning by emitting the message but returning success.
It is thought that the original author's intention was to emit the
warning but keep the device functional, less the force feedback feature,
so let's go with that.
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/hid-logitech-hidpp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index e871f1729d4b..eee9ab6a2fc4 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4487,10 +4487,12 @@ static int hidpp_probe(struct hid_device *hdev, const struct hid_device_id *id)
if (!ret)
ret = hidpp_ff_init(hidpp, &data);
- if (ret)
+ if (ret) {
hid_warn(hidpp->hid_dev,
"Unable to initialize force feedback support, errno %d\n",
ret);
+ ret = 0;
+ }
}
/*
--
2.53.0.473.g4a7958ca14-goog
^ permalink raw reply related
* Re: [PATCH v5 00/16] HID: Add Legion Go and Go S Drivers
From: Jiri Kosina @ 2026-02-26 22:53 UTC (permalink / raw)
To: Derek J. Clark
Cc: Benjamin Tissoires, Richard Hughes, Mario Limonciello,
Zhixin Zhang, Mia Shao, Mark Pearson, Pierre-Loup A . Griffais,
linux-input, linux-doc, linux-kernel
In-Reply-To: <20260224013217.1363996-1-derekjohn.clark@gmail.com>
On Tue, 24 Feb 2026, Derek J. Clark wrote:
> This series adds configuration driver support for the Legion Go S,
> Legion Go, and Legion Go 2 built-in controller HID interfaces. This
> allows for configuring hardware specific attributes such as the auso
> sleep timeout, rumble intensity, etc. non-configuration reports are
> forwarded to the HID subsystem to ensure no loss of functionality in
> userspace. Basic gamepad functionality is provided through xpad, while
> advanced features are currently only implemented in userspace daemons
> such as InputPlumber[1]. I plan to move this functionality into the
> kernel in a later patch series.
>
> Three new device.h macros are added that solve a fairly specific
> problem. Many of the attributes need to have the same name as other
> attributes when they are in separate attribute subdirectories. The
> previous version of this series, along with the upcoming his-asus-ally
> driver[2] use this macro to simplify the sysfs by removing redundancy.
> An upcoming out of tree driver for the Zotac Zone [3] also found this
> macro to be useful. This greatly reduces the path length and term
> redundancy of file paths in the sysfs, while also allowing for cleaner
> subdirectories that are grouped by functionality. Rather than carry the
> same macro in four drivers, it seems beneficial to me that we include the
> macro with the other device macros.
>
> A new HID uevent property is also added, HID_FIRMWARE_VERSION, so as to
> permit fwupd to read the firmware version of the Go S HID interface without
> detaching the kernel driver.
>
> Finally, there are some checkpatch warnings that will need to be supressed:
> WARNING: ENOSYS means 'invalid syscall nr' and nothing else
> 1292: FILE: drivers/hid/lenovo-legos-hid/lenovo-legos-hid-config.c:1085:
> + case -ENOSYS: /* during rmmod -ENOSYS is expected */
>
> This error handling case was added as it is experienced in the real world
> when the driver is rmmod. The LED subsystem produces this error code in
> its legacy code and this is not a new novel use of -ENOSYS, we are simply
> catching the case to avoid spurious errors in dmesg when the drivers are
> removed.
>
> [1]: https://github.com/ShadowBlip/InputPlumber/tree/main/src/drivers/lego
> [2]: https://lore.kernel.org/all/20240806081212.56860-1-luke@ljones.dev/
> [3]: https://github.com/flukejones/linux/tree/wip/zotac-zone-6.15/drivers/hid/zotac-zone-hid
>
> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
> ---
> Change Log
> v5:
> - Make all RO attributes cache the data during probe using delayed
> work for both drivers. All RW attributes are read in realtime to
> ensure they match the device current state in the event of firmware
> reset or a userspace application.
> - Fix endianness of version strings and print as hex for Go driver.
> - Remove reset__esume function. It was not being hit as the MCU of
> both devices disconnects of suspend, forcing a reinit of the driver.
> Udev or userpsace will need to set the OS Mode upon resume.
> v4: https://lore.kernel.org/linux-input/20260220070533.4083667-1-derekjohn.clark@gmail.com/
> - Use dmabuf allocated per request for both drivers instead of a devm
> preallocated buffer that is reused. This solves a bug where some
> attributes couldn't be restored without manual writing after resume.
> - Reduce the number of quirks and flags in the Go S init to only those
> necessary. Previously they were duplicated from the Go driver but
> everything except HID_CONNECT_HIDRAW was found to be unnessary
> during operational testing.
> - Clean up formatting for debug prints in Go S driver.
> - Fix bugs in RGB driver for Go that caused the effect to switch to
> solid when the speed or brightness was changed.
> - Remove extraneous setting of os_mode member of drvdata when setting
> os_mode. It will be read from the hardware in _show.
> v3: https://lore.kernel.org/linux-input/20260124014907.991265-1-derekjohn.clark@gmail.com/
> - Fix Documentation formatting by removing extra + characters.
> - Fix bugs in hid-lenovo-go-s IMU & TP RO attributes being tied to the
> wrong _show function.
> - Rename enume os_mode_index to os_mode_types_index to fix collision
> with os_mode_index attribute.
> - Remove accidental rename for enabled->enable attributes in patch 4
> - Add SOB for Mario in patch 10 as Co-Developer.
> v2: https://lore.kernel.org/linux-input/20251229031753.581664-1-derekjohn.clark@gmail.com/
> - Break up adding the Go S driver into feature specific patches.
> - Rename Go S driver from lenovo-legos-hid to hid-lenovo-go-s and move
> it out of a subdirectory.
> - Drop the arbitrary uevent properties patch.
> - Add Go series driver.
> - Move DEVICE_ATTR_NAMED macros to device.h.
> v1: https://lore.kernel.org/linux-input/20250703004943.515919-1-derekjohn.clark@gmail.com/
This is now queued in hid.git#for-7.1/lenovo.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v5 01/16] include: device.h: Add named device attributes
From: Greg Kroah-Hartman @ 2026-02-26 22:38 UTC (permalink / raw)
To: Jiri Kosina
Cc: Derek J. Clark, Benjamin Tissoires, Richard Hughes,
Mario Limonciello, Zhixin Zhang, Mia Shao, Mark Pearson,
Pierre-Loup A . Griffais, linux-input, linux-doc, linux-kernel,
Rafael J. Wysocki
In-Reply-To: <478589q4-1rp6-87q8-02o8-n50071039639@xreary.bet>
On Thu, Feb 26, 2026 at 06:05:10PM +0100, Jiri Kosina wrote:
> You would need and Ack from driver core maintainers (CCing Greg and Rafael
> here) on this one so that I can take it together with the rest of the
> series.
The comments are a bit odd in the descriptions of these new macros, but
hey, it's good enough to understand, so no objection from me.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/9] mfd: cpcap: convert documentation to schema and add Mot board support
From: Mark Brown @ 2026-02-26 22:13 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Liam Girdwood, David Lechner,
Tony Lindgren, Svyatoslav Ryhel
Cc: linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260223063858.12208-1-clamor95@gmail.com>
On Mon, 23 Feb 2026 08:38:49 +0200, Svyatoslav Ryhel wrote:
> The initial goal was only to add support for the CPCAP used in the Mot
> Tegra20 board; however, since the documentation was already partially
> converted, I decided to complete the conversion to schema too.
>
> The CPCAP regulator, leds, rtc, pwrbutton and core files were converted
> from TXT to YAML while preserving the original structure. Mot board
> compatibility was added to the regulator and core schema. Since these
> were one-line patches, they were not separated into dedicated commits;
> however, the commit message notes this for both cases.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/9] dt-bindings: regulator: cpcap-regulator: convert to DT schema
commit: 5a8ffc5dca9c096fe9c8879fa3a2faff723fbb8a
[2/9] dt-bindings: regulator: cpcap-regulator: document Mot regulator
commit: 0e5646030212856a7f022387a647694ba65e75a7
[3/9] regulator: cpcap-regulator: add support for Mot regulators
commit: d90c0f78379454d51a428e312ac6db573060185c
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3 1/9] dt-bindings: regulator: cpcap-regulator: convert to DT schema
From: Mark Brown @ 2026-02-26 18:55 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Pavel Machek, Liam Girdwood, David Lechner,
Tony Lindgren, linux-input, devicetree, linux-kernel, linux-leds
In-Reply-To: <20260223063858.12208-2-clamor95@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
On Mon, Feb 23, 2026 at 08:38:50AM +0200, Svyatoslav Ryhel wrote:
> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> from TXT to YAML format. Main functionality preserved.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5 01/16] include: device.h: Add named device attributes
From: Jiri Kosina @ 2026-02-26 17:05 UTC (permalink / raw)
To: Derek J. Clark
Cc: Benjamin Tissoires, Richard Hughes, Mario Limonciello,
Zhixin Zhang, Mia Shao, Mark Pearson, Pierre-Loup A . Griffais,
linux-input, linux-doc, linux-kernel, Greg Kroah-Hartman,
Rafael J. Wysocki
In-Reply-To: <20260224013217.1363996-2-derekjohn.clark@gmail.com>
You would need and Ack from driver core maintainers (CCing Greg and Rafael
here) on this one so that I can take it together with the rest of the
series.
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 24 Feb 2026, Derek J. Clark wrote:
> Adds DEVICE_ATTR_[RW|RO|WO]_NAMED macros for adding attributes that
> reuse the same sysfs name in a driver under separate subdirectories.
>
> When dealing with some devices it can be useful to be able to reuse
> the same name for similar attributes under a different subdirectory.
> For example, a single logical HID endpoint may provide a configuration
> interface for multiple physical devices. In such a case it is useful to
> provide symmetrical attribute names under different subdirectories on
> the configuration device. The Lenovo Legion Go is one such device,
> providing configuration to a detachable left controller, detachable
> right controller, the wireless transmission dongle, and the MCU. It is
> therefore beneficial to treat each of these as individual devices in
> the driver, providing a subdirectory for each physical device in the
> sysfs. As some attributes are reused by each physical device, it
> provides a much cleaner interface if the same driver can reuse the same
> attribute name in sysfs while uniquely distinguishing the store/show
> functions in the driver, rather than repeat string portions.
>
> Example new WO attrs:
> ATTRS{left_handle/reset}=="(not readable)"
> ATTRS{right_handle/reset}=="(not readable)"
> ATTRS{tx_dongle/reset}=="(not readable)"
>
> vs old WO attrs in a subdir:
> ATTRS{left_handle/left_handle_reset}=="(not readable)"
> ATTRS{right_handle/right_handle_reset}=="(not readable)"
> ATTRS{tx_dongle/tx_dongle_reset}=="(not readable)"
>
> or old WO attrs with no subdir:
> ATTRS{left_handle_reset}=="(not readable)"
> ATTRS{right_handle_reset}=="(not readable)"
> ATTRS{tx_dongle_reset}=="(not readable)"
>
> While the third option is usable, it doesn't logically break up the
> physical devices and creates a device directory with over 80 attributes
> once all attrs are defined.
>
> Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
> Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com>
> ---
> v4:
> - Use dmabuf per request instead of devm allocated static buffer.
> Resolves bug with side effects during suspend.
> ---
> include/linux/device.h | 46 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 0be95294b6e61..381463baed6d3 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -189,6 +189,22 @@ ssize_t device_show_string(struct device *dev, struct device_attribute *attr,
> #define DEVICE_ATTR_ADMIN_RW(_name) \
> struct device_attribute dev_attr_##_name = __ATTR_RW_MODE(_name, 0600)
>
> +/**
> + * DEVICE_ATTR_RW_NAMED - Define a read-write device attribute with a sysfs name
> + * that differs from the function name.
> + * @_name: Attribute function preface
> + * @_attrname: Attribute name as it wil be exposed in the sysfs.
> + *
> + * Like DEVICE_ATTR_RW(), but allows for reusing names under separate paths in
> + * the same driver.
> + */
> +#define DEVICE_ATTR_RW_NAMED(_name, _attrname) \
> + struct device_attribute dev_attr_##_name = { \
> + .attr = { .name = _attrname, .mode = 0644 }, \
> + .show = _name##_show, \
> + .store = _name##_store, \
> + }
> +
> /**
> * DEVICE_ATTR_RO - Define a readable device attribute.
> * @_name: Attribute name.
> @@ -207,6 +223,21 @@ ssize_t device_show_string(struct device *dev, struct device_attribute *attr,
> #define DEVICE_ATTR_ADMIN_RO(_name) \
> struct device_attribute dev_attr_##_name = __ATTR_RO_MODE(_name, 0400)
>
> +/**
> + * DEVICE_ATTR_RO_NAMED - Define a read-only device attribute with a sysfs name
> + * that differs from the function name.
> + * @_name: Attribute function preface
> + * @_attrname: Attribute name as it wil be exposed in the sysfs.
> + *
> + * Like DEVICE_ATTR_RO(), but allows for reusing names under separate paths in
> + * the same driver.
> + */
> +#define DEVICE_ATTR_RO_NAMED(_name, _attrname) \
> + struct device_attribute dev_attr_##_name = { \
> + .attr = { .name = _attrname, .mode = 0444 }, \
> + .show = _name##_show, \
> + }
> +
> /**
> * DEVICE_ATTR_WO - Define an admin-only writable device attribute.
> * @_name: Attribute name.
> @@ -216,6 +247,21 @@ ssize_t device_show_string(struct device *dev, struct device_attribute *attr,
> #define DEVICE_ATTR_WO(_name) \
> struct device_attribute dev_attr_##_name = __ATTR_WO(_name)
>
> +/**
> + * DEVICE_ATTR_WO_NAMED - Define a read-only device attribute with a sysfs name
> + * that differs from the function name.
> + * @_name: Attribute function preface
> + * @_attrname: Attribute name as it wil be exposed in the sysfs.
> + *
> + * Like DEVICE_ATTR_WO(), but allows for reusing names under separate paths in
> + * the same driver.
> + */
> +#define DEVICE_ATTR_WO_NAMED(_name, _attrname) \
> + struct device_attribute dev_attr_##_name = { \
> + .attr = { .name = _attrname, .mode = 0200 }, \
> + .store = _name##_store, \
> + }
> +
> /**
> * DEVICE_ULONG_ATTR - Define a device attribute backed by an unsigned long.
> * @_name: Attribute name.
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement
From: Lee Jones @ 2026-02-26 16:23 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, David Rheinsberg, linux-input, linux-kernel, stable
In-Reply-To: <aaBqruhB0a7m0SBG@plouf>
On Thu, 26 Feb 2026, Benjamin Tissoires wrote:
> On Feb 26 2026, Lee Jones wrote:
> > On Thu, 26 Feb 2026, Benjamin Tissoires wrote:
> >
> > > On Feb 26 2026, Lee Jones wrote:
> > > > On Tue, 24 Feb 2026, Jiri Kosina wrote:
> > > >
> > > > > On Tue, 24 Feb 2026, Benjamin Tissoires wrote:
> > > > >
> > > > > > Long story short: that patch is too intrusive as it makes assumption on
> > > > > > the behavior of the device. We need to understand where/if the bug was
> > > > > > spotted and fix the caller of hid_hw_raw_request, not the uhid
> > > > > > implementation.
> > > > >
> > > > > Thanks a lot for the analysis, Benjamin!
> > > > >
> > > > > I asked about that here:
> > > > >
> > > > > https://lore.kernel.org/all/172q4775-616s-p7s4-7n80-p8579n0r3516@xreary.bet/
> > > > >
> > > > > So let's wait for Lee to clarify. Until that, the patch stays out of the
> > > > > branch.
> > > >
> > > > Thanks to both of you for looking into this. I appreciate your efforts.
> > > >
> > > > This is very much real world.
> > > >
> > > > Is there a way to add an errata for the PS3 controller?
> > > >
> > >
> > > Unfortunatelly no. uhid merely emulates what a device can do, and HID is
> > > a convention. So if we were to have a special case to PS3 controllers,
> > > we would then start having to maintain an endless list of quirks when
> > > the issue is *not* in uhid, but in the processing of the device after
> > > (maybe in hid-core?).
> >
> > Actually I think the issue is in UHID. At least the way I read it.
>
> And I disagree :)
>
> >
> > Are there legitimate use-cases for devices overwriting the Report ID
> > contained in the first index of the data buffer? From my very limited
> > knowledge of the subsystem, this sounds like an oversight.
> >
>
> Legitimate, probably no, but we are talking about physical devices
> here. uhid is a mere replacement of a transport layer, and there is
> nothing that prevents a device to reply with a buffer starting with 1
> when requested about feature 2 (because it's firmware and they just
> don't care).
>
> This happens a lot with proprietary features on devices, when there is
> no spec, so ODM provide their own driver and they can do whatever they
> want.
>
> If uhid or any transport layer solely takes the decision that a reply to
> a request is wrong, we have no chance of fixing it after the fact. This
> is what happens with the PS3 controller: an undocumented feature is
> used, but that's what the Playstation does, so we need to tag along.
>
> I hope it makes more sense now.
>
> FTR, Lee shared the logs of the issue privately, and I already told him
> where we should fix the issue.
Thanks for all the help and the insight.
I will follow-up with the suggested fixes soon.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH V3 RESEND 0/2] Add tc3408 bindings and timing
From: Dmitry Torokhov @ 2026-02-26 16:06 UTC (permalink / raw)
To: Langyan Ye
Cc: robh, krzk+dt, conor+dt, jikos, bentiss, dianders, linux-input,
devicetree, linux-kernel
In-Reply-To: <20260108063524.742464-1-yelangyan@huaqin.corp-partner.google.com>
On Thu, Jan 08, 2026 at 02:35:22PM +0800, Langyan Ye wrote:
> The tc3408 touch screen chip same as Elan eKTH6915 controller
> has a reset gpio. The difference is that they have different
> post_power_delay_ms.
>
> According to the Parade TC3408 datasheet, the reset pin requires a
> pull-down duration longer than 10 ms, therefore post_power_delay_ms
> is set to 10. In addition, the chipset requires an initialization
> time greater than 300 ms after reset, so post_gpio_reset_on_delay_ms
> is configured as 300.
>
> Changes in v3:
> - PATCH 2/2: Corrected post_gpio_reset_on_delay_ms: 100 -> 300
> - Link to v2: https://lore.kernel.org/all/20250820122520.3356738-1-yelangyan@huaqin.corp-partner.google.com/
>
> Changes in v2:
> - PATCH 1/2: Drop redundant "bindings for" from subject
> - PATCH 1/2: Improve description (describe hardware instead of bindings)
> - PATCH 1/2: Drop "panel: true" property
> - PATCH 1/2: Drop redundant description for reset-gpios
> - PATCH 1/2: Use unevaluatedProperties: false instead of additionalProperties
> - Link to v1: https://lore.kernel.org/all/20250819034852.1230264-1-yelangyan@huaqin.corp-partner.google.com/
>
> Langyan Ye (2):
> dt-bindings: input: Add Parade TC3408 touchscreen controller
> HID: i2c-hid: elan: Add parade-tc3408 timing
>
> .../bindings/input/parade,tc3408.yaml | 68 +++++++++++++++++++
> drivers/hid/i2c-hid/i2c-hid-of-elan.c | 8 +++
> 2 files changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/parade,tc3408.yaml
Applied the lot, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement
From: Benjamin Tissoires @ 2026-02-26 15:51 UTC (permalink / raw)
To: Lee Jones
Cc: Jiri Kosina, David Rheinsberg, linux-input, linux-kernel, stable
In-Reply-To: <20260226140810.GD8023@google.com>
On Feb 26 2026, Lee Jones wrote:
> On Thu, 26 Feb 2026, Benjamin Tissoires wrote:
>
> > On Feb 26 2026, Lee Jones wrote:
> > > On Tue, 24 Feb 2026, Jiri Kosina wrote:
> > >
> > > > On Tue, 24 Feb 2026, Benjamin Tissoires wrote:
> > > >
> > > > > Long story short: that patch is too intrusive as it makes assumption on
> > > > > the behavior of the device. We need to understand where/if the bug was
> > > > > spotted and fix the caller of hid_hw_raw_request, not the uhid
> > > > > implementation.
> > > >
> > > > Thanks a lot for the analysis, Benjamin!
> > > >
> > > > I asked about that here:
> > > >
> > > > https://lore.kernel.org/all/172q4775-616s-p7s4-7n80-p8579n0r3516@xreary.bet/
> > > >
> > > > So let's wait for Lee to clarify. Until that, the patch stays out of the
> > > > branch.
> > >
> > > Thanks to both of you for looking into this. I appreciate your efforts.
> > >
> > > This is very much real world.
> > >
> > > Is there a way to add an errata for the PS3 controller?
> > >
> >
> > Unfortunatelly no. uhid merely emulates what a device can do, and HID is
> > a convention. So if we were to have a special case to PS3 controllers,
> > we would then start having to maintain an endless list of quirks when
> > the issue is *not* in uhid, but in the processing of the device after
> > (maybe in hid-core?).
>
> Actually I think the issue is in UHID. At least the way I read it.
And I disagree :)
>
> Are there legitimate use-cases for devices overwriting the Report ID
> contained in the first index of the data buffer? From my very limited
> knowledge of the subsystem, this sounds like an oversight.
>
Legitimate, probably no, but we are talking about physical devices
here. uhid is a mere replacement of a transport layer, and there is
nothing that prevents a device to reply with a buffer starting with 1
when requested about feature 2 (because it's firmware and they just
don't care).
This happens a lot with proprietary features on devices, when there is
no spec, so ODM provide their own driver and they can do whatever they
want.
If uhid or any transport layer solely takes the decision that a reply to
a request is wrong, we have no chance of fixing it after the fact. This
is what happens with the PS3 controller: an undocumented feature is
used, but that's what the Playstation does, so we need to tag along.
I hope it makes more sense now.
FTR, Lee shared the logs of the issue privately, and I already told him
where we should fix the issue.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH v3 3/4] dt-bindings: input: add GPIO charlieplex keypad
From: Hugo Villeneuve @ 2026-02-26 15:35 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: robin, andy, 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: <CAMuHMdVdYX9p9DfDoyMv8qEm52kY51QULkEnuxRBH2OyWyYf6g@mail.gmail.com>
Hi Geert,
On Thu, 26 Feb 2026 10:32:30 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Hugo,
>
> On Wed, 25 Feb 2026 at 16:54, Hugo Villeneuve <hugo@hugovil.com> wrote:
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Add DT bindings for GPIO charlieplex keypad.
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > @@ -0,0 +1,106 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +
> > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: GPIO charlieplex keypad
> > +
> > +maintainers:
> > + - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > +
> > +description: |
> > + The charlieplex keypad supports N^2)-N different key combinations (where N is
> > + the number of lines). Key presses and releases are detected by configuring
> > + only one line as output at a time, and reading other line states. This process
> > + is repeated for each line. Diodes are required to ensure current flows in only
> > + one direction between any pair of pins.
> > + This mechanism doesn't allow to detect simultaneous key presses.
>
> Indeed, e.g. pressing S1 and S2 simultaneously will show a ghost
> S5 keypress.
>
> > +
> > + Wiring example for 3 lines keyboard with 6 switches and 3 diodes:
> > +
> > + L0 --+---------------------+----------------------+
> > + | | |
> > + L1 -------+-----------+---------------------+ |
> > + | | | | | |
> > + L2 -------------+----------------+-----+ | |
> > + | | | | | | | | |
> > + | | | | | | | | |
> > + | S1 \ S2 \ | S3 \ S4 \ | S5 \ S6 \
> > + | | | | | | | | |
> > + | +--+--+ | +--+--+ | +--+--+
> > + | | | | | |
> > + | D1 v | D2 v | D3 v
> > + | - (k) | - (k) | - (k)
> > + | | | | | |
> > + +-------+ +-------+ +-------+
>
> Don't you need pull-down resistors on L[0-2], and/or a way to specify
> in DT to enable internal poll-down on GPIO controllers that support it?
> Some controllers may support internal pull-up only, but I guess that
> can be handled using GPIO_ACTIVE_LOW?
Yes, using something like this:
line-gpios = <&gpio2 25 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)
should work I think, although with my hardware unfortunately I cannot
test it.
Hugo.
>
> > +
> > + L: GPIO line
> > + S: switch
> > + D: diode (k indicates cathode)
> > +
> > +allOf:
> > + - $ref: input.yaml#
> > + - $ref: /schemas/input/matrix-keymap.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: gpio-charlieplex-keypad
> > +
> > + autorepeat: true
> > +
> > + debounce-delay-ms:
> > + default: 5
> > +
> > + line-gpios:
> > + description:
> > + List of GPIOs used as lines. The gpio specifier for this property
> > + depends on the gpio controller to which these lines are connected.
> > +
> > + linux,keymap: true
> > +
> > + poll-interval: true
> > +
> > + settling-time-us: true
> > +
> > + wakeup-source: true
> > +
> > +required:
> > + - compatible
> > + - line-gpios
> > + - linux,keymap
> > + - poll-interval
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > + #include <dt-bindings/input/input.h>
> > +
> > + charlieplex-keypad {
>
> "keyboard", as per Devicetree Specification Generic Names
> Recommendation.
>
> > + compatible = "gpio-charlieplex-keypad";
> > + debounce-delay-ms = <20>;
> > + poll-interval = <5>;
> > + settling-time-us = <2>;
> > +
> > + line-gpios = <&gpio2 25 GPIO_ACTIVE_HIGH
> > + &gpio2 26 GPIO_ACTIVE_HIGH
> > + &gpio2 27 GPIO_ACTIVE_HIGH>;
> > +
> > + /* MATRIX_KEY(output, input, key-code) */
> > + linux,keymap = <
> > + /*
> > + * According to wiring diagram above, if L1 is configured as
> > + * output and HIGH, and we detect a HIGH level on input L0,
> > + * then it means S1 is pressed: MATRIX_KEY(L1, L0, KEY...)
> > + */
> > + MATRIX_KEY(1, 0, KEY_F1) /* S1 */
> > + MATRIX_KEY(2, 0, KEY_F2) /* S2 */
> > + MATRIX_KEY(0, 1, KEY_F3) /* S3 */
> > + MATRIX_KEY(2, 1, KEY_F4) /* S4 */
> > + MATRIX_KEY(1, 2, KEY_F5) /* S5 */
> > + MATRIX_KEY(0, 2, KEY_F6) /* S6 */
> > + >;
> > + };
>
> 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
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH] Input: evdev: fix data race in evdev_read() and evdev_poll()
From: Osama Abdelkader @ 2026-02-26 15:17 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, linux-kernel; +Cc: syzbot+1b327485934adf39955b
In-Reply-To: <20260208194516.172227-1-osama.abdelkader@gmail.com>
On Sun, Feb 08, 2026 at 08:45:15PM +0100, Osama Abdelkader wrote:
> Protect all reads of client->packet_head with buffer_lock to fix a
> KCSAN-reported data race. The race occurs between:
>
> - evdev_pass_values() writing to packet_head (protected by buffer_lock)
> - evdev_read() reading packet_head without lock protection
> - evdev_poll() reading packet_head without lock protection
>
> The fix ensures all accesses to packet_head are protected by buffer_lock,
> matching the existing write-side protection pattern used in
> evdev_pass_values() and evdev_fetch_next_event().
>
> Changes:
> - evdev_read(): Protect packet_head read in O_NONBLOCK check
> - evdev_read(): Protect packet_head read in wait loop condition
> - evdev_poll(): Protect packet_head read in poll check
>
> KCSAN report:
> BUG: KCSAN: data-race in evdev_pass_values / evdev_read
>
> write to 0xffff888104842008 of 4 bytes by task 8439 on cpu 1:
> __pass_event drivers/input/evdev.c:239 [inline]
> evdev_pass_values+0x387/0x4e0 drivers/input/evdev.c:278
> evdev_events+0x8e/0xd0 drivers/input/evdev.c:306
> input_pass_values+0x123/0x390 drivers/input/input.c:128
> input_event_dispose+0x248/0x320 drivers/input/input.c:342
> input_handle_event+0x9e8/0xa20 drivers/input/input.c:370
> input_inject_event+0xbc/0x120 drivers/input/input.c:424
> evdev_write+0x224/0x2b0 drivers/input/evdev.c:528
> vfs_write+0x269/0x9f0 fs/read_write.c:684
> ksys_write+0xdc/0x1a0 fs/read_write.c:738
> __do_sys_write fs/read_write.c:749 [inline]
> __se_sys_write fs/read_write.c:746 [inline]
> __x64_sys_write+0x40/0x50 fs/read_write.c:746
> x64_sys_call+0x2847/0x3000 arch/x86/include/generated/asm/syscalls_64.h:2
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> read to 0xffff888104842008 of 4 bytes by task 2991 on cpu 0:
> evdev_read+0x157/0x5e0 drivers/input/evdev.c:572
> vfs_read+0x1ab/0x7f0 fs/read_write.c:570
> ksys_read+0xdc/0x1a0 fs/read_write.c:715
> __do_sys_read fs/read_write.c:724 [inline]
> __se_sys_read fs/read_write.c:722 [inline]
> __x64_sys_read+0x40/0x50 fs/read_write.c:722
> x64_sys_call+0x2889/0x3000 arch/x86/include/generated/asm/syscalls_64.h:1
> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> value changed: 0x00000002 -> 0x00000004
>
> Reported-by: syzbot+1b327485934adf39955b@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=1b327485934adf39955b
> Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
> ---
> drivers/input/evdev.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index 90ff6be85cf4..eebd59d190f5 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -569,9 +569,13 @@ static ssize_t evdev_read(struct file *file, char __user *buffer,
> if (!evdev->exist || client->revoked)
> return -ENODEV;
>
> + spin_lock_irq(&client->buffer_lock);
> if (client->packet_head == client->tail &&
> - (file->f_flags & O_NONBLOCK))
> + (file->f_flags & O_NONBLOCK)) {
> + spin_unlock_irq(&client->buffer_lock);
> return -EAGAIN;
> + }
> + spin_unlock_irq(&client->buffer_lock);
>
> /*
> * count == 0 is special - no IO is done but we check
> @@ -593,9 +597,12 @@ static ssize_t evdev_read(struct file *file, char __user *buffer,
> break;
>
> if (!(file->f_flags & O_NONBLOCK)) {
> - error = wait_event_interruptible(client->wait,
> + spin_lock_irq(&client->buffer_lock);
> + error = wait_event_interruptible_lock_irq(client->wait,
> client->packet_head != client->tail ||
> - !evdev->exist || client->revoked);
> + !evdev->exist || client->revoked,
> + client->buffer_lock);
> + spin_unlock_irq(&client->buffer_lock);
> if (error)
> return error;
> }
> @@ -610,6 +617,7 @@ static __poll_t evdev_poll(struct file *file, poll_table *wait)
> struct evdev_client *client = file->private_data;
> struct evdev *evdev = client->evdev;
> __poll_t mask;
> + bool have_data;
>
> poll_wait(file, &client->wait, wait);
>
> @@ -618,7 +626,11 @@ static __poll_t evdev_poll(struct file *file, poll_table *wait)
> else
> mask = EPOLLHUP | EPOLLERR;
>
> - if (client->packet_head != client->tail)
> + spin_lock_irq(&client->buffer_lock);
> + have_data = client->packet_head != client->tail;
> + spin_unlock_irq(&client->buffer_lock);
> +
> + if (have_data)
> mask |= EPOLLIN | EPOLLRDNORM;
>
> return mask;
> --
> 2.43.0
>
ping
^ permalink raw reply
* Re: [PATCH v5] hid/hid-multitouch: Keep latency normal on deactivate for reactivation gesture
From: Jiri Kosina @ 2026-02-26 15:10 UTC (permalink / raw)
To: Werner Sembach; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260108161139.32681-1-wse@tuxedocomputers.com>
On Thu, 8 Jan 2026, Werner Sembach wrote:
> Uniwill devices have a built in gesture in the touchpad to de- and
> reactivate it by double taping the upper left corner. This gesture stops
> working when latency is set to high, so this patch keeps the latency on
> normal.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> ---
> V1->V2: Use a quirk to narrow down the devices this is applied to.
> V2->V3: Fix this patch breaking touchpads on some devices.
> Add another device ID.
> V3->V4: Readd quirks formerly applied to the devices via the default class.
> V4->V5: Fix whitespace error.
Applied to hid.git#for-7.0/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/2] hid: hid-pl: eliminate private debug macro
From: Jiri Kosina @ 2026-02-26 15:07 UTC (permalink / raw)
To: Oliver Neukum; +Cc: bentiss, linux-input
In-Reply-To: <20260216134958.260648-3-oneukum@suse.com>
On Mon, 16 Feb 2026, Oliver Neukum wrote:
> Use proper dynamic debugging.
>
> V2: resend full series
>
> Signed-off-by: Oliver Neukum <oneukum@suse.com>
> ---
> drivers/hid/hid-pl.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hid/hid-pl.c b/drivers/hid/hid-pl.c
> index dc11d5322fc0..4b6b33597d11 100644
> --- a/drivers/hid/hid-pl.c
> +++ b/drivers/hid/hid-pl.c
> @@ -24,10 +24,6 @@
> */
>
>
> -/* #define DEBUG */
> -
> -#define debug(format, arg...) pr_debug("hid-plff: " format "\n" , ## arg)
> -
> #include <linux/input.h>
> #include <linux/slab.h>
> #include <linux/module.h>
> @@ -53,14 +49,14 @@ static int hid_plff_play(struct input_dev *dev, void *data,
>
> left = effect->u.rumble.strong_magnitude;
> right = effect->u.rumble.weak_magnitude;
> - debug("called with 0x%04x 0x%04x", left, right);
> + dev_dbg(&dev->dev, "called with 0x%04x 0x%04x", left, right);
Can you please use hid_dbg() instead?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCHv2 1/2] hid: hid-pl: handle probe errors
From: Jiri Kosina @ 2026-02-26 15:06 UTC (permalink / raw)
To: Oliver Neukum; +Cc: bentiss, linux-input, stable
In-Reply-To: <20260216134958.260648-2-oneukum@suse.com>
On Mon, 16 Feb 2026, Oliver Neukum wrote:
> Errors in init must be reported back or we'll
> follow a NULL pointer the first time FF is used,
> because plff_init() initializes the private member.
>
> V2: resend full series
This one is in Linus' tree as 3756a272d2cf3 already.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: apple: Add EPOMAKER TH87 to the non-apple keyboards list
From: Jiri Kosina @ 2026-02-26 15:01 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-input, Benjamin Tissoires, linux-kernel
In-Reply-To: <20260224090004.73980-1-tiwai@suse.de>
On Tue, 24 Feb 2026, Takashi Iwai wrote:
> EPOMAKER TH87 has the very same ID as Apple Aluminum keyboard
> (05ac:024f) although it doesn't work as expected in compatible way.
>
> Put three entries to the non-apple keyboards list to exclude this
> device: one for BT ("TH87"), one for USB ("HFD Epomaker TH87") and one
> for dongle ("2.4G Wireless Receiver").
Applied to hid.git#for-7.0/upstream-fixes, thanks Takashi.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH RESEND v2] HID: winwing: Enable rumble effects
From: Jiri Kosina @ 2026-02-26 14:58 UTC (permalink / raw)
To: Ivan Gorinov; +Cc: linux-input, linux-kernel
In-Reply-To: <20260226054913.GA8668@altimeter-info>
On Thu, 26 Feb 2026, Ivan Gorinov wrote:
> Enable rumble motor control on TGRIP-15E and TGRIP-15EX throttle grips
> by sending haptic feedback commands (EV_FF events) to the input device.
>
> Signed-off-by: Ivan Gorinov <linux-kernel@altimeter.info>
[ ... snip ... ]
> +static int winwing_haptic_rumble(struct winwing_drv_data *data)
> +{
> + __u8 *buf;
> + __u8 m;
> +
> + if (!data)
> + return -EINVAL;
> +
> + if (!data->hdev)
> + return -EINVAL;
> +
> + buf = data->report_rumble;
> +
> + if (!buf)
> + return -EINVAL;
> +
> + m = convert_magnitude(data->rumble.strong_magnitude);
> + if (m != data->rumble_left) {
> + int ret;
> +
> + buf[0] = 0x02;
> + buf[1] = 0x01;
> + buf[2] = 0xbf;
> + buf[3] = 0x00;
> + buf[4] = 0x00;
> + buf[5] = 0x03;
> + buf[6] = 0x49;
> + buf[7] = 0x00;
> + buf[8] = m;
> + buf[9] = 0x00;
> + buf[10] = 0;
> + buf[11] = 0;
> + buf[12] = 0;
> + buf[13] = 0;
> +
> + ret = hid_hw_output_report(data->hdev, buf, 14);
> + if (ret < 0) {
> + hid_err(data->hdev, "error %d (%*ph)\n", ret, 14, buf);
> + return ret;
> + }
> + data->rumble_left = m;
> + }
> +
> + m = convert_magnitude(data->rumble.weak_magnitude);
> + if (m != data->rumble_right) {
> + int ret;
> +
> + buf[0] = 0x02;
> + buf[1] = 0x03;
> + buf[2] = 0xbf;
> + buf[3] = 0x00;
> + buf[4] = 0x00;
> + buf[5] = 0x03;
> + buf[6] = 0x49;
> + buf[7] = 0x00;
> + buf[8] = m;
> + buf[9] = 0x00;
> + buf[10] = 0;
> + buf[11] = 0;
> + buf[12] = 0;
> + buf[13] = 0;
Do these magic numbers have any real meaning, or is it just mimicking
observed binary stream?
It'd be nice to have at least short comment explaining it.
Thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: ipc: Add Nova Lake-H/S PCI device IDs
From: Jiri Kosina @ 2026-02-26 14:54 UTC (permalink / raw)
To: Zhang Lixu
Cc: linux-input, srinivas.pandruvada, benjamin.tissoires,
andriy.shevchenko, selina.wang
In-Reply-To: <20260203005507.44430-1-lixu.zhang@intel.com>
On Tue, 3 Feb 2026, Zhang Lixu wrote:
> Add device IDs of Nova Lake-H and Nova Lake-S into ishtp support list.
>
> Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Now in hid.git#for-7.0/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH V3 RESEND 2/2] HID: i2c-hid: elan: Add parade-tc3408 timing
From: Jiri Kosina @ 2026-02-26 14:52 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Benjamin Tissoires, Doug Anderson, Langyan Ye, robh, krzk+dt,
conor+dt, linux-input, devicetree, linux-kernel
In-Reply-To: <aZ_SqXA8ad3SAD3J@google.com>
On Wed, 25 Feb 2026, Dmitry Torokhov wrote:
> > > > Parade-tc3408 requires reset to pull down time greater than 10ms,
> > > > so the configuration post_power_delay_ms is 10, and the chipset
> > > > initial time is required to be greater than 300ms,
> > > > so the post_gpio_reset_on_delay_ms is set to 300.
> > > >
> > > > Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
> > > > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > >
> > > Jiri, Benjamin, another I2C hid with bindings...
> >
> > I guess maybe this could go through the input tree, but it needs
> > either Jiri's or Benjamin's ack? Is that the plan?
>
> Jiri, Benjamin,
>
> I am going to pick up the DT binding changes, do you want me to pick up
> the driver changes as well or do you want to merge them through your
> tree?
I think it's easier if it goes all together to avoid cross-tree
dependencies.
Please feel free to add
Acked-by: Jiri Kosina <jkosina@suse.com>
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3 3/4] dt-bindings: input: add GPIO charlieplex keypad
From: Hugo Villeneuve @ 2026-02-26 14:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: robin, andy, 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: <CAMuHMdVdYX9p9DfDoyMv8qEm52kY51QULkEnuxRBH2OyWyYf6g@mail.gmail.com>
Hi Geert,
On Thu, 26 Feb 2026 10:32:30 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Hugo,
>
> On Wed, 25 Feb 2026 at 16:54, Hugo Villeneuve <hugo@hugovil.com> wrote:
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > Add DT bindings for GPIO charlieplex keypad.
> >
> > Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/gpio-charlieplex-keypad.yaml
> > @@ -0,0 +1,106 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +
> > +$id: http://devicetree.org/schemas/input/gpio-charlieplex-keypad.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: GPIO charlieplex keypad
> > +
> > +maintainers:
> > + - Hugo Villeneuve <hvilleneuve@dimonoff.com>
> > +
> > +description: |
> > + The charlieplex keypad supports N^2)-N different key combinations (where N is
> > + the number of lines). Key presses and releases are detected by configuring
> > + only one line as output at a time, and reading other line states. This process
> > + is repeated for each line. Diodes are required to ensure current flows in only
> > + one direction between any pair of pins.
> > + This mechanism doesn't allow to detect simultaneous key presses.
>
> Indeed, e.g. pressing S1 and S2 simultaneously will show a ghost
> S5 keypress.
>
> > +
> > + Wiring example for 3 lines keyboard with 6 switches and 3 diodes:
> > +
> > + L0 --+---------------------+----------------------+
> > + | | |
> > + L1 -------+-----------+---------------------+ |
> > + | | | | | |
> > + L2 -------------+----------------+-----+ | |
> > + | | | | | | | | |
> > + | | | | | | | | |
> > + | S1 \ S2 \ | S3 \ S4 \ | S5 \ S6 \
> > + | | | | | | | | |
> > + | +--+--+ | +--+--+ | +--+--+
> > + | | | | | |
> > + | D1 v | D2 v | D3 v
> > + | - (k) | - (k) | - (k)
> > + | | | | | |
> > + +-------+ +-------+ +-------+
>
> Don't you need pull-down resistors on L[0-2], and/or a way to specify
> in DT to enable internal poll-down on GPIO controllers that support it?
> Some controllers may support internal pull-up only, but I guess that
> can be handled using GPIO_ACTIVE_LOW?
Yes, I did not put any resistors in the diagram in order to keep it
simple and clear.
You need pull-down resistors either on the board, or specified in the
DT like we do for our board (we use the PCAL6416 with pull-up/down
support):
line-gpios = <&gpio20 0 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)
...
I will add this to the example, and add a few lines explaining this in
the description.
> > +
> > + L: GPIO line
> > + S: switch
> > + D: diode (k indicates cathode)
> > +
> > +allOf:
> > + - $ref: input.yaml#
> > + - $ref: /schemas/input/matrix-keymap.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: gpio-charlieplex-keypad
> > +
> > + autorepeat: true
> > +
> > + debounce-delay-ms:
> > + default: 5
> > +
> > + line-gpios:
> > + description:
> > + List of GPIOs used as lines. The gpio specifier for this property
> > + depends on the gpio controller to which these lines are connected.
> > +
> > + linux,keymap: true
> > +
> > + poll-interval: true
> > +
> > + settling-time-us: true
> > +
> > + wakeup-source: true
> > +
> > +required:
> > + - compatible
> > + - line-gpios
> > + - linux,keymap
> > + - poll-interval
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > + #include <dt-bindings/input/input.h>
> > +
> > + charlieplex-keypad {
>
> "keyboard", as per Devicetree Specification Generic Names
> Recommendation.
Ok.
Thank you,
Hugo.
>
> > + compatible = "gpio-charlieplex-keypad";
> > + debounce-delay-ms = <20>;
> > + poll-interval = <5>;
> > + settling-time-us = <2>;
> > +
> > + line-gpios = <&gpio2 25 GPIO_ACTIVE_HIGH
> > + &gpio2 26 GPIO_ACTIVE_HIGH
> > + &gpio2 27 GPIO_ACTIVE_HIGH>;
> > +
> > + /* MATRIX_KEY(output, input, key-code) */
> > + linux,keymap = <
> > + /*
> > + * According to wiring diagram above, if L1 is configured as
> > + * output and HIGH, and we detect a HIGH level on input L0,
> > + * then it means S1 is pressed: MATRIX_KEY(L1, L0, KEY...)
> > + */
> > + MATRIX_KEY(1, 0, KEY_F1) /* S1 */
> > + MATRIX_KEY(2, 0, KEY_F2) /* S2 */
> > + MATRIX_KEY(0, 1, KEY_F3) /* S3 */
> > + MATRIX_KEY(2, 1, KEY_F4) /* S4 */
> > + MATRIX_KEY(1, 2, KEY_F5) /* S5 */
> > + MATRIX_KEY(0, 2, KEY_F6) /* S6 */
> > + >;
> > + };
>
> 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
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH 0/5] hid-pidff set_condition compatibility fixes
From: Jiri Kosina @ 2026-02-26 14:46 UTC (permalink / raw)
To: Tomasz Pakuła; +Cc: bentiss, oleg, linux-input, linux-kernel
In-Reply-To: <20260203174531.2866644-1-tomasz.pakula.oficjalny@gmail.com>
On Tue, 3 Feb 2026, Tomasz Pakuła wrote:
> This patch series adds a few more quirks to the hid-pidff driver to allow for
> greater compatibility with HID PID devices in the wild. Some omit selected
> fields based on the permissiveness of the Windows driver/DirectInput.
>
> All the combined quirks allow for Conditional effects playback on affected
> devices simply by following DirectInput and skipping missing fields. This brings
> force feedback feeling in line with other platforms for affected devices.
>
> Last patch updates MAINTAINERS to officially take ownership of hid-pidff driver.
>
> Tomasz Pakuła (5):
> HID: pidff: Refactor field quirks detection
> HID: pidff: Add MISSING_NEG_COEFFICIENT quirk
> HID: pidff: Add MISSING_NEG_SATURATION quirk
> HID: pidff: Add MISSING_DEADBAND quirk
> HID: Update MAINTAINERS for USB HID PID
>
> MAINTAINERS | 17 +++++-----
> drivers/hid/usbhid/hid-pidff.c | 57 ++++++++++++++++++++++------------
> drivers/hid/usbhid/hid-pidff.h | 9 ++++++
> 3 files changed, 56 insertions(+), 27 deletions(-)
Now in hid.git#for-7.1/pidff. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3 0/4] input: add GPIO-based charlieplex keypad
From: Hugo Villeneuve @ 2026-02-26 14:27 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: robin, andy, 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: <CAMuHMdVd0Ds5vHQa+MG2E+E36qAu5HQE3b+Vzpbv84MM=2DFWw@mail.gmail.com>
Hi Geert,
On Thu, 26 Feb 2026 10:20:33 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Hugo,
>
> Thanks for your series!
>
> On Wed, 25 Feb 2026 at 16:54, Hugo Villeneuve <hugo@hugovil.com> wrote:
> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >
> > 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 PCA9416 I2C GPIO
>
> PCA9416? The closest I could find is TCA9416, which is something
> different.
Its a typo, it is PCA6416, thanks for catching that!
Hugo.
>
> > expander.
> >
> > Link: [v1] https://lore.kernel.org/all/20260203155023.536103-1-hugo@hugovil.com/
> > Link: [v2] https://lore.kernel.org/all/20260213171431.2228814-1-hugo@hugovil.com/
>
> 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
>
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement
From: Lee Jones @ 2026-02-26 14:08 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, David Rheinsberg, linux-input, linux-kernel, stable
In-Reply-To: <aaA6fioiB9_aiBrA@plouf>
On Thu, 26 Feb 2026, Benjamin Tissoires wrote:
> On Feb 26 2026, Lee Jones wrote:
> > On Tue, 24 Feb 2026, Jiri Kosina wrote:
> >
> > > On Tue, 24 Feb 2026, Benjamin Tissoires wrote:
> > >
> > > > Long story short: that patch is too intrusive as it makes assumption on
> > > > the behavior of the device. We need to understand where/if the bug was
> > > > spotted and fix the caller of hid_hw_raw_request, not the uhid
> > > > implementation.
> > >
> > > Thanks a lot for the analysis, Benjamin!
> > >
> > > I asked about that here:
> > >
> > > https://lore.kernel.org/all/172q4775-616s-p7s4-7n80-p8579n0r3516@xreary.bet/
> > >
> > > So let's wait for Lee to clarify. Until that, the patch stays out of the
> > > branch.
> >
> > Thanks to both of you for looking into this. I appreciate your efforts.
> >
> > This is very much real world.
> >
> > Is there a way to add an errata for the PS3 controller?
> >
>
> Unfortunatelly no. uhid merely emulates what a device can do, and HID is
> a convention. So if we were to have a special case to PS3 controllers,
> we would then start having to maintain an endless list of quirks when
> the issue is *not* in uhid, but in the processing of the device after
> (maybe in hid-core?).
Actually I think the issue is in UHID. At least the way I read it.
Are there legitimate use-cases for devices overwriting the Report ID
contained in the first index of the data buffer? From my very limited
knowledge of the subsystem, this sounds like an oversight.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 1/1] HID: uhid: Fix out-of-bounds write caused by raw events mismanagement
From: Benjamin Tissoires @ 2026-02-26 12:22 UTC (permalink / raw)
To: Lee Jones
Cc: Jiri Kosina, David Rheinsberg, linux-input, linux-kernel, stable
In-Reply-To: <20260226111816.GA8023@google.com>
On Feb 26 2026, Lee Jones wrote:
> On Tue, 24 Feb 2026, Jiri Kosina wrote:
>
> > On Tue, 24 Feb 2026, Benjamin Tissoires wrote:
> >
> > > Long story short: that patch is too intrusive as it makes assumption on
> > > the behavior of the device. We need to understand where/if the bug was
> > > spotted and fix the caller of hid_hw_raw_request, not the uhid
> > > implementation.
> >
> > Thanks a lot for the analysis, Benjamin!
> >
> > I asked about that here:
> >
> > https://lore.kernel.org/all/172q4775-616s-p7s4-7n80-p8579n0r3516@xreary.bet/
> >
> > So let's wait for Lee to clarify. Until that, the patch stays out of the
> > branch.
>
> Thanks to both of you for looking into this. I appreciate your efforts.
>
> This is very much real world.
>
> Is there a way to add an errata for the PS3 controller?
>
Unfortunatelly no. uhid merely emulates what a device can do, and HID is
a convention. So if we were to have a special case to PS3 controllers,
we would then start having to maintain an endless list of quirks when
the issue is *not* in uhid, but in the processing of the device after
(maybe in hid-core?).
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH v3 0/4] input: add GPIO-based charlieplex keypad
From: Geert Uytterhoeven @ 2026-02-26 9:20 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: robin, andy, 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: <20260225155409.612478-1-hugo@hugovil.com>
Hi Hugo,
Thanks for your series!
On Wed, 25 Feb 2026 at 16:54, Hugo Villeneuve <hugo@hugovil.com> wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> 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 PCA9416 I2C GPIO
PCA9416? The closest I could find is TCA9416, which is something
different.
> expander.
>
> Link: [v1] https://lore.kernel.org/all/20260203155023.536103-1-hugo@hugovil.com/
> Link: [v2] https://lore.kernel.org/all/20260213171431.2228814-1-hugo@hugovil.com/
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
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