* Re: [PATCH] amd-sfh-hid: tablet mode switch and asus quirk
From: Jiri Kosina @ 2026-05-12 16:06 UTC (permalink / raw)
To: Helge Bahmann
Cc: Nehal Bakulchandra Shah, Sandeep Singh, Basavaraj Natikar,
bentiss, linux-hid, linux-input
In-Reply-To: <6879487.lOV4Wx5bFT@lothlorien>
On Mon, 27 Apr 2026, Helge Bahmann wrote:
> Add an input driver that interprets the "operation mode" sensor offered
> by the amd sfh on some laptop models.
>
> Add a quirk to make the driver work again with the Asus VivoBook
> VivoBook (turn off the "disable interrupts" flag).
>
> Expose the intr_disable flag as a module parameter in case it turns out
> to be needed on further laptop models.
>
> Signed-off-by: Helge Bahmann <hcb@chaoticmind.net>
Basavaraj, can you please review this one?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3 0/4] HID: Proper fix for OOM in hid-core
From: Jiri Kosina @ 2026-05-12 16:04 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Filipe Laíns, Bastien Nocera, Ping Cheng, Jason Gerecke,
Viresh Kumar, Johan Hovold, Alex Elder, Greg Kroah-Hartman,
Lee Jones, Icenowy Zheng, linux-input, linux-kernel, greybus-dev,
linux-staging, linux-usb, stable
In-Reply-To: <20260504-wip-fix-core-v3-0-ce1f11f4968f@kernel.org>
On Mon, 4 May 2026, Benjamin Tissoires wrote:
> Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()") enforced the provided data to be at least the size of
> the declared buffer in the report descriptor to prevent a buffer
> overflow.
>
> We only had corner cases of malicious devices exposing the OOM because
> in most cases, the buffer provided by the transport layer needs to be
> allocated at probe time and is large enough to handle all the possible
> reports.
>
> However, the patch from above, which enforces the spec a little bit more
> introduced both regressions for devices not following the spec (not
> necesserally malicious), but also a stream of errors for those devices.
>
> Let's revert to the old behavior by giving more information to HID core
> to be able to decide whether it can or not memset the rest of the buffer
> to 0 and continue the processing.
>
> Note that the first commit makes an API change, but the callers are
> relatively limited, so it should be fine on its own. The second patch
> can't really make the same kind of API change because we have too many
> callers in various subsystems. We can switch them one by one to the safe
> approach when needed.
>
> The last 2 patches are small cleanups I initially put together with the
> 2 first patches, but they can be applied on their own and don't need to
> be pulled in stable like the first 2.
>
> Cheers,
> Benjamin
>
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
I have now queued the first two in hid.git#for-7.1/upstream-fixes.
I expect the remaining two will be applied once respun with Dmitry's
suggestion on proper guarding.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: google: hammer: stop hardware on devres action failure
From: Jiri Kosina @ 2026-05-12 16:01 UTC (permalink / raw)
To: 박명훈; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260424125043.52639-1-pakmyeonghun@bagmyeonghun-ui-MacBookPro.local>
On Fri, 24 Apr 2026, 박명훈 wrote:
> From: Myeonghun Pak <mhun512@gmail.com>
>
> hammer_probe() starts the HID hardware before registering the devres
> action that stops it. If devm_add_action() fails, probe returns an
> error with the hardware still started because the cleanup action was
> never registered and the driver's remove callback is not called after a
> failed probe.
>
> Use devm_add_action_or_reset() so the stop action runs immediately on
> registration failure while preserving the existing devres-managed cleanup
> path for later probe failures and remove.
>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> ---
> drivers/hid/hid-google-hammer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
> index 1af477e584..c99c3c0d44 100644
> --- a/drivers/hid/hid-google-hammer.c
> +++ b/drivers/hid/hid-google-hammer.c
> @@ -496,7 +496,7 @@ static int hammer_probe(struct hid_device *hdev,
> if (error)
> return error;
>
> - error = devm_add_action(&hdev->dev, hammer_stop, hdev);
> + error = devm_add_action_or_reset(&hdev->dev, hammer_stop, hdev);
Makes sense, thanks for catching it. Applied.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/2] HID: appletb-kbd: fix UAF and mutex-in-atomic in inactivity timer
From: Jiri Kosina @ 2026-05-12 15:57 UTC (permalink / raw)
To: Sangyun Kim; +Cc: bentiss, qasdev00, gargaditya08, linux-input, linux-kernel
In-Reply-To: <20260420051318.1411671-1-sangyun.kim@snu.ac.kr>
On Mon, 20 Apr 2026, Sangyun Kim wrote:
> This series addresses two defects in hid-appletb-kbd's inactivity
> timer subsystem. The two patches target different bugs and are
> logically independent; they are sent together because they touch the
> same tear-down code and because the same maintainer will review both.
>
> Patch 1 fixes a slab use-after-free with two related tear-down windows
> introduced by commit 38224c472a03 ("HID: appletb-kbd: fix slab
> use-after-free bug in appletb_kbd_probe"):
>
> A) Within "if (kbd->backlight_dev)" the order was
> put_device() then timer_delete_sync(). A concurrent
> hid_appletb_bl unbind between those two calls can drop the last
> devm reference and free the backlight_device; the still-armed
> inactivity timer softirq then dereferences the freed object
> through backlight_device_set_brightness() -> mutex_lock(&ops_lock).
>
> B) The "if (kbd->backlight_dev)" block ran before
> hid_hw_close()/hid_hw_stop(), so even after window A is closed a
> late ".event" callback from the HID core (USB URB completion on
> real hardware) can arrive between timer_delete_sync() and
> put_device(), reach reset_inactivity_timer(), re-arm the timer
> via mod_timer(), and reopen the same UAF.
>
> Both windows produce the same KASAN slab-use-after-free on the object
> allocated by devm_backlight_device_register(). Patch 1 closes them
> together by moving hid_hw_close()/hid_hw_stop() before the backlight
> cleanup and, inside that cleanup block, calling timer_delete_sync()
> before put_device(). Shipping both as one commit avoids leaving
> stable kernels in a half-fixed state where only window A is closed.
>
> Patch 2 fixes a separate "sleeping function called from invalid
> context" bug in the same subsystem. The inactivity timer is a
> struct timer_list, so the callback runs in softirq context and calls
> backlight_device_set_brightness() -> mutex_lock() from atomic
> context; reset_inactivity_timer() has the same issue on the
> brightness-restore path (it is called from appletb_kbd_hid_event()
> and appletb_kbd_inp_event(), which run in softirq/IRQ context on
> real USB hardware). Convert the inactivity timer to a delayed_work
> and defer the brightness-restore call to a dedicated work_struct so
> both sleeping calls run in process context.
>
> Sangyun Kim (2):
> HID: appletb-kbd: fix UAF in inactivity-timer cleanup path
> HID: appletb-kbd: run inactivity autodim from workqueues
Both applied to hid.git#for-7.1/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 0/5] Add OneXPlayer Configuration HID Driver
From: Jiri Kosina @ 2026-05-12 15:56 UTC (permalink / raw)
To: Derek J. Clark
Cc: Benjamin Tissoires, Pierre-Loup A . Griffais, Lambert Fan,
Zhouwang Huang, linux-input, linux-doc, linux-kernel
In-Reply-To: <20260419042624.625746-1-derekjohn.clark@gmail.com>
On Sat, 18 Apr 2026, Derek J. Clark wrote:
> Adds an HID driver for OneXPlayer HID configuration devices. There are
> currently 2 generations of OneXPlayer HID protocol. The first (OneXPlayer
> F1 series) only provides an RGB control interface over HID. The Second
> (X1 mini series, G1 series, AOKZOE A1X) also includes a hardware level
> button mapping interface, vibration intensity settings, and the ability
> to switch output between xinput and a debug mode that can be used to debug
> the button mapping. Some devices (G1 Series, APEX) use a hybrid of Gen1
> RGB control and Gen 2 controller settings. To ensure there is no conflicts
> when the driver is loaded, we skip creating the RGB interface for Gen 2
> devices if there is a DMI match.
>
> I'll also add a note that Gen 1 devices also have an interface for
> setting the key map and debug mode, but that is done entirely over a
> serial TTY device so it is not able to be added to this driver. There
> are also some "Gen 0" devices (OneXPlayer 2 Series) also use it, but
> the TTY interface also handles the RGB control so no support is
> provided by this driver for those interfaces.
>
> Signed-off-by: Derel J. Clark <derekjohn.clark@gmail.com>
> ---
> v4:
> - Make all delayed work part of drvdata & ensure they are canceled
> during remove.
>
> v3: https://lore.kernel.org/linux-input/20260412213444.2231505-1-derekjohn.clark@gmail.com/
> - Ensure default button map is properly init during probe.
>
> v2: https://lore.kernel.org/linux-input/20260407041354.2283201-1-derekjohn.clark@gmail.com/
> - Add DMI quirks for certain devices that ship with both GEN1 and GEN2
> MCU to avoid clashing when initializing the RGB interface.
> - Add left & right vibration intensity attributes.
> - Add additional mappings for keyboard inputs.
> - Add a delayed work trigger to re-apply settings after the MCU
> completes initializing after a suspend/resume cycle.
>
> v1: https://lore.kernel.org/linux-input/20260322031615.1524307-1-derekjohn.clark@gmail.com/
Now in hid.git#for-7.2/oxp, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: playstation: Clamp num_touch_reports
From: Jiri Kosina @ 2026-05-12 15:55 UTC (permalink / raw)
To: T.J. Mercier
Cc: roderick.colenbrander, linux-input, Benjamin Tissoires, stable,
Xingyu Jin, Roderick Colenbrander, linux-kernel
In-Reply-To: <20260417154704.1186803-1-tjmercier@google.com>
On Fri, 17 Apr 2026, T.J. Mercier wrote:
> A device would never lie about the number of touch reports would it?
>
> If it does the loop in dualshock4_parse_report will read off the end of
> the touch_reports array, up to about 2 KiB for the maximum number of 256
> loop iteraions. The data that is read is emitted via evdev if the
> DS4_TOUCH_POINT_INACTIVE bit happens to be set. Protect against this by
> clamping the num_touch_reports value provided by the device to the
> maximum size of the touch_reports array.
>
> Fixes: 752038248808 ("HID: playstation: add DualShock4 touchpad support.")
> Cc: stable@vger.kernel.org
> Reported-by: Xingyu Jin <xingyuj@google.com>
> Signed-off-by: T.J. Mercier <tjmercier@google.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v6] HID: magicmouse: add battery reporting for Magic Trackpad v1
From: Jiri Kosina @ 2026-05-12 15:53 UTC (permalink / raw)
To: Damiano Gragnaniello; +Cc: benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <20260416143323.418078-1-damianogragnaniello@gmail.com>
On Thu, 16 Apr 2026, Damiano Gragnaniello wrote:
[ ... snip ... ]
>
> - /* If there is only one "firm" touch, set touch to its
> - * tracking ID.
> - */
[ ... snip ... ]
> - /* If some button was pressed before, keep it held
> - * down. Otherwise, if there's exactly one firm
> - * touch, use that to override the mouse's guess.
> - */
[ ... snip ... ]
> - /* If requested, emulate a scroll wheel by detecting small
> - * vertical touch motions.
> - */
> - if (emulate_scroll_wheel && (input->id.product !=
> - USB_DEVICE_ID_APPLE_MAGICTRACKPAD2)) {
[ ... snip ... ]
> - /* Reset acceleration after half a second. */
[ ... snip ... ]
> - /* Generate the input events for this touch. */
[ ... snip ... ]
> - /* Expect four bytes of prefix, and N*9 bytes of touch data. */
[ ... snip ... ]
> - /* The following bits provide a device specific timestamp. They
> - * are unused here.
> - *
> - * ts = data[1] >> 6 | data[2] << 2 | data[3] << 10;
> - */
[ ... snip ... ]
> - /* Expect twelve bytes of prefix and N*9 bytes of touch data. */
[ ... snip ... ]
Why are you removing all those comments? (and quite some more).
I don't think your patch changes any of this.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 1/1] HID: magicmouse: Prevent out-of-bounds (OOB) read during DOUBLE_REPORT_ID
From: Jiri Kosina @ 2026-05-12 15:49 UTC (permalink / raw)
To: Lee Jones; +Cc: Benjamin Tissoires, linux-input, linux-kernel, gnoack
In-Reply-To: <20260416131655.2279756-1-lee@kernel.org>
On Thu, 16 Apr 2026, Lee Jones wrote:
> It is currently possible for a malicious or misconfigured USB device to
> cause an out-of-bounds (OOB) read when submitting reports using
> DOUBLE_REPORT_ID by specifying a large report length and providing a
> smaller one.
>
> Let's prevent that by comparing the specified report length with the
> actual size of the data read in from userspace. If the actual data
> length ends up being smaller than specified, we'll politely warn the
> user and prevent any further processing.
>
> Signed-off-by: Lee Jones <lee@kernel.org>
> ---
> v1 => v2: Add more size checks to protect against issues during recursion
Applied, sorry for the delay.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: mcp2221: fix OOB write in mcp2221_raw_event()
From: Jiri Kosina @ 2026-05-12 15:48 UTC (permalink / raw)
To: Florian Pradines; +Cc: gupt21, bentiss, linux-i2c, linux-input
In-Reply-To: <20260509094517.2691246-1-florian.pradines@gmail.com>
On Sat, 9 May 2026, Florian Pradines wrote:
> mcp2221_raw_event() copies device-supplied data into mcp->rxbuf at
> offset rxbuf_idx without checking that the copy fits within the
> destination buffer. A device responding with up to 60 bytes to a
> small I2C/SMBus read can overflow the buffer.
>
> Add a rxbuf_size field to struct mcp2221, set it alongside rxbuf in
> mcp_i2c_smbus_read(), and check rxbuf_idx + data[3] <= rxbuf_size
> before the memcpy.
>
> Signed-off-by: Florian Pradines <florian.pradines@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: mcp2221: Fix heap buffer overflow in mcp2221_raw_event()
From: Jiri Kosina @ 2026-05-12 15:47 UTC (permalink / raw)
To: Benoit Sevens
Cc: Rishi Gupta, Benjamin Tissoires, linux-i2c, linux-input,
linux-kernel
In-Reply-To: <20260415114752.1181079-1-bsevens@google.com>
On Wed, 15 Apr 2026, Benoit Sevens wrote:
> From: Benoît Sevens <bsevens@google.com>
>
> A heap buffer overflow can occur in the mcp2221_raw_event() function
> when handling I2C read responses. The driver failed to check if the
> total incoming data length fits within the originally allocated buffer
> `mcp->rxbuf`.
>
> Fix this by introducing `rxbuf_len` to `struct mcp2221` to keep track
> of the allocated buffer size. Initialize it in `mcp_i2c_smbus_read()`
> and `mcp_smbus_xfer()`, and ensure the copied data length combined with
> the current index does not exceed this length in `mcp2221_raw_event()`.
>
> Signed-off-by: Benoît Sevens <bsevens@google.com>
Unfortunately the patch seems to have been somehow mangled by your mail
client:
patching file drivers/hid/hid-mcp2221.c
Hunk #1 succeeded at 126 (offset 7 lines).
Hunk #2 FAILED at 324.
patch: **** malformed patch at line 173: u16 addr,
Fix for the same issue has later been submitted by Florian Pradines [1],
so I will be taking that one and adding you as Reported-by: or so, ok?
Thanks.
[1] https://lore.kernel.org/all/20260509094517.2691246-1-florian.pradines@gmail.com/
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 0/3] HID: nintendo: Add preliminary Switch 2 controller driver
From: Jiri Kosina @ 2026-05-12 15:43 UTC (permalink / raw)
To: Vicki Pfau; +Cc: Dmitry Torokhov, Benjamin Tissoires, linux-input
In-Reply-To: <20260415073142.1303505-1-vi@endrift.com>
On Wed, 15 Apr 2026, Vicki Pfau wrote:
> This series adds preliminary support for Switch 2 controllers using the
> same split-driver model as previous versions. This is a minor iteration on
> v3 (which was erroneously submitted as v2 again), fixing an issue where we
> checked for NULL instead of handling an ERR_PTR, as well as a few typo
> fixes.
>
> Vicki Pfau (3):
> HID: nintendo: Add preliminary Switch 2 controller driver
> HID: nintendo: Add rumble support for Switch 2 controllers
> HID: nintendo: Add unified report format support
Vicki,
are you planning v5 with Silvan's comment addressed, please?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: multitouch: Fix Yoga Book 9 14IAH10 touchscreen misclassification
From: Jiri Kosina @ 2026-05-12 15:39 UTC (permalink / raw)
To: Dave Carey; +Cc: linux-input, bentiss
In-Reply-To: <20260413125803.46792-1-carvsdriver@gmail.com>
On Mon, 13 Apr 2026, Dave Carey wrote:
> The Lenovo Yoga Book 9 14IAH10 (83KJ) (17EF:6161) firmware includes a
> HID_DG_TOUCHPAD application collection designed for the Windows inbox HID
> driver's Win8 PTP touchpad mode. On Linux the HID_DG_TOUCHSCREEN
> collections provide the correct direct-touch interface. The presence of
> the touchpad collection causes hid-multitouch to misclassify the
> touchscreen nodes as indirect buttonpads, leaving them non-functional.
>
> Within the touchpad collection:
> - HID_UP_BUTTON usages trigger the touchscreen-with-buttons heuristic
> that sets INPUT_MT_POINTER on the touchscreen applications.
> - The HID_DG_TOUCHPAD application itself sets INPUT_MT_POINTER via
> mt_allocate_application(), propagating to all touchscreen nodes.
> - A HID_DG_BUTTONTYPE feature (report 0x51) returns MT_BUTTONTYPE_CLICKPAD,
> setting td->is_buttonpad = true for the entire device.
>
> Additionally, the firmware resets if any USB control request arrives while
> the CDC-ACM interface is initialising (~1.18 s after enumeration).
> The Win8 compliance blob (0xff00:0xc5) and Contact Count Max feature
> reports in the touchscreen collections trigger GET_REPORT calls at probe
> that hit this window. Surface Switch (0x57) and Button Switch (0x58)
> feature reports are sent by mt_set_modes() on every input-device open and
> close, repeatedly hitting this window throughout device lifetime.
>
> The firmware also leaves a persistent ghost contact in its contact buffer
> (contact ID 2, fixed coordinates, tip always asserted) on every enumeration.
> This ghost occupies a multitouch slot and prevents KWin from seeing a clean
> finger-lift, causing stuck touch state. The ghost is cleared when Input
> Mode is set via HID_REQ_SET_REPORT at probe.
Oh man, what a device.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3] HID: pulsar: add driver for Pulsar gaming mice
From: Jiri Kosina @ 2026-05-12 15:37 UTC (permalink / raw)
To: Nikolas Koesling
Cc: Benjamin Tissoires, Lode Willems, linux-input, linux-kernel, Leo
In-Reply-To: <20260412075346.100567-1-nikolas@koesling.info>
On Sun, 12 Apr 2026, Nikolas Koesling wrote:
> Add a HID driver for Pulsar wireless gaming mice (X2 V2, X2H, X2A,
> Xlite V3). The driver exposes battery level, voltage, and charging
> status through the power supply framework. It supports wired, 1kHz,
> and 4kHz wireless dongle connections.
>
> The driver also supports Kysona M600 ATK, VXE R1 SE+ and
> VXE Dragonfly R1 Pro, which use the same protocol for reading
> battery status and availability.
>
> The protocol used by this driver is based on findings from
> python-pulsar-mouse-tool by Andrew Rabert (MIT License):
> https://github.com/andrewrabert/python-pulsar-mouse-tool
>
> ATK vendor and device IDs were provided by Leo <leo@managarm.org>.
> VXE and Kysona vendor and device IDS are from hid-kysona.c by
> Lode Willems <me@lodewillems.com>
>
> Tested-by: Leo <leo@managarm.org>
> Signed-off-by: Nikolas Koesling <nikolas@koesling.info>
> ---
> Changes in v2:
> - Add support for Kysona M600, ATK VXE R1 SE+, and VXE Dragonfly R1 Pro
> - Add device type enum to distinguish vendors and generate proper
> battery names per vendor/model
> - Add mutual exclusion with HID_KYSONA in Kconfig
> - Add ATK and VXE vendor/device IDs to hid-ids.h
> - Refactor model name generation: extract model_pulsar() and add
> model_atk() for vendor-specific battery naming
> - Fall back to hdev->name for battery model when device info read
> fails on non-Pulsar devices (downgrade error to debug log)
> - Remove POWER_SUPPLY_PROP_MANUFACTURER property
> - Pass device type via driver_data in hid_device_id table
>
> Changes in v3:
> - Increase size of battery model name to hid device name size
> ---
> MAINTAINERS | 6 +
> drivers/hid/Kconfig | 15 +
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-ids.h | 15 +
> drivers/hid/hid-pulsar.c | 754 +++++++++++++++++++++++++++++++++++++++
> 5 files changed, 791 insertions(+)
> create mode 100644 drivers/hid/hid-pulsar.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c3fe46d7c4bc..207216632918 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11352,6 +11352,12 @@ L: linux-input@vger.kernel.org
> S: Supported
> F: drivers/hid/hid-playstation.c
>
> +HID PULSAR DRIVER
> +M: Nikolas Koesling <nikolas@koesling.info>
> +L: linux-input@vger.kernel.org
> +S: Maintained
> +F: drivers/hid/hid-pulsar.c
> +
> HID SENSOR HUB DRIVERS
> M: Jiri Kosina <jikos@kernel.org>
> M: Jonathan Cameron <jic23@kernel.org>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index c1d9f7c6a5f2..333d165554ee 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -511,12 +511,15 @@ config HID_KYE
> config HID_KYSONA
> tristate "Kysona devices"
> depends on USB_HID
> + depends on !HID_PULSAR
> help
> Support for Kysona mice.
>
> Say Y here if you have a Kysona M600 mouse
> and want to be able to read its battery capacity.
>
> + Note: The Kysona M600 is also supported by HID_PULSAR.
> +
I guess that we want to just ditch that driver altogether then?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: magicmouse: enable battery polling for 2024 Magic Trackpad
From: Jiri Kosina @ 2026-05-12 15:36 UTC (permalink / raw)
To: Dmitri Ollari; +Cc: linux-input
In-Reply-To: <20260411163806.35759-1-dmitri.ollari@protonmail.com>
On Sat, 11 Apr 2026, Dmitri Ollari wrote:
> The 2024 Magic Trackpad USB-C (PID 0x0324) does not report battery
> strength via HID descriptor fields over Bluetooth. Instead it requires
> an explicit HID_REQ_GET_REPORT request to retrieve the battery level.
>
> This patch makes the following changes:
>
> 1. Replace the battery_timer (timer_list) with battery_work (delayed_work)
> so that HID_REQ_GET_REPORT can be issued from a sleepable context.
> Timers run in atomic context and cannot block, which caused deadlocks
> on the Bluetooth transport path.
>
> 2. Extend the fetch guard and probe scheduling block to include the 2024
> Magic Trackpad USB-C when connected over Bluetooth (vendor 0x004C,
> product 0x0324 via BT_VENDOR_ID_APPLE).
>
> 3. Schedule battery_work immediately at probe (delay=0) instead of
> issuing a direct magicmouse_fetch_battery() call. The direct call
> bypassed the cold-start correction logic and could publish a stale
> value before the work handler had a chance to validate it.
>
> 4. Add a cold-start
> double-poll: the device may return a stale battery
> value (e.g. 4%) on the very first GET_REPORT after power-on. On the
> first successful poll battery_validated is set and a second poll is
> scheduled 3 seconds later to obtain the real value. Subsequent polls
> use the normal 60-second interval.
>
> 5. Remove the early-return guard that skipped polling when
> battery_capacity equalled battery_max. This prevented the second
> corrective poll from firing when the first stale response happened
> to equal 100.
>
> Signed-off-by: Dmitri Ollari <dmitri.ollari@protonmail.com>
Dmitri,
thanks for the patch.
It has however been badly line-wrapped and whitespace-damaged by your mail
client.
Can you please look into fixing it and resubmit?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: sony: use input_dev from sc struct in sony_init_ff()
From: Jiri Kosina @ 2026-05-12 15:34 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260411155347.101760-2-rosalie@mailbox.org>
On Sat, 11 Apr 2026, Rosalie Wanders wrote:
> This commit makes sony_init_ff() use the input_dev from the sc struct,
> this simplifies the sony_init_ff() function.
>
> Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Applied, thank you.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: usbhid: replace strlcat with better alternatives
From: Jiri Kosina @ 2026-05-12 15:33 UTC (permalink / raw)
To: Mahad Ibrahim
Cc: Benjamin Tissoires, linux-usb, linux-input, linux-hardening,
linux-kernel-mentees, Shuah Khan, linux-kernel
In-Reply-To: <20260410192447.7059-1-mahad.ibrahim.dev@gmail.com>
On Fri, 10 Apr 2026, Mahad Ibrahim wrote:
> In preparation for the removal of the strlcat() API as per the KSPP,
> replace the string concatenation logic in hid-core, usbkbd, and
> usbmouse with struct seq_buf, which tracks the current write position
> and remaining space internally. The changes implemented include:
>
> - Replace device name and phys concatenation with seq_buf_puts().
> - Include Struct seq_buf and its initialization.
> - Include header file of seq_buf.
> - Replace strlen() with seq_buf_used() on the string buffer which was
> tracked by seq_buf to increase speed.
> - Add size_t len in files which did not have it.
> - Use of strscpy with length in place of strlcat.
>
> Testing: This driver was compiled as a module as well as in-built in
> QEMU with the QEMU basic mouse, and QEMU basic keyboard. The testing was
> done in the following steps.
> - Add Hardware Mouse in QEMU checking the usbhid module.
> - Verify dmesg string name of mouse.
> - Blacklist hidusb module from auto-loading, and removing the module via
> rmmod.
> - Load usbmouse module, and reattach QEMU mouse.
> - Verify dmesg string name of mouse.
> - Repeat same procedure on usbkbd module.
>
> This aligns the driver with KSPP security guidelines.
>
> Link: https://github.com/KSPP/linux/issues/370
>
> Signed-off-by: Mahad Ibrahim <mahad.ibrahim.dev@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: playstation: Add DualSense Edge extra button support
From: Jiri Kosina @ 2026-05-12 15:30 UTC (permalink / raw)
To: Aaron Webster
Cc: Roderick Colenbrander, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20260407044008.40222-1-awebster@gmail.com>
On Mon, 6 Apr 2026, Aaron Webster wrote:
> The DualSense Edge controller (product ID 0x0df2) has four additional
> buttons compared to the standard DualSense: two front function buttons
> (Fn1 and Fn2) and two rear paddles (left and right). These are reported
> in bits 4-7 of buttons[2] in the input report.
>
> Map them to BTN_TRIGGER_HAPPY1 through BTN_TRIGGER_HAPPY4 so that
> userspace applications can use these extra inputs. An is_edge flag
> gates the extra button handling based on the product ID.
>
> Signed-off-by: Aaron Webster <awebster@gmail.com>
> ---
> Tested with a DualSense Edge controller (Hardware: 1000208, Firmware:
> 1000087 type 3, Fw version: 20 131082 6, Sw series: 68, Update version:
> 0213, build date Jul 4 2025) on Debian 13 (trixie) with kernel
> 6.12.74+deb13+1-amd64 (x86_64) via Bluetooth.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: rakk: add support for Rakk Dasig X side buttons
From: Jiri Kosina @ 2026-05-12 15:29 UTC (permalink / raw)
To: Karl Cayme; +Cc: bentiss, linux-input, linux-kernel, linuxhid
In-Reply-To: <20260321124759.608492-1-kcayme@gmail.com>
On Sat, 21 Mar 2026, Karl Cayme wrote:
> The Rakk Dasig X gaming mouse has a faulty HID report descriptor that
> declares USAGE_MAXIMUM=3 (buttons 1-3) while actually sending 5 button
> bits (REPORT_COUNT=5). This causes the kernel to ignore side buttons
> (buttons 4 and 5).
>
> Fix by patching the descriptor to set USAGE_MAXIMUM=5 in the
> report_fixup callback.
>
> The mouse uses Telink vendor ID 0x248a with three product IDs for USB
> direct (0xfb01), wireless dongle (0xfa02), and Bluetooth (0x8266)
> connection modes. All three variants have the same bug at byte offset 17.
>
> Suggested-by: Terry Junge <linuxhid@cosmicgizmosystems.com>
> Signed-off-by: Karl Cayme <kcayme@gmail.com>
> ---
> Hi,
>
> Thanks for the feedback. I updated the patch with your suggestion to
> check PIDs.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH] HID: iota-ups: add driver for LattePanda IOTA UPS
From: Jiri Kosina @ 2026-05-12 15:27 UTC (permalink / raw)
To: Andrew Maney; +Cc: linux-input, benjamin.tissoires
In-Reply-To: <20260316072034.56694-1-andrewmaney05@gmail.com>
On Mon, 16 Mar 2026, Andrew Maney wrote:
> This driver exposes the DFRobot LattePanda IOTA UPS board as a standard
> power_supply device, allowing desktop environments and power management
> tools such as UPower and systemd-logind to display battery status,
> remaining capacity, and charging status without any special
> configuration. It also enables automatic suspend or shutdown on low
> battery and power profile configuration via any tool that supports the
> standard power_supply interface.
>
> The UPS presents itself as an Arduino Leonardo HID device running custom
> firmware (VID 0x2341, PID 0x8036). It reports status and capacity via
> HID reports 0x07 and 0x0C respectively.
>
> The charge limit (80% or 100%) is configured via a physical DIP switch
> on the UPS board and cannot be detected automatically. Userspace can
> inform the driver of the configured limit via
> charge_control_end_threshold.
>
> Known issue: the driver occasionally reports 0% capacity briefly on
> initial load before the first valid HID report is received. I am
> investigating the cause.
>
> Signed-off-by: Andrew Maney <andrewmaney05@gmail.com>
> ---
> iota-ups.c | 355 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 355 insertions(+)
> create mode 100644 iota-ups.c
>
> diff --git a/iota-ups.c b/iota-ups.c
> new file mode 100644
> index 0000000..df334b2
> --- /dev/null
> +++ b/iota-ups.c
You seem to have generated this patch in a strange way, so that it can't
be applied on top of the tree (i.e. in a standard 'patch -p1' way that
all the tools default to).
Could you please re-generate it properly and resend?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: quirks: really enable the intended work around for appledisplay
From: Jiri Kosina @ 2026-05-12 15:24 UTC (permalink / raw)
To: Lukas Bulwahn
Cc: Benjamin Tissoires, René Rebe, linux-input, kernel-janitors,
linux-kernel, Lukas Bulwahn
In-Reply-To: <20260205081131.426899-1-lukas.bulwahn@redhat.com>
On Thu, 5 Feb 2026, Lukas Bulwahn wrote:
> From: Lukas Bulwahn <lukas.bulwahn@redhat.com>
>
> 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>
Applied, thanks Lukas.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [RFC] hid: hid-sjoy: race between init and usage
From: Jiri Kosina @ 2026-05-12 15:23 UTC (permalink / raw)
To: Oliver Neukum; +Cc: bentiss, jussi.kivilinna, linux-input
In-Reply-To: <20260303094906.1214359-1-oneukum@suse.com>
On Tue, 3 Mar 2026, Oliver Neukum wrote:
> The driver uses an initial IO to set the device to a default
> state. That initialization is currently being done after the device
> node has been created. That means that the single buffer used
> for output can be altered while IO is in progress.
> Move the intialization before announcement to user space.
>
> Fixes: fac733f029251 ("HID: force feedback support for SmartJoy PLUS PS2/USB adapter")
> Signed-off-by: Oliver Neukum <oneukum@suse.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3 0/6] iio: hid-sensor: standardize scan_type initialization
From: Jonathan Cameron @ 2026-05-12 14:48 UTC (permalink / raw)
To: Natália Salvino André
Cc: andy, dlechner, jikos, nuno.sa, srinivas.pandruvada, linux-iio,
linux-input, Zhang, Lixu
In-Reply-To: <20260512012302.20883-1-natalia.andre@ime.usp.br>
On Mon, 11 May 2026 22:16:16 -0300
Natália Salvino André <natalia.andre@ime.usp.br> wrote:
> This series refactors the HID sensor drivers to standardize the
> initialization of the iio_chan_spec scan_type structure.
> Direct initialization using compound literals was used.
>
> This change improves code readability and ensures that all fields
> of the scan_type structure are properly zero-initialized.
> Additionally, for the hid-sensor-accel-3d driver, the channel
> initialization loop was refactored to iterate directly over the
> scan indices, eliminating redundant logic.
Series looks good to me but I'll leave it on the list a while to
both let sashiko catch up and anyone else who wants to can have time
to look. Also ideally get some testing.
Lixu, if you don't mind, please can you give this a test on top
of the more radical refactor patches?
To me it looks safe enough but this is the sort of series that subtle
typos can hide in!
Thanks,
Jonathan
>
> Natália Salvino André (6):
> iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
> iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
> iio: light: HID: hid-sensor-als: Refactor channel initialization
> iio: light: HID: hid-sensor-prox: Refactor channel initialization
> iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel
> initialization
> iio: pressure: HID: hid-sensor-press: Refactor channel initialization
>
> drivers/iio/accel/hid-sensor-accel-3d.c | 27 +++++++------------
> drivers/iio/gyro/hid-sensor-gyro-3d.c | 24 +++++++----------
> drivers/iio/light/hid-sensor-als.c | 18 +++++--------
> drivers/iio/light/hid-sensor-prox.c | 19 +++++--------
> drivers/iio/magnetometer/hid-sensor-magn-3d.c | 20 +++++---------
> drivers/iio/pressure/hid-sensor-press.c | 19 +++++--------
> 6 files changed, 42 insertions(+), 85 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v3 0/6] iio: hid-sensor: standardize scan_type initialization
From: Jonathan Cameron @ 2026-05-12 14:42 UTC (permalink / raw)
To: Natália Salvino André
Cc: andy, dlechner, jikos, nuno.sa, srinivas.pandruvada, linux-iio,
linux-input
In-Reply-To: <20260512012302.20883-1-natalia.andre@ime.usp.br>
On Mon, 11 May 2026 22:16:16 -0300
Natália Salvino André <natalia.andre@ime.usp.br> wrote:
> This series refactors the HID sensor drivers to standardize the
> initialization of the iio_chan_spec scan_type structure.
> Direct initialization using compound literals was used.
>
> This change improves code readability and ensures that all fields
> of the scan_type structure are properly zero-initialized.
> Additionally, for the hid-sensor-accel-3d driver, the channel
> initialization loop was refactored to iterate directly over the
> scan indices, eliminating redundant logic.
Hi Natália,
I'm a little confused. How is this v3? Where is the change log?
I'll review it as a fresh series.
thanks
Jonathan
>
> Natália Salvino André (6):
> iio: accel: HID: hid-sensor-accel-3d: Refactor channel initialization
> iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
> iio: light: HID: hid-sensor-als: Refactor channel initialization
> iio: light: HID: hid-sensor-prox: Refactor channel initialization
> iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel
> initialization
> iio: pressure: HID: hid-sensor-press: Refactor channel initialization
>
> drivers/iio/accel/hid-sensor-accel-3d.c | 27 +++++++------------
> drivers/iio/gyro/hid-sensor-gyro-3d.c | 24 +++++++----------
> drivers/iio/light/hid-sensor-als.c | 18 +++++--------
> drivers/iio/light/hid-sensor-prox.c | 19 +++++--------
> drivers/iio/magnetometer/hid-sensor-magn-3d.c | 20 +++++---------
> drivers/iio/pressure/hid-sensor-press.c | 19 +++++--------
> 6 files changed, 42 insertions(+), 85 deletions(-)
>
^ permalink raw reply
* [PATCH] HID: lenovo: Restore Fn-lock LED state on resume for tp10ubkbd devices
From: Kean @ 2026-05-12 14:22 UTC (permalink / raw)
To: derekjohn.clark, mpearson-lenovo
Cc: jikos, bentiss, linux-input, linux-kernel, Kean
The reset_resume callback only restores trackpoint settings for compact
USB keyboards (CUSBKBD, TPIIUSBKBD) but omits the tp10ubkbd device
family: X12_TAB, X12_TAB2, TP10UBKBD, X1_TAB, X1_TAB2, X1_TAB3.
If these devices lose power during suspend, the Fn-lock state reverts
to the hardware default but the driver's cached state and the keyboard
LED are not restored, causing the LED to show the wrong state after
resume.
Add the missing device cases to restore the Fn-lock LED on resume.
Tested:
This patch works on ThinkPad X12_TAB.
Signed-off-by: Kean <rh_king@163.com>
---
drivers/hid/hid-lenovo.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index a6b73e03c16b..4c9fb163b6d6 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -1424,6 +1424,8 @@ static int lenovo_probe(struct hid_device *hdev,
static int lenovo_reset_resume(struct hid_device *hdev)
{
+ struct lenovo_drvdata *data;
+
switch (hdev->product) {
case USB_DEVICE_ID_LENOVO_CUSBKBD:
case USB_DEVICE_ID_LENOVO_TPIIUSBKBD:
@@ -1431,6 +1433,17 @@ static int lenovo_reset_resume(struct hid_device *hdev)
lenovo_features_set_cptkbd(hdev);
break;
+ case USB_DEVICE_ID_LENOVO_X12_TAB:
+ case USB_DEVICE_ID_LENOVO_X12_TAB2:
+ case USB_DEVICE_ID_LENOVO_TP10UBKBD:
+ case USB_DEVICE_ID_LENOVO_X1_TAB:
+ case USB_DEVICE_ID_LENOVO_X1_TAB2:
+ case USB_DEVICE_ID_LENOVO_X1_TAB3:
+ data = hid_get_drvdata(hdev);
+ if (data)
+ lenovo_led_set_tp10ubkbd(hdev, TP10UBKBD_FN_LOCK_LED,
+ data->fn_lock ? LED_ON : LED_OFF);
+ break;
default:
break;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/1] HID: magicmouse: Prevent out-of-bounds (OOB) read during DOUBLE_REPORT_ID
From: Lee Jones @ 2026-05-12 14:12 UTC (permalink / raw)
To: Günther Noack
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260430140148.GJ1806155@google.com>
On Thu, 30 Apr 2026, Lee Jones wrote:
> On Thu, 16 Apr 2026, Günther Noack wrote:
>
> > On Thu, Apr 16, 2026 at 02:16:54PM +0100, Lee Jones wrote:
> > > It is currently possible for a malicious or misconfigured USB device to
> > > cause an out-of-bounds (OOB) read when submitting reports using
> > > DOUBLE_REPORT_ID by specifying a large report length and providing a
> > > smaller one.
> > >
> > > Let's prevent that by comparing the specified report length with the
> > > actual size of the data read in from userspace. If the actual data
> > > length ends up being smaller than specified, we'll politely warn the
> > > user and prevent any further processing.
> > >
> > > Signed-off-by: Lee Jones <lee@kernel.org>
> > > ---
> > > v1 => v2: Add more size checks to protect against issues during recursion
> > >
> > > drivers/hid/hid-magicmouse.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
> > > index 91f621ceb924..e84e6b21d113 100644
> > > --- a/drivers/hid/hid-magicmouse.c
> > > +++ b/drivers/hid/hid-magicmouse.c
> > > @@ -390,6 +390,10 @@ static int magicmouse_raw_event(struct hid_device *hdev,
> > > struct input_dev *input = msc->input;
> > > int x = 0, y = 0, ii, clicks = 0, npoints;
> > >
> > > + /* Protect against zero sized recursive calls from DOUBLE_REPORT_ID */
> > > + if (size < 1)
> > > + return 0;
> > > +
> > > switch (data[0]) {
> > > case TRACKPAD_REPORT_ID:
> > > case TRACKPAD2_BT_REPORT_ID:
> > > @@ -490,6 +494,18 @@ static int magicmouse_raw_event(struct hid_device *hdev,
> > > /* Sometimes the trackpad sends two touch reports in one
> > > * packet.
> > > */
> > > +
> > > + /* Ensure that we have at least 2 elements (report type and size) */
> > > + if (size < 2)
> > > + return 0;
> > > +
> > > + if (size < data[1] + 2) {
> > > + hid_warn(hdev,
> > > + "received report length (%d) was smaller than specified (%d)",
> > > + size, data[1] + 2);
> > > + return 0;
> > > + }
> > > +
> > > magicmouse_raw_event(hdev, report, data + 2, data[1]);
> > > magicmouse_raw_event(hdev, report, data + 2 + data[1],
> > > size - 2 - data[1]);
> > > --
> > > 2.54.0.rc1.513.gad8abe7a5a-goog
> > >
> >
> > Thank you! This looks correct now.
> >
> > Reviewed-by: Günther Noack <gnoack@google.com>
>
> Contentless ping. =:-)
Biweekly ping on this please - if you'd prefer a [RESEND], let me know.
--
Lee Jones
^ 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