* Re: [PATCH v2] HID: magicmouse: add haptic click configuration for Magic Trackpad 2
From: Jiri Kosina @ 2026-06-10 16:26 UTC (permalink / raw)
To: Christian Fressl; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260514171524.110189-1-christian@fressl.at>
On Thu, 14 May 2026, Christian Fressl wrote:
> Apple Magic Trackpad 2 devices support persistent haptic feedback
> configuration through feature reports 0x22 and 0x23. Add an opt-in
> module parameter to select either the verified silent-low profile or to
> disable haptic feedback.
>
> The default remains unchanged. The report payload format is
> reverse-engineered, so keep the existing payload bytes fixed and vary
> only the known 24-bit feedback value.
>
> The USB-C Trackpad exposes multiple HID interfaces. Use the one-shot
> actuator output report 0x53 only to identify the interface that accepts
> the persistent configuration reports; do not use it for the persistent
> setting itself.
>
> Tested on Apple Magic Trackpad USB-C 05ac:0324 with Ubuntu
> 6.17.0-23-generic. Compile-tested against HID for-next.
>
> Protocol information was derived from public reverse-engineering notes,
> then independently tested with local hardware.
>
> Link: https://github.com/mwyborski/Linux-Magic-Trackpad-2-Driver/issues/28#issuecomment-451625504
> Signed-off-by: Christian Fressl <christian@fressl.at>
> ---
> Changes in v2:
> - Cache haptic_click with READ_ONCE() before applying the setting.
[ ... snip ... ]
> +static int magicmouse_apply_haptic_click(struct hid_device *hdev)
> +{
> + unsigned int click = READ_ONCE(haptic_click);
Can you please elaborate on why the READ_ONCE() is needed specifically
here? I don't get it.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: multitouch: Honor ContactCount for Yoga Book 9 to suppress ghost contacts
From: Jiri Kosina @ 2026-06-10 16:28 UTC (permalink / raw)
To: Dave Carey; +Cc: linux-input, Benjamin Tissoires
In-Reply-To: <CALPvRORBFHpbos=_xpBVchK-oSZF9EnY6n5-sAQGr=qiL13FbQ@mail.gmail.com>
On Thu, 14 May 2026, Dave Carey wrote:
> The INGENIC 17EF:6161 firmware on the Lenovo Yoga Book 9 14IAH10
> does not clear stale contact slots when fingers are lifted. Each
> HID report contains up to 10 finger slots, but only the first
> ContactCount slots represent valid contacts; the remaining slots
> retain TipSwitch=1 with positions from previous touches.
>
> Raw HID capture confirms this: across a 60-second capture with
> repeated multi-finger gestures, 90% of frames had more TipSwitch=1
> slots than the reported ContactCount. The ContactCount field itself
> is always accurate.
>
> Add MT_QUIRK_CONTACT_CNT_ACCURATE to the MT_CLS_YOGABOOK9I class so
> the driver stops processing slots once ContactCount valid contacts
> have been consumed, discarding the stale ghost entries per HID
> specification section 17. MT_QUIRK_NOT_SEEN_MEANS_UP (already in
> the class) ensures that any slot skipped by this guard is released
> via INPUT_MT_DROP_UNUSED at frame sync.
>
> Signed-off-by: Dave Carey <carvsdriver@gmail.com>
> Tested-by: Dave Carey <carvsdriver@gmail.com>
> ---
> This follows commit 108ac841 ("HID: multitouch: Fix Yoga Book 9 14IAH10
> touchscreen misclassification"), applied to hid/for-next on 2026-05-12,
> which established MT_CLS_YOGABOOK9I and added MT_QUIRK_NOT_SEEN_MEANS_UP.
>
> That fix made the touchscreens fully functional. With three or more
> fingers and repeated on/off gestures, ghost contacts then began appearing
> because the firmware leaves stale TipSwitch=1 data in slots beyond
> ContactCount. The capture showed patterns like cc=1 with 7 active slots,
> or cc=3 with 8 active slots, consistently across all gesture cycles.
> ContactCount was always the correct count. Verified ghost-free after this
> change across 6+ repeated three-finger swipe sequences.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: nintendo: add support for HORI Wireless Switch Pad
From: Jiri Kosina @ 2026-06-10 16:32 UTC (permalink / raw)
To: Hector Zelaya
Cc: Benjamin Tissoires, Daniel J. Ogorchock, linux-input,
linux-kernel, Joshua Peisach
In-Reply-To: <20260527-hori-support-v2-1-195c2f832112@hectorzelaya.dev>
On Wed, 27 May 2026, Hector Zelaya wrote:
> Add support for the HORI Wireless Switch Pad (vendor 0x0f0d, product
> 0x00f6), a licensed third-party Nintendo Switch Pro Controller.
>
> The controller reports controller type 0x06 (vs 0x03 for first-party
> Pro Controllers) and has the following quirks:
>
> - SPI flash calibration data is incompatible; use default stick
> calibration values instead.
> - X and Y button bits are swapped compared to first-party controllers;
> add a dedicated button mapping table.
> - Rumble and IMU enable may timeout (no vibration motor in hardware);
> treat as non-fatal for licensed controllers.
>
> Tested over Bluetooth on NixOS with kernel 7.0.5 and 7.0.10:
> - All 14 buttons map correctly
> - Player LED sets on connect
> - Sticks report correctly with default calibration
> - IMU/gyro data streams at 60Hz
> - D-pad reports on ABS_HAT0X/HAT0Y
>
> Device information:
> Bluetooth name: Lic Pro Controller
> Bluetooth HID: 0005:0F0D:00F6
>
> Assisted-by: Kiro:Auto [Amazon Kiro IDE]
> Signed-off-by: Hector Zelaya <hector@hectorzelaya.dev>
> Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] amd-sfh-hid: tablet mode switch and asus quirk
From: Jiri Kosina @ 2026-06-10 16:33 UTC (permalink / raw)
To: Helge Bahmann
Cc: Nehal Bakulchandra Shah, Sandeep Singh, Basavaraj Natikar,
Benjamin Tissoires, 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, could you please review this one? Thanks.
> ---
> drivers/hid/amd-sfh-hid/amd_sfh_client.c | 25 ++++++++------
> drivers/hid/amd-sfh-hid/amd_sfh_hid.c | 43 ++++++++++++++++++++++++
> drivers/hid/amd-sfh-hid/amd_sfh_hid.h | 6 ++++
> drivers/hid/amd-sfh-hid/amd_sfh_pcie.c | 9 +++++
> drivers/hid/amd-sfh-hid/amd_sfh_pcie.h | 3 ++
> 5 files changed, 75 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_client.c b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> index 7017bfa59093..a24757c5a203 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_client.c
> @@ -128,10 +128,16 @@ void amd_sfh_work_buffer(struct work_struct *work)
> guard(mutex)(&mp2->lock);
> for (i = 0; i < cli_data->num_hid_devices; i++) {
> if (cli_data->sensor_sts[i] == SENSOR_ENABLED) {
> - report_size = mp2->mp2_ops->get_in_rep(i, cli_data->sensor_idx[i],
> - cli_data->report_id[i], in_data);
> - hid_input_report(cli_data->hid_sensor_hubs[i], HID_INPUT_REPORT,
> - in_data->input_report[i], report_size, 0);
> + if (cli_data->hid_sensor_hubs[i]) {
> + report_size = mp2->mp2_ops->get_in_rep(i, cli_data->sensor_idx[i],
> + cli_data->report_id[i],
> + in_data);
> + hid_input_report(cli_data->hid_sensor_hubs[i], HID_INPUT_REPORT,
> + in_data->input_report[i], report_size, 0);
> + } else if (cli_data->sensor_idx[i] == op_idx &&
> + cli_data->modeswitch_input) {
> + amdtp_modeswitch_report(i, cli_data->modeswitch_input, in_data);
> + }
> }
> }
> schedule_delayed_work(&cli_data->work_buffer, msecs_to_jiffies(AMD_SFH_IDLE_LOOP));
> @@ -327,15 +333,12 @@ int amd_sfh_hid_client_init(struct amd_mp2_dev *privdata)
>
> for (i = 0; i < cl_data->num_hid_devices; i++) {
> cl_data->cur_hid_dev = i;
> - if (cl_data->sensor_idx[i] == op_idx) {
> - dev_dbg(dev, "sid 0x%x (%s) status 0x%x\n",
> - cl_data->sensor_idx[i], get_sensor_name(cl_data->sensor_idx[i]),
> - cl_data->sensor_sts[i]);
> - continue;
> - }
>
> if (cl_data->sensor_sts[i] == SENSOR_ENABLED) {
> - rc = amdtp_hid_probe(i, cl_data);
> + if (cl_data->sensor_idx[i] != op_idx)
> + rc = amdtp_hid_probe(i, cl_data);
> + else
> + rc = amdtp_modeswitch_probe(i, cl_data);
> if (rc)
> goto cleanup;
> } else {
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_hid.c b/drivers/hid/amd-sfh-hid/amd_sfh_hid.c
> index 81f3024b7b1b..44008c02b63c 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_hid.c
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_hid.c
> @@ -181,4 +181,47 @@ void amdtp_hid_remove(struct amdtp_cl_data *cli_data)
> cli_data->hid_sensor_hubs[i] = NULL;
> }
> }
> +
> + /* note: cli_data->modeswitch_input implicitly cleaned by devres */
> +}
> +
> +int amdtp_modeswitch_probe(u32 cur_hid_dev, struct amdtp_cl_data *cli_data)
> +{
> + struct amd_mp2_dev *mp2 = container_of(cli_data->in_data, struct amd_mp2_dev, in_data);
> + struct device *dev = &mp2->pdev->dev;
> + struct input_dev *input;
> + int rc;
> +
> + input = devm_input_allocate_device(dev);
> + if (IS_ERR(input))
> + return PTR_ERR(input);
> +
> + input->name = "AMD SFH tablet mode switch sensor";
> + input->id.bustype = BUS_PCI;
> +
> + input_set_capability(input, EV_SW, SW_TABLET_MODE);
> +
> + rc = input_register_device(input);
> + if (rc)
> + goto cleanup;
> +
> + cli_data->modeswitch_input = input;
> +
> + return 0;
> +
> +cleanup:
> + return rc;
> +}
> +
> +void amdtp_modeswitch_report(u32 index, struct input_dev *input, struct amd_input_data *in_data)
> +{
> + u32 *sensor_virt_addr = in_data->sensor_virt_addr[index];
> + u32 value = sensor_virt_addr[0];
> +
> + if (value == AMD_SFH_OP_IDX_MODE_TABLET)
> + input_report_switch(input, SW_TABLET_MODE, 1);
> + else
> + input_report_switch(input, SW_TABLET_MODE, 0);
> +
> + input_sync(input);
> }
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_hid.h b/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
> index 7452b0302953..20aff7b75fbd 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_hid.h
> @@ -11,6 +11,8 @@
> #ifndef AMDSFH_HID_H
> #define AMDSFH_HID_H
>
> +#include <linux/input.h>
> +
> #define MAX_HID_DEVICES 7
> #define AMD_SFH_HID_VENDOR 0x1022
> #define AMD_SFH_HID_PRODUCT 0x0001
> @@ -50,6 +52,7 @@ struct amdtp_cl_data {
> u8 sensor_idx[MAX_HID_DEVICES];
> u8 *feature_report[MAX_HID_DEVICES];
> u8 request_done[MAX_HID_DEVICES];
> + struct input_dev *modeswitch_input;
> struct amd_input_data *in_data;
> struct delayed_work work;
> struct delayed_work work_buffer;
> @@ -78,4 +81,7 @@ void amdtp_hid_remove(struct amdtp_cl_data *cli_data);
> int amd_sfh_get_report(struct hid_device *hid, int report_id, int report_type);
> void amd_sfh_set_report(struct hid_device *hid, int report_id, int report_type);
> void amdtp_hid_wakeup(struct hid_device *hid);
> +int amdtp_modeswitch_probe(u32 cur_hid_dev, struct amdtp_cl_data *cli_data);
> +void amdtp_modeswitch_report(u32 index, struct input_dev *input, struct amd_input_data *in_data);
> +
> #endif
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
> index 1d9f955573aa..cd9cff75f114 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.c
> @@ -39,6 +39,8 @@ module_param_named(sensor_mask, sensor_mask_override, int, 0444);
> MODULE_PARM_DESC(sensor_mask, "override the detected sensors mask");
>
> static bool intr_disable = true;
> +module_param_named(intr_disable, intr_disable, bool, 0444);
> +MODULE_PARM_DESC(intr_disable, "override the interrupt disable sensor bit");
>
> static int amd_sfh_wait_response_v2(struct amd_mp2_dev *mp2, u8 sid, u32 sensor_sts)
> {
> @@ -317,6 +319,13 @@ static const struct dmi_system_id dmi_sfh_table[] = {
> DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook x360 435 G7"),
> },
> },
> + {
> + .callback = mp2_disable_intr,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "VivoBook_ASUSLaptop TP420UA_TM420UA"),
> + }
> + },
> {}
> };
>
> diff --git a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
> index 2eb61f4e8434..5e968894ebe4 100644
> --- a/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
> +++ b/drivers/hid/amd-sfh-hid/amd_sfh_pcie.h
> @@ -83,6 +83,9 @@ enum sensor_idx {
> als_idx = 19
> };
>
> +#define AMD_SFH_OP_IDX_MODE_LAPTOP 1
> +#define AMD_SFH_OP_IDX_MODE_TABLET 3
> +
> enum mem_use_type {
> USE_DRAM,
> USE_C2P_REG,
> --
> 2.47.3
>
>
>
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 7/8] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Conor Dooley @ 2026-06-10 16:34 UTC (permalink / raw)
To: Jun Yan
Cc: conor+dt, devicetree, dmitry.torokhov, krzk+dt, linux-input,
linux-kernel, robh
In-Reply-To: <20260610133458.970174-1-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
On Wed, Jun 10, 2026 at 09:34:58PM +0800, Jun Yan wrote:
> > > > > + threshold, so counts differ.
> > > > > =3D20
> > > > > microchip,calib-sensitivity:
> > > > > $ref: /schemas/types.yaml#/definitions/uint32-array
> > > > > @@ -149,7 +153,7 @@ patternProperties:
> > > > > reg:
> > > > > description: LED channel number
> > > > > minimum: 0
> > > > > - maximum: 7
> > > > > + maximum: 10
> > > > > =3D20
> > > > > required:
> > > > > - reg
> > > > > @@ -199,6 +203,19 @@ allOf:
> > > > > reg:
> > > > > maximum: 1
> > > > > =3D20
> > > > > + - if:
> > > > > + properties:
> > > > > + compatible:
> > > > > + contains:
> > > > > + enum:
> > > > > + - microchip,cap1188
> > > >=20
> > > > I don't understand this restriction, shouldn't this be
> > > > if: properties: compatible: not: contains: microchip,cap1114
> > > > so that the constraints before your change are retained?
> > > >=20
> > >=20
> > > Previously, the LED reg property had a default maximum of 7 for CAP1188.=
> > =20
> > > With the addition of CAP1114, the default maximum is now 11.=20
> > > An if-then constraint is added to limit the LED count for CAP1188.
> >
> > Ah, is this because cap1188 is the only existing device in the binding
> > that actually has LEDs?
>
> - CAP1126: max 2 LED channels (0-1)
> - CAP1188: max 8 LED channels (0-7)
> - CAP1106, CAP12xx: no LED support
>
> The LED reg property constraints for CAP1126 were added in Patch 3 [1].
>
> [1] https://lore.kernel.org/linux-input/20260606150458.250606-4-jerrysteve1101@gmail.com/
Okay, that makes more sense now. Thanks.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] HID: hid-goodix-spi: validate report size to prevent stack buffer overflow
From: Jiri Kosina @ 2026-06-10 16:35 UTC (permalink / raw)
To: Tianchu Chen; +Cc: bentiss, linux-input, linux-kernel, stable
In-Reply-To: <f7e444a3facbe5fb2627167ab205771476e46bc8@linux.dev>
On Fri, 29 May 2026, Tianchu Chen wrote:
> From: Tianchu Chen <flynnnchen@tencent.com>
>
> goodix_hid_set_raw_report() builds a protocol frame in a 128-byte stack
> buffer (tmp_buf), writing an 11-12 byte header followed by the
> caller-supplied report data. The HID core caps report size at
> HID_MAX_BUFFER_SIZE (16384) by default, while the driver does not set
> hid_ll_driver.max_buffer_size and performs no bounds checking before
> copying the payload:
>
> memcpy(tmp_buf + tx_len, buf, len);
>
> A hidraw SET_REPORT ioctl with a report larger than ~116 bytes
> overflows the stack buffer.
>
> Add a size check after constructing the header, rejecting reports that
> would exceed the buffer capacity.
>
> Discovered by Atuin - Automated Vulnerability Discovery Engine.
>
> Fixes: 75e16c8ce283 ("HID: hid-goodix: Add Goodix HID-over-SPI driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
Applied, thanks and sorry for the delay.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/2] HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte reads
From: Jiri Kosina @ 2026-06-10 16:41 UTC (permalink / raw)
To: Zhang Lixu
Cc: Jonathan Cameron, Srinivas Pandruvada, Benjamin Tissoires,
David Lechner, Nuno Sá, Andy Shevchenko, linux-input,
linux-iio, linux-kernel
In-Reply-To: <20260610082911.157232-2-lixu.zhang@intel.com>
On Wed, 10 Jun 2026, Zhang Lixu wrote:
> From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>
> sensor_hub_input_attr_get_raw_value() is limited to returning a single
> 32-bit value, which is insufficient for sensors that report data larger
> than 32 bits, such as a quaternion with four s16 elements.
>
> Add sensor_hub_input_attr_read_values() that accepts a caller-provided
> buffer and accumulates incoming data until the buffer is full. The two
> paths are distinguished in sensor_hub_raw_event() by pending.max_raw_size
> being non-zero, preserving backward compatibility.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Co-developed-by: Zhang Lixu <lixu.zhang@intel.com>
> Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Jiri Kosina <jkosina@suse.com>
Jonathan, will you take the whole lot through your tree?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v1] Input: Drop unused assignments from pnp_device_id arrays
From: Dmitry Torokhov @ 2026-06-10 16:57 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Kees Cook, Werner Sembach, Christoffer Sandberg, feng, gongqi,
linux-input, linux-kernel
In-Reply-To: <ailQutR_TfyCQ-SP@monoceros>
On Wed, Jun 10, 2026 at 01:58:17PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> Hello Dmitry,
>
> On Tue, Jun 09, 2026 at 11:12:49PM -0700, Dmitry Torokhov wrote:
> > On Tue, Jun 09, 2026 at 04:53:25PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > Explicitly assigning .driver_data in drivers that don't use this member
> > > is silly and a bit irritating. Drop these. Also simplify the list
> > > terminator entry to be just empty to match what most other device_id
> > > tables do.
> > >
> > > There is no changed semantic, not even a change in the compiled result.
> > >
> > > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> > > ---
> > > drivers/input/gameport/ns558.c | 46 +++++++++++-----------
> > > drivers/input/serio/i8042-acpipnpio.h | 56 +++++++++++++--------------
> > > 2 files changed, 51 insertions(+), 51 deletions(-)
> > >
> > > diff --git a/drivers/input/gameport/ns558.c b/drivers/input/gameport/ns558.c
> > > index fdece6ec1df3..f70a96c4f1fd 100644
> > > --- a/drivers/input/gameport/ns558.c
> > > +++ b/drivers/input/gameport/ns558.c
> > > @@ -148,29 +148,29 @@ static int ns558_isa_probe(int io)
> > > #ifdef CONFIG_PNP
> > >
> > > static const struct pnp_device_id pnp_devids[] = {
> > > - [...]
> > > - { .id = "", },
> > > + [...]
> > > + { }
> >
> > This goes BOOOM! You have to keep empty .id string as terminator.
>
> How so? Given that my patch doesn't modify the resulting ns558.o I doubt
> that. If .id was a char *, I'd agree, but it's a char[], so there should
> be no difference (and the compiler agrees).
Sorry, brain fart on my part.
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Dmitry Torokhov @ 2026-06-10 17:03 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: Arnd Bergmann, linux-arm-kernel, linux-input, linux-serial,
Russell King, Greg Kroah-Hartman, Jiri Slaby, Russell King,
Linus Walleij, Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weißschuh,
Peter Zijlstra
In-Reply-To: <CADkSEUhh1NdOMTHVsErhqzyCpDGFA-FkNFaWp94e9LnB3njxqw@mail.gmail.com>
On Mon, Jun 08, 2026 at 10:13:50AM -0700, Ethan Nelson-Moore wrote:
> Hi, Arnd,
>
> On Mon, Jun 8, 2026 at 10:11 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > I think this is correct, as footbridge is the only one that selects
> > CONFIG_ARCH_MIGHT_HAVE_PC_SERIO and defines I8042_KBD_IRQ on arm.
>
> I came to the same conclusion.
I see. In this case:
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> # for input
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] amd-sfh-hid: tablet mode switch and asus quirk
From: Basavaraj Natikar @ 2026-06-10 17:12 UTC (permalink / raw)
To: Helge Bahmann, Jiri Kosina, linux-input; +Cc: Basavaraj Natikar, bentiss
In-Reply-To: <2632507.ElGaqSPkdT@lothlorien>
On 5/14/2026 1:29 PM, Helge Bahmann wrote:
> [You don't often get email from hcb@chaoticmind.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Tue, 12 May 2026, Jiri Kosina wrote:
>> 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?
> Some additional context, maybe helpful for review:
>
> 1. The numbers and behavior were extracted from the ACPI tables
> (WMI driver of sorts) of the notebook; I don't have access to any
> official AMD / ASUS docs or similar.
>
> 2. I have an alternate version of this change that is more indirect:
> - create a HID driver providing an "abstract table mode" message
> - have an input driver attaching to this newly defined HID driver
>
> While that is keeping "more in line" with the current driver
> architecture, I am not sure this indirection really helps. Particularly,
> there is no "canonical" HID tablet mode switch message defined,
> so it all remains completely bespoke. I am happy to change it if
> you prefer, but would need your input.
>
> 3. Since this is based on Asus VivoBook and its ACPI tables,
> there is a possibility that this "op sensor / tablet mode" behavior
> is not as universal as I surmise. A point could be made to make this
> entire behavior model-dependent (with a mod param to override
> / activate for other models). Happy to take input / advice.
Thanks Helge.
I'd like to go with the dedicated input-driver approach (your option with
a standalone input driver) rather than the HID-message indirection -- it
keeps clean subsystem boundaries.
For splitting the work, either of these works for me -- whichever you
prefer:
Option 1: I create the new input driver
drivers/input/misc/amd_sfh_tabletmode.c and once done we will review your ASUS VivoBook
quirk + intr_disable module-param patches on top of it.
Option 2: If you'd rather keep ownership of it, you write
drivers/input/misc/amd_sfh_tabletmode.c consuming the mode exposed by
amd-sfh, and I'll review and help.
Let me know which option you'd like and I'll proceed.
Thanks,
--
Basavaraj
^ permalink raw reply
* Re: [PATCH] input: remove changelogs, tracked in git
From: Dmitry Torokhov @ 2026-06-10 18:05 UTC (permalink / raw)
To: Elliot Tester; +Cc: linux-input, linux-kernel
In-Reply-To: <20260514193302.117488-1-elliotctester1@gmail.com>
On Thu, May 14, 2026 at 09:33:02PM +0200, Elliot Tester wrote:
> Signed-off-by: Elliot Tester <elliotctester1@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/7] ASUS Zenbook Duo keyboard support
From: Jiri Kosina @ 2026-06-10 18:06 UTC (permalink / raw)
To: Paolo Pisati; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <5sn10614-2s0s-7r22-s9p9-5np4921p047n@xreary.bet>
On Wed, 10 Jun 2026, Jiri Kosina wrote:
> > Add support for the ASUS Zenbook Duo line of usb/BT wireless convertible keyboards.
> >
> > This patchset is a collective effort, gathered here:
> >
> > https://github.com/NeroReflex/asusctl/issues/25
>
> Applied to hid.git#for-7.2/asus, thanks.
And now dropped due to build breakage reported by Benjamin's CI:
https://gitlab.freedesktop.org/bentiss/hid/-/jobs/102074691
Please fix that and resubmit, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Input: ads7846 - consolidate coordinate filtering logic
From: Aaro Koskinen @ 2026-06-10 18:26 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Kris Bahnsen, linux-input, Mark Featherston, Marek Vasut,
linux-kernel
In-Reply-To: <afzo03UP-shPfNMe@google.com>
Hi,
On Thu, May 07, 2026 at 12:35:04PM -0700, Dmitry Torokhov wrote:
> I think if you pull 'next' branch of my tree, then the following patches
> seem to apply cleanly on 7.0:
>
> c68bc840f06c ("Input: ads7846 - restore half-duplex support")
> 011bdf9f3a9d ("Input: ads7846 - consolidate coordinate filtering logic")
>
> I hope they also build ;)
>
> c68bc840f06c should appear in linux-next soon too.
Did you forgot to push this, or was it dropped? Because I fail to see
it any any tree...
A.
^ permalink raw reply
* Re: [PATCH] HID: uhid: convert to hid_safe_input_report()
From: Jiri Kosina @ 2026-06-10 18:32 UTC (permalink / raw)
To: Carlos Llamas
Cc: David Rheinsberg, Benjamin Tissoires, Lee Jones, kernel-team,
linux-kernel, stable, open list:UHID USERSPACE HID IO DRIVER
In-Reply-To: <20260606181552.3095967-1-cmllamas@google.com>
On Sat, 6 Jun 2026, Carlos Llamas wrote:
> Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()"), added a check in hid_report_raw_event() to reject
> reports if the received data size is smaller than expected. This was
> intended to prevent OOB errors by no longer allowing zeroing-out of
> shorter reports due to the lack of buffer size information.
>
> However, this leads to regressions in hid_report_raw_event(), where
> shorter than expected reports are rejected, even though their buffers
> are sufficiently large to be zero-padded.
>
> To solve this issue, Benjamin introduced a safer alternative in commit
> 206342541fc8 ("HID: core: introduce hid_safe_input_report()"), which
> forwards the buffer size and allows hid_report_raw_event() to safely
> zero-pad the data.
>
> Convert uhid to use hid_safe_input_report() and pass UHID_DATA_MAX as
> the buffer size. This prevents the reported regressions [1], allowing
> hid core to zero-pad the shorter reports safely as expected.
>
> Cc: stable@vger.kernel.org
> Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()")
> Closes: https://lore.kernel.org/all/ahsh0UtTX6e0ZeHa@google.com/ [1]
> Signed-off-by: Carlos Llamas <cmllamas@google.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS ead562291438b5657d7e4d5e8d6d54611b132370
From: kernel test robot @ 2026-06-10 19:02 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: ead562291438b5657d7e4d5e8d6d54611b132370 Input: ipaq-micro-keys - simplify allocation
elapsed time: 761m
configs tested: 236
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260610 gcc-8.5.0
arc randconfig-001-20260611 gcc-14.3.0
arc randconfig-002-20260610 gcc-8.5.0
arc randconfig-002-20260611 gcc-14.3.0
arm allnoconfig clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig gcc-16.1.0
arm mvebu_v7_defconfig clang-23
arm randconfig-001-20260610 gcc-8.5.0
arm randconfig-001-20260611 gcc-14.3.0
arm randconfig-002-20260610 gcc-8.5.0
arm randconfig-002-20260611 gcc-14.3.0
arm randconfig-003-20260610 gcc-8.5.0
arm randconfig-003-20260611 gcc-14.3.0
arm randconfig-004-20260610 gcc-8.5.0
arm randconfig-004-20260611 gcc-14.3.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260610 gcc-11.5.0
arm64 randconfig-002-20260610 gcc-11.5.0
arm64 randconfig-003-20260610 gcc-11.5.0
arm64 randconfig-004-20260610 gcc-11.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260610 gcc-11.5.0
csky randconfig-002-20260610 gcc-11.5.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260610 clang-22
hexagon randconfig-002-20260610 clang-22
i386 allmodconfig clang-22
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260610 gcc-14
i386 buildonly-randconfig-002-20260610 gcc-14
i386 buildonly-randconfig-003-20260610 gcc-14
i386 buildonly-randconfig-004-20260610 gcc-14
i386 buildonly-randconfig-005-20260610 gcc-14
i386 buildonly-randconfig-006-20260610 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260610 gcc-14
i386 randconfig-002-20260610 gcc-14
i386 randconfig-003-20260610 gcc-14
i386 randconfig-004-20260610 gcc-14
i386 randconfig-005-20260610 gcc-14
i386 randconfig-006-20260610 gcc-14
i386 randconfig-007-20260610 gcc-14
i386 randconfig-011-20260610 gcc-14
i386 randconfig-012-20260610 gcc-14
i386 randconfig-013-20260610 gcc-14
i386 randconfig-014-20260610 gcc-14
i386 randconfig-015-20260610 gcc-14
i386 randconfig-016-20260610 gcc-14
i386 randconfig-017-20260610 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260610 clang-22
loongarch randconfig-002-20260610 clang-22
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k apollo_defconfig gcc-16.1.0
m68k defconfig clang-23
m68k m5272c3_defconfig gcc-16.1.0
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001-20260610 clang-22
nios2 randconfig-002-20260610 clang-22
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-17
parisc allyesconfig clang-23
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260610 gcc-8.5.0
parisc randconfig-001-20260611 gcc-13.4.0
parisc randconfig-002-20260610 gcc-8.5.0
parisc randconfig-002-20260611 gcc-13.4.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc randconfig-001-20260610 gcc-8.5.0
powerpc randconfig-001-20260611 gcc-13.4.0
powerpc randconfig-002-20260610 gcc-8.5.0
powerpc randconfig-002-20260611 gcc-13.4.0
powerpc64 randconfig-001-20260610 gcc-8.5.0
powerpc64 randconfig-001-20260611 gcc-13.4.0
powerpc64 randconfig-002-20260610 gcc-8.5.0
powerpc64 randconfig-002-20260611 gcc-13.4.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-16.1.0
riscv randconfig-001-20260610 gcc-16.1.0
riscv randconfig-002 gcc-16.1.0
riscv randconfig-002-20260610 gcc-16.1.0
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-16.1.0
s390 randconfig-001-20260610 gcc-16.1.0
s390 randconfig-002 gcc-16.1.0
s390 randconfig-002-20260610 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-17
sh allyesconfig clang-23
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh randconfig-001 gcc-16.1.0
sh randconfig-001-20260610 gcc-16.1.0
sh randconfig-002 gcc-16.1.0
sh randconfig-002-20260610 gcc-16.1.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001 gcc-14.3.0
sparc randconfig-001-20260610 gcc-14.3.0
sparc randconfig-001-20260611 gcc-15.2.0
sparc randconfig-002 gcc-14.3.0
sparc randconfig-002-20260610 gcc-14.3.0
sparc randconfig-002-20260611 gcc-15.2.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-14.3.0
sparc64 randconfig-001-20260610 gcc-14.3.0
sparc64 randconfig-001-20260611 gcc-15.2.0
sparc64 randconfig-002 gcc-14.3.0
sparc64 randconfig-002-20260610 gcc-14.3.0
sparc64 randconfig-002-20260611 gcc-15.2.0
um allmodconfig clang-17
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-14.3.0
um randconfig-001-20260610 gcc-14.3.0
um randconfig-001-20260611 gcc-15.2.0
um randconfig-002 gcc-14.3.0
um randconfig-002-20260610 gcc-14.3.0
um randconfig-002-20260611 gcc-15.2.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260610 gcc-14
x86_64 buildonly-randconfig-002-20260610 gcc-14
x86_64 buildonly-randconfig-003-20260610 gcc-14
x86_64 buildonly-randconfig-004-20260610 gcc-14
x86_64 buildonly-randconfig-005-20260610 gcc-14
x86_64 buildonly-randconfig-006-20260610 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260610 gcc-13
x86_64 randconfig-002-20260610 gcc-13
x86_64 randconfig-003-20260610 gcc-13
x86_64 randconfig-004-20260610 gcc-13
x86_64 randconfig-005-20260610 gcc-13
x86_64 randconfig-006-20260610 gcc-13
x86_64 randconfig-011-20260610 gcc-14
x86_64 randconfig-012-20260610 gcc-14
x86_64 randconfig-013-20260610 gcc-14
x86_64 randconfig-014-20260610 gcc-14
x86_64 randconfig-015-20260610 gcc-14
x86_64 randconfig-016-20260610 gcc-14
x86_64 randconfig-071-20260610 gcc-14
x86_64 randconfig-072-20260610 gcc-14
x86_64 randconfig-073-20260610 gcc-14
x86_64 randconfig-074-20260610 gcc-14
x86_64 randconfig-075-20260610 gcc-14
x86_64 randconfig-076-20260610 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa allyesconfig gcc-16.1.0
xtensa randconfig-001 gcc-14.3.0
xtensa randconfig-001-20260610 gcc-14.3.0
xtensa randconfig-001-20260611 gcc-15.2.0
xtensa randconfig-002 gcc-14.3.0
xtensa randconfig-002-20260610 gcc-14.3.0
xtensa randconfig-002-20260611 gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume
From: Jiri Kosina @ 2026-06-10 20:08 UTC (permalink / raw)
To: d3z
Cc: even.xu, bentiss, xinpeng.sun, linux-input, linux-kernel,
sakari.ailus, abhishektamboli9
In-Reply-To: <20260601211828.112626-1-d3z.the.dev@gmail.com>
On Tue, 2 Jun 2026, d3z wrote:
> From: Danny D. <d3z.the.dev@gmail.com>
>
> On the Surface Pro 10 (Meteor Lake) the touchscreen stops working after a
> suspend/resume cycle and only recovers after a reboot. The driver logs
> "GET_DEVICE_INFO: recv failed: -11" on resume.
>
> This platform suspends through s2idle: /sys/power/mem_sleep exposes
> "[s2idle]" as the only state, there is no "deep"/S3 entry at all. The
> touch IC nonetheless loses power across that s2idle suspend, the same
> way it does across hibernation. quickspi_resume() only re-selects the
> THC port, restores interrupts and DMA and sends a HIDSPI_ON command,
> assuming the touch IC kept its power and state. When it has actually
> lost power the HIDSPI_ON command is never acknowledged and the
> descriptor read fails, leaving the touchscreen dead until the module is
> reloaded.
>
> quickspi_restore() already handles this for hibernation by
> reconfiguring the THC SPI/LTR settings and running reset_tic() to
> re-enumerate the device. Make quickspi_resume() do the same when the
> device is not a wake source. A wake-enabled device keeps its power and
> state across suspend, so it stays on the light restore path: resetting
> it would discard a pending wake touch event and break wake-on-touch.
>
> The non-wake path mirrors the existing quickspi_restore() sequence,
> including enabling interrupts before reset_tic(), so it introduces no
> new ordering relative to code already in the driver.
>
> This change has been validated on a Surface Pro 10 running the
> linux-surface kernel across multiple s2idle suspend/resume cycles; it
> has not been tested on a mainline build.
>
> Closes: https://github.com/linux-surface/linux-surface/issues/1799
> Signed-off-by: Danny D. <d3z.the.dev@gmail.com>
> ---
> v1 -> v2:
> - Only run the full reset when the device is not a wake source
> (device_may_wakeup()), so wake-on-touch is no longer disturbed.
> - Reword the changelog around s2idle: the SP10 has no "deep"/S3 state, the
> touch IC loses power across s2idle.
>
> .../hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 60 +++++++++++++++++--
> 1 file changed, 56 insertions(+), 4 deletions(-)
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Input: ads7846 - consolidate coordinate filtering logic
From: Dmitry Torokhov @ 2026-06-10 22:49 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Kris Bahnsen, linux-input, Mark Featherston, Marek Vasut,
linux-kernel
In-Reply-To: <aimsXWeg3wouoiB9@darkstar.musicnaut.iki.fi>
On Wed, Jun 10, 2026 at 09:26:37PM +0300, Aaro Koskinen wrote:
> Hi,
>
> On Thu, May 07, 2026 at 12:35:04PM -0700, Dmitry Torokhov wrote:
> > I think if you pull 'next' branch of my tree, then the following patches
> > seem to apply cleanly on 7.0:
> >
> > c68bc840f06c ("Input: ads7846 - restore half-duplex support")
> > 011bdf9f3a9d ("Input: ads7846 - consolidate coordinate filtering logic")
> >
> > I hope they also build ;)
> >
> > c68bc840f06c should appear in linux-next soon too.
>
> Did you forgot to push this, or was it dropped? Because I fail to see
> it any any tree...
Well, that explains why Kris could not find them... Pushed out.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4] Input: ads7846 - don't use scratch for tx_buf when clearing register
From: Dmitry Torokhov @ 2026-06-10 22:49 UTC (permalink / raw)
To: Kris Bahnsen
Cc: Marek Vasut, stable, Mark Featherston, linux-input, linux-kernel
In-Reply-To: <20260507164943.760009-1-kris@embeddedTS.com>
On Thu, May 07, 2026 at 04:49:43PM +0000, Kris Bahnsen wrote:
> The workaround for XPT2046 clears the command register, giving the
> touchscreen controller a NOP. The change incorrectly re-uses the
> req->scratch variable which is used as rx_buf for xfer[5], so by
> the time xfer[6] occurs, the contents of req->scratch may not be
> 0. It was found that the touchscreen controller can end up in
> a completely unresponsive state due to it being given a command
> the driver does not expect.
>
> Instead, rely on the spi_transfer behavior of tx_buf being NULL to
> transmit all 0 bits and use the scratch variable for the rx_buf for
> both the 1 byte command to and 2 byte response from the controller.
>
> Also relocates the scratch member of struct ser_req to force it
> into a different cache line to prevent any potential issues of
> DMA stepping on unrelated data in other struct members due to
> sharing the same cache line.
>
> This change was tested on real TSC2046 and ADS7843 controllers,
> but not the XPT2046 the workaround was originally created for.
> Confirming that the original modification to clear the command
> register does not impact either real controller.
>
> Fixes: 781a07da9bb94 ("Input: ads7846 - add dummy command register clearing cycle")
> Cc: stable@vger.kernel.org
> Co-developed-by: Mark Featherston <mark@embeddedTS.com>
> Signed-off-by: Mark Featherston <mark@embeddedTS.com>
> Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] HID: lenovo: Add support for ThinkPad X13 Folio keyboard
From: Vishnu Sankar @ 2026-06-10 22:59 UTC (permalink / raw)
To: Jiri Kosina
Cc: bentiss, derekjohn.clark, mpearson-lenovo, vsankar, linux-input,
linux-kernel
In-Reply-To: <09prqp54-684n-r4q1-02or-1nqr1s4516on@xreary.bet>
Hi Jiri,
Thank you so much.
On Thu, Jun 11, 2026 at 12:39 AM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Wed, 10 Jun 2026, Vishnu Sankar wrote:
>
> > Hi Jiri / Benjamin,
> >
> > Gently pinging on this series.
> > Is there anything blocking acceptance or any changes needed from my side?
> > The series has been tested on physical hardware.
>
> Sorry for the delay. Now applied to hid.git#for-7.1/upstream-fixes.
>
> --
> Jiri Kosina
> SUSE Labs
>
--
Regards,
Vishnu Sankar
^ permalink raw reply
* [PATCH] Input: ipaq-micro-keys - add length check in micro_key_receive
From: Dmitry Torokhov @ 2026-06-10 23:02 UTC (permalink / raw)
To: linux-input; +Cc: Rosen Penev, linux-kernel
The driver accesses the message payload (msg[0]) without checking if
the length is greater than zero. The parent MFD driver can produce a
payload with a length of 0, in which case msg[0] would be uninitialized
or stale.
Add a check to return early if len is less than 1.
Reported-by: sashiko-bot@kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/ipaq-micro-keys.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/keyboard/ipaq-micro-keys.c b/drivers/input/keyboard/ipaq-micro-keys.c
index 3c7d6aa0fe29..ebd991de70f8 100644
--- a/drivers/input/keyboard/ipaq-micro-keys.c
+++ b/drivers/input/keyboard/ipaq-micro-keys.c
@@ -43,6 +43,9 @@ static void micro_key_receive(void *data, int len, unsigned char *msg)
struct ipaq_micro_keys *keys = data;
int key, down;
+ if (len < 1)
+ return;
+
down = 0x80 & msg[0];
key = 0x7f & msg[0];
--
2.54.0.1099.g489fc7bff1-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH] Input: ipaq-micro-keys - add length check in micro_key_receive
From: sashiko-bot @ 2026-06-10 23:14 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <aintAvTyw4CVb5hG@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] `micro_key_start()` and `micro_key_stop()` acquire `keys->micro->lock` without disabling interrupts, leading to a potential deadlock with the MFD serial interrupt handler.
--
commit 33b9102060e60926d04c255f54b3c13bbafe5ca3
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Input: ipaq-micro-keys - add length check in micro_key_receive
The driver accesses the message payload (msg[0]) without checking if
the length is greater than zero. The parent MFD driver can produce a
payload with a length of 0, in which case msg[0] would be uninitialized
or stale.
Add a check to return early if len is less than 1.
Reported-by: sashiko-bot@kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> diff --git a/drivers/input/keyboard/ipaq-micro-keys.c b/drivers/input/keyboard/ipaq-micro-keys.c
> index 695ef3c2081a4..b2068fbc82651 100644
> --- a/drivers/input/keyboard/ipaq-micro-keys.c
> +++ b/drivers/input/keyboard/ipaq-micro-keys.c
> @@ -43,6 +43,9 @@ static void micro_key_receive(void *data, int len, unsigned char *msg)
> struct ipaq_micro_keys *keys = data;
> int key, down;
>
> + if (len < 1)
> + return;
> +
> down = 0x80 & msg[0];
> key = 0x7f & msg[0];
>
[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential deadlock
involving keys->micro->lock when looking at the surrounding code.
Does the use of guard(spinlock) in micro_key_start() and micro_key_stop()
risk a deadlock with the MFD serial interrupt handler?
drivers/input/keyboard/ipaq-micro-keys.c:micro_key_start() {
guard(spinlock)(&keys->micro->lock);
...
}
drivers/input/keyboard/ipaq-micro-keys.c:micro_key_stop() {
guard(spinlock)(&keys->micro->lock);
...
}
The keys->micro->lock spinlock is also acquired within the MFD driver's hard
IRQ handler in micro_serial_isr(). Since micro_key_start() and
micro_key_stop() are called in process context without disabling local
interrupts, could an interrupt firing on the same CPU while the lock is held
cause the ISR to try acquiring the lock again and hang?
Should these functions be using guard(spinlock_irqsave) or equivalent to
prevent this?
--
Sashiko AI review · https://sashiko.dev/#/patchset/aintAvTyw4CVb5hG@google.com?part=1
^ permalink raw reply
* Re: [PATCH v3 2/4] HID: wacom: Fix Use-After-Free in wacom_bamboo_pad
From: Dmitry Torokhov @ 2026-06-10 23:17 UTC (permalink / raw)
To: Lee Jones
Cc: Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
Peter Hutterer, linux-input, linux-kernel
In-Reply-To: <20260609121353.3743782-2-lee@kernel.org>
On Tue, Jun 09, 2026 at 01:13:38PM +0100, Lee Jones wrote:
> @@ -3308,13 +3309,12 @@ static void wacom_bamboo_pad_pen_event(struct wacom_wac *wacom,
> prefix = data[0];
> data[0] = WACOM_REPORT_BPAD_PEN;
>
> - /*
> - * actually reroute the event.
> - * No need to check if wacom->shared->pen is valid, hid_input_report()
> - * will check for us.
> - */
> - hid_input_report(wacom->shared->pen, HID_INPUT_REPORT, data,
> - WACOM_PKGLEN_PENABLED, 1);
> + rcu_read_lock();
Since the driver already uses guard notation we can use
guard(rcu)();
> + pen = rcu_dereference(wacom->shared->pen);
> + if (pen)
> + hid_input_report(pen, HID_INPUT_REPORT, data,
> + WACOM_PKGLEN_PENABLED, 1);
> + rcu_read_unlock();
>
> data[0] = prefix;
> }
Otherwise:
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/4] HID: wacom: Fix Use-After-Free in wacom_intuos_pad
From: Dmitry Torokhov @ 2026-06-10 23:22 UTC (permalink / raw)
To: Lee Jones
Cc: Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
Peter Hutterer, linux-input, linux-kernel
In-Reply-To: <20260609121353.3743782-1-lee@kernel.org>
On Tue, Jun 09, 2026 at 01:13:37PM +0100, Lee Jones wrote:
> wacom_intuos_pad() accesses wacom->shared->touch_input locklessly
> inside the interrupt handler context. If the Touch sibling device
> is disconnected, wacom_remove_shared_data() clears 'touch_input'
> outside any lock, creating a Time-of-Check to Time-of-Use (TOCTOU)
> race condition where a preempted reader in interrupt context
> dereferences the freed pointer, leading to a Use-After-Free.
>
> Resolve this by introducing RCU protection for the touch_input
> pointer:
>
> - Annotate 'touch_input' in wacom_shared struct with __rcu
> - Wrap all lockless readers in wacom_wac.c with rcu_read_lock() and
> rcu_dereference() using a unified wacom_report_touch_mute()
> helper
> - Update writers in wacom_sys.c using rcu_assign_pointer()
> - Call synchronize_rcu() in wacom_remove_shared_data() to ensure
> all active RCU readers have finished before the input device is
> freed
>
> Also wrap wacom_set_shared_values() and touch/pen assignments in
> wacom_add_shared_data() inside the wacom_udev_list_lock to serialize
> concurrent probe assignments, and verify that 'shared->touch == hdev'
> before setting touch_input to prevent concurrent sibling probe state
> desynchronization.
>
> Finally, advertise the SW_MUTE_DEVICE capability on Touch input
> devices prior to registration in wacom_setup_touch_input_capabilities()
> to prevent invalid post-registration capability modifications.
>
> Fixes: 961794a00eab ("Input: wacom - add reporting of SW_MUTE_DEVICE events")
> Signed-off-by: Lee Jones <lee@kernel.org>
> ---
>
> v1 -> v2: Split and use RCU as per Dmitry's review
> v2 -> v3: Sashiko fixes
>
> drivers/hid/wacom_sys.c | 41 ++++++++++++++----------
> drivers/hid/wacom_wac.c | 70 ++++++++++++++++++++++-------------------
> drivers/hid/wacom_wac.h | 2 +-
> 3 files changed, 63 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 2220168bf116..7ba589826548 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -877,10 +877,16 @@ static void wacom_remove_shared_data(void *res)
> data = container_of(wacom_wac->shared, struct wacom_hdev_data,
> shared);
>
> - if (wacom_wac->shared->touch == wacom->hdev)
> - wacom_wac->shared->touch = NULL;
> - else if (wacom_wac->shared->pen == wacom->hdev)
> - wacom_wac->shared->pen = NULL;
> + scoped_guard(mutex, &wacom_udev_list_lock) {
> + if (wacom_wac->shared->touch == wacom->hdev) {
> + wacom_wac->shared->touch = NULL;
> + rcu_assign_pointer(wacom_wac->shared->touch_input, NULL);
> + } else if (wacom_wac->shared->pen == wacom->hdev) {
> + wacom_wac->shared->pen = NULL;
> + }
> + }
> +
> + synchronize_rcu();
>
> kref_put(&data->kref, wacom_release_shared_data);
> wacom_wac->shared = NULL;
> @@ -909,6 +915,11 @@ static int wacom_add_shared_data(struct hid_device *hdev)
> list_add_tail(&data->list, &wacom_udev_list);
> }
>
> + if (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH)
> + data->shared.touch = hdev;
> + else if (wacom_wac->features.device_type & WACOM_DEVICETYPE_PEN)
> + data->shared.pen = hdev;
> +
> mutex_unlock(&wacom_udev_list_lock);
>
> wacom_wac->shared = &data->shared;
> @@ -917,11 +928,6 @@ static int wacom_add_shared_data(struct hid_device *hdev)
> if (retval)
> return retval;
>
> - if (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH)
> - wacom_wac->shared->touch = hdev;
> - else if (wacom_wac->features.device_type & WACOM_DEVICETYPE_PEN)
> - wacom_wac->shared->pen = hdev;
> -
> return retval;
> }
>
> @@ -2345,9 +2351,15 @@ static void wacom_release_resources(struct wacom *wacom)
>
> static void wacom_set_shared_values(struct wacom_wac *wacom_wac)
> {
> + struct wacom *wacom = container_of(wacom_wac, struct wacom, wacom_wac);
> +
> + mutex_lock(&wacom_udev_list_lock);
Why not
guard(mutex)(&wacom_udev_list_lock);
> +
> if (wacom_wac->features.device_type & WACOM_DEVICETYPE_TOUCH) {
> - wacom_wac->shared->type = wacom_wac->features.type;
> - wacom_wac->shared->touch_input = wacom_wac->touch_input;
> + if (wacom_wac->shared->touch == wacom->hdev) {
> + wacom_wac->shared->type = wacom_wac->features.type;
> + rcu_assign_pointer(wacom_wac->shared->touch_input, wacom_wac->touch_input);
> + }
> }
>
> if (wacom_wac->has_mute_touch_switch) {
> @@ -2361,12 +2373,7 @@ static void wacom_set_shared_values(struct wacom_wac *wacom_wac)
> wacom_wac->shared->is_touch_on = true;
> }
>
> - if (wacom_wac->shared->has_mute_touch_switch &&
> - wacom_wac->shared->touch_input) {
> - set_bit(EV_SW, wacom_wac->shared->touch_input->evbit);
> - input_set_capability(wacom_wac->shared->touch_input, EV_SW,
> - SW_MUTE_DEVICE);
> - }
> + mutex_unlock(&wacom_udev_list_lock);
> }
>
> static int wacom_parse_and_register(struct wacom *wacom, bool wireless)
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index da1f0ea85625..495960227b8d 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -510,6 +510,22 @@ static void wacom_intuos_schedule_prox_event(struct wacom_wac *wacom_wac)
> }
> }
>
> +static void wacom_report_touch_mute(struct wacom_wac *wacom_wac, bool mute)
> +{
> + struct input_dev *touch_input;
> +
> + if (!wacom_wac->shared)
> + return;
Can this happen? I think callers already check this or simply
dereference.
> +
> + rcu_read_lock();
guard(rcu)();
> + touch_input = rcu_dereference(wacom_wac->shared->touch_input);
> + if (touch_input) {
> + input_report_switch(touch_input, SW_MUTE_DEVICE, mute);
> + input_sync(touch_input);
> + }
> + rcu_read_unlock();
> +}
> +
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: synaptics-rmi4 - unregister function handlers on physical driver registration failure
From: Dmitry Torokhov @ 2026-06-10 23:41 UTC (permalink / raw)
To: Haoxiang Li
Cc: git, Marge.Yang, kees, jiapeng.chong, linux-input, linux-kernel,
stable
In-Reply-To: <20260610064633.2837084-1-haoxiang_li2024@163.com>
Hi Haoxiang,
On Wed, Jun 10, 2026 at 02:46:33PM +0800, Haoxiang Li wrote:
> If rmi_register_physical_driver() fails, the current error path
> unregisters only the RMI bus. The function handlers registered
> earlier remain registered with the driver core.
>
> Add a separate error path to unregister the function handlers
> before unregistering the bus in this failure case.
>
> Fixes: d6e680837ec5 ("Input: synaptics-rmi4 - fix function name in kerneldoc")
This is not correct commit for fixes. I changed this to
2b6a321da9a2 ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices")
and applied, thank you.
Thanks.
--
Dmitry
^ permalink raw reply
* [hid:for-7.2/asus 1/7] drivers/hid/hid-asus.c:1399:14: warning: variable 'rsize_orig' is used uninitialized whenever 'if' condition is false
From: kernel test robot @ 2026-06-11 4:05 UTC (permalink / raw)
To: Joshua Leivenzon; +Cc: llvm, oe-kbuild-all, linux-input, Jiri Kosina
tree: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-7.2/asus
head: 9bde6277292c8233fb24fc6e51323027b49d1cde
commit: 92f9f783f013a27a175089950b7b22c3d5a48249 [1/7] HID: asus: Fix up Zenbook Duo report descriptors
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260611/202606110526.QfgiXQTQ-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260611/202606110526.QfgiXQTQ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606110526.QfgiXQTQ-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/hid/hid-asus.c:1399:14: warning: variable 'rsize_orig' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
1399 | } else if (drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/hid/hid-asus.c:1410:17: note: uninitialized use occurs here
1410 | if (*rsize == rsize_orig &&
| ^~~~~~~~~~
drivers/hid/hid-asus.c:1399:10: note: remove the 'if' if its condition is always true
1399 | } else if (drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/hid/hid-asus.c:1390:17: note: initialize the variable 'rsize_orig' to silence this warning
1390 | int rsize_orig;
| ^
| = 0
1 warning generated.
vim +1399 drivers/hid/hid-asus.c
1370
1371 static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
1372 unsigned int *rsize)
1373 {
1374 struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
1375
1376 if (drvdata->quirks & QUIRK_FIX_NOTEBOOK_REPORT &&
1377 *rsize >= 56 && rdesc[54] == 0x25 && rdesc[55] == 0x65) {
1378 hid_info(hdev, "Fixing up Asus notebook report descriptor\n");
1379 rdesc[55] = 0xdd;
1380 }
1381 /* For the T100TA/T200TA keyboard dock */
1382 if (drvdata->quirks & QUIRK_T100_KEYBOARD &&
1383 (*rsize == 76 || *rsize == 101) &&
1384 rdesc[73] == 0x81 && rdesc[74] == 0x01) {
1385 hid_info(hdev, "Fixing up Asus T100 keyb report descriptor\n");
1386 rdesc[74] &= ~HID_MAIN_ITEM_CONSTANT;
1387 }
1388 /* For the T100CHI/T90CHI keyboard dock and Zenbook Duo 2024+ keyboards */
1389 if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI | QUIRK_ZENBOOK_DUO_KEYBOARD)) {
1390 int rsize_orig;
1391 int offs;
1392
1393 if (drvdata->quirks & QUIRK_T100CHI) {
1394 rsize_orig = 403;
1395 offs = 388;
1396 } else if (drvdata->quirks & QUIRK_T90CHI) {
1397 rsize_orig = 306;
1398 offs = 291;
> 1399 } else if (drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) {
1400 rsize_orig = 257;
1401 offs = 176;
1402 }
1403
1404 /*
1405 * Change Usage (76h) to Usage Minimum (00h), Usage Maximum
1406 * (FFh) and clear the flags in the Input() byte.
1407 * Note the descriptor has a bogus 0 byte at the end so we
1408 * only need 1 extra byte.
1409 */
1410 if (*rsize == rsize_orig &&
1411 rdesc[offs] == 0x09 && rdesc[offs + 1] == 0x76) {
1412 __u8 *new_rdesc;
1413
1414 new_rdesc = devm_kzalloc(&hdev->dev, rsize_orig + 1,
1415 GFP_KERNEL);
1416 if (!new_rdesc)
1417 return rdesc;
1418
1419 hid_info(hdev, "Fixing up %s keyb report descriptor\n",
1420 drvdata->quirks & QUIRK_T100CHI ?
1421 "T100CHI" : drvdata->quirks & QUIRK_T90CHI ?
1422 "T90CHI" : "ZENBOOK DUO");
1423
1424 memcpy(new_rdesc, rdesc, rsize_orig);
1425 *rsize = rsize_orig + 1;
1426 rdesc = new_rdesc;
1427
1428 memmove(rdesc + offs + 4, rdesc + offs + 2, 12);
1429 rdesc[offs] = 0x19;
1430 rdesc[offs + 1] = 0x00;
1431 rdesc[offs + 2] = 0x29;
1432 rdesc[offs + 3] = 0xff;
1433 rdesc[offs + 14] = 0x00;
1434 }
1435 }
1436
1437 if (drvdata->quirks & QUIRK_G752_KEYBOARD &&
1438 *rsize == 75 && rdesc[61] == 0x15 && rdesc[62] == 0x00) {
1439 /* report is missing usage minimum and maximum */
1440 __u8 *new_rdesc;
1441 size_t new_size = *rsize + sizeof(asus_g752_fixed_rdesc);
1442
1443 new_rdesc = devm_kzalloc(&hdev->dev, new_size, GFP_KERNEL);
1444 if (new_rdesc == NULL)
1445 return rdesc;
1446
1447 hid_info(hdev, "Fixing up Asus G752 keyb report descriptor\n");
1448 /* copy the valid part */
1449 memcpy(new_rdesc, rdesc, 61);
1450 /* insert missing part */
1451 memcpy(new_rdesc + 61, asus_g752_fixed_rdesc, sizeof(asus_g752_fixed_rdesc));
1452 /* copy remaining data */
1453 memcpy(new_rdesc + 61 + sizeof(asus_g752_fixed_rdesc), rdesc + 61, *rsize - 61);
1454
1455 *rsize = new_size;
1456 rdesc = new_rdesc;
1457 }
1458
1459 if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
1460 *rsize == 331 && rdesc[190] == 0x85 && rdesc[191] == 0x5a &&
1461 rdesc[204] == 0x95 && rdesc[205] == 0x05) {
1462 hid_info(hdev, "Fixing up Asus N-KEY keyb report descriptor\n");
1463 rdesc[205] = 0x01;
1464 }
1465
1466 /* match many more n-key devices */
1467 if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD && *rsize > 15) {
1468 for (int i = 0; i < *rsize - 15; i++) {
1469 /* offset to the count from 0x5a report part always 14 */
1470 if (rdesc[i] == 0x85 && rdesc[i + 1] == 0x5a &&
1471 rdesc[i + 14] == 0x95 && rdesc[i + 15] == 0x05) {
1472 hid_info(hdev, "Fixing up Asus N-Key report descriptor\n");
1473 rdesc[i + 15] = 0x01;
1474 break;
1475 }
1476 }
1477 }
1478
1479 return rdesc;
1480 }
1481
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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