* [PATCH] Input: mpr121: Drop redundant wakeup handling
From: phucduc.bui @ 2026-03-09 7:14 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: phucduc.bui, linux-input, linux-kernel
From: bui duc phuc <phucduc.bui@gmail.com>
The driver currently calls device_init_wakeup() and manually toggles
IRQ wake in suspend and resume paths. This is unnecessary since the
I2C core already handles wakeup configuration when the device is
described in Device Tree with the "wakeup-source" property.
Note: Compile-tested only, not verified on hardware.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
drivers/input/keyboard/mpr121_touchkey.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/input/keyboard/mpr121_touchkey.c b/drivers/input/keyboard/mpr121_touchkey.c
index bd1a944ded46..47edc161ec77 100644
--- a/drivers/input/keyboard/mpr121_touchkey.c
+++ b/drivers/input/keyboard/mpr121_touchkey.c
@@ -295,8 +295,6 @@ static int mpr_touchkey_probe(struct i2c_client *client)
return error;
i2c_set_clientdata(client, mpr121);
- device_init_wakeup(dev,
- device_property_read_bool(dev, "wakeup-source"));
return 0;
}
@@ -305,9 +303,6 @@ static int mpr_suspend(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
- if (device_may_wakeup(&client->dev))
- enable_irq_wake(client->irq);
-
i2c_smbus_write_byte_data(client, ELECTRODE_CONF_ADDR, 0x00);
return 0;
@@ -318,9 +313,6 @@ static int mpr_resume(struct device *dev)
struct i2c_client *client = to_i2c_client(dev);
struct mpr121_touchkey *mpr121 = i2c_get_clientdata(client);
- if (device_may_wakeup(&client->dev))
- disable_irq_wake(client->irq);
-
i2c_smbus_write_byte_data(client, ELECTRODE_CONF_ADDR,
mpr121->keycount);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v7 1/3] input: trackpoint - Enable doubletap by default on capable devices
From: Ilpo Järvinen @ 2026-03-09 8:01 UTC (permalink / raw)
To: Vishnu Sankar
Cc: Mark Pearson, dmitry.torokhov, hmh, Hans de Goede, corbet,
derekjohn.clark, linux-input, LKML, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar
In-Reply-To: <20260209063355.491189-2-vishnuocv@gmail.com>
On Mon, 9 Feb 2026, Vishnu Sankar wrote:
> Enable doubletap functionality by default on TrackPoint devices that
> support it. The feature is detected using firmware ID pattern matching
> (PNP: LEN03xxx) with a deny list of incompatible devices.
>
> This provides immediate doubletap functionality without requiring
> userspace configuration. The hardware is enabled during device
> detection, while event filtering continues to be handled by the
> thinkpad_acpi driver as before.
>
> Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
> Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> Changes in v7:
> - Removed unwanted comments
> - Removed psmouse_info ()
>
> Changes in v6:
> - No Changes
>
> Changes in v5:
> - Renamed function to trackpoint_is_dt_capable()
> - Simplified string comparison without sscanf()
> - Removed wrapper function as suggested
> - Fixed missing period in comment
>
> Changes in v4:
> - Simplified approach: removed all sysfs attributes and user interface
> - Enable doubletap by default during device detection
> - Removed global variables and complex attribute infrastructure
> - Uses minimal firmware ID detection with deny list
> - Follows KISS principle as suggested by reviewers
>
> Changes in v3:
> - No changes
>
> Changes in v2:
> - Improve commit messages
> - Sysfs attributes moved to trackpoint.c
> - Removed unnecessary comments
> - Removed unnecessary debug messages
> - Using strstarts() instead of strcmp()
> - is_trackpoint_dt_capable() modified
> - Removed _BIT suffix and used BIT() define
> - Reverse the trackpoint_doubletap_status() logic to return error first
> - Removed export functions as a result of the design change
> - Changed trackpoint_dev->psmouse to parent_psmouse
> - The path of trackpoint.h is not changed
> ---
> drivers/input/mouse/trackpoint.c | 45 ++++++++++++++++++++++++++++++++
> drivers/input/mouse/trackpoint.h | 5 ++++
> 2 files changed, 50 insertions(+)
>
> diff --git a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
> index 5f6643b69a2c..e12d76350252 100644
> --- a/drivers/input/mouse/trackpoint.c
> +++ b/drivers/input/mouse/trackpoint.c
> @@ -393,6 +393,45 @@ static int trackpoint_reconnect(struct psmouse *psmouse)
> return 0;
> }
>
> +/* List of known incapable device PNP IDs */
> +static const char * const dt_incompatible_devices[] = {
> + "LEN0304",
> + "LEN0306",
> + "LEN0317",
> + "LEN031A",
> + "LEN031B",
> + "LEN031C",
> + "LEN031D",
> +};
> +
> +/*
> + * Checks if it's a doubletap capable device.
> + * The PNP ID format is "PNP: LEN030d PNP0f13".
> + */
> +static bool trackpoint_is_dt_capable(const char *pnp_id)
> +{
> + size_t i;
> +
> + if (!pnp_id)
> + return false;
> +
> + /* Must start with "PNP: LEN03" */
> + if (!strstarts(pnp_id, "PNP: LEN03"))
Missing include.
> + return false;
> +
> + /* Ensure enough length before comparing */
> + if (strlen(pnp_id) < 12)
> + return false;
> +
> + /* Check deny-list */
> + for (i = 0; i < ARRAY_SIZE(dt_incompatible_devices); i++) {
Missing include for ARRAY_SIZE().
> + if (!strncmp(pnp_id + 5,
> + dt_incompatible_devices[i], 7))
Fits to one line.
> + return false;
> + }
> + return true;
> +}
> +
> int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
> {
> struct ps2dev *ps2dev = &psmouse->ps2dev;
> @@ -470,6 +509,12 @@ int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
> psmouse->vendor, firmware_id,
> (button_info & 0xf0) >> 4, button_info & 0x0f);
>
> + if (trackpoint_is_dt_capable(ps2dev->serio->firmware_id)) {
> + error = trackpoint_write(ps2dev, TP_DOUBLETAP, TP_DOUBLETAP_ENABLE);
> + if (error)
> + psmouse_warn(psmouse, "Failed to enable doubletap: %d\n", error);
> + }
> +
> return 0;
> }
>
> diff --git a/drivers/input/mouse/trackpoint.h b/drivers/input/mouse/trackpoint.h
> index eb5412904fe0..3e03cdb39449 100644
> --- a/drivers/input/mouse/trackpoint.h
> +++ b/drivers/input/mouse/trackpoint.h
> @@ -69,6 +69,8 @@
> /* (how hard it is to drag */
> /* with Z-axis pressed) */
>
> +#define TP_DOUBLETAP 0x58 /* TrackPoint doubletap register */
> +
> #define TP_MINDRAG 0x59 /* Minimum amount of force needed */
> /* to trigger dragging */
>
> @@ -110,6 +112,9 @@
> external device will be forced to 1 */
> #define TP_MASK_EXT_TAG 0x04
>
> +/* Doubletap register values */
> +#define TP_DOUBLETAP_ENABLE 0xFF /* Enable value */
> +#define TP_DOUBLETAP_DISABLE 0xFE /* Disable value */
>
> /* Power on Self Test Results */
> #define TP_POR_SUCCESS 0x3B
>
--
i.
^ permalink raw reply
* Re: [PATCH v7 3/3] Documentation: thinkpad-acpi - Document doubletap_enable attribute
From: Ilpo Järvinen @ 2026-03-09 8:03 UTC (permalink / raw)
To: Vishnu Sankar
Cc: Mark Pearson, dmitry.torokhov, hmh, Hans de Goede, corbet,
derekjohn.clark, linux-input, LKML, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar
In-Reply-To: <20260209063355.491189-4-vishnuocv@gmail.com>
On Mon, 9 Feb 2026, Vishnu Sankar wrote:
> Document the doubletap_enable sysfs attribute for ThinkPad ACPI driver.
>
> Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
> ---
> + * 1 - doubletap events are processed (default)
> + * 0 - doubletap events are filtered out (ignored)
There's something odd in space vs tab here.
--
i.
^ permalink raw reply
* Re: [6.18.] ThinkPad T14 Gen 2 AMD (LEN2073) - Synaptics touchpad remains PS/2, intertouch=1 ineffective, lost sync events
From: Thorsten Leemhuis @ 2026-03-09 8:12 UTC (permalink / raw)
To: Rácz Máté, linux-input, linux-i2c
Cc: Linux kernel regressions list
In-Reply-To: <CANkKV93wfs7oxU8kiyPWeafOs+ugpZSPLQrea7wtoSuGEG+pPw@mail.gmail.com>
Hi!
On 3/5/26 19:07, Rácz Máté wrote:
>
> I did some additional checks on my system with kernel 6.18.13-200.fc43.x86_64:
Have you tried if 7.0-rc is still affected?
And if it is: could you bisect? See
https://docs.kernel.org/admin-guide/bug-bisect.html
for details. Without a bisection developers developers from both
subsystems involved (i2c, input) might not look into this, as everyone
will suspect it might be some change to the other subsystems that causes
this.
Ciao, Thorsten
> 1. Kernel configuration (relevant parts):
>
> $ grep -i "RMI\|SMBus" /boot/config-$(uname -r)
> CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y
> CONFIG_RMI4_CORE=m
> CONFIG_RMI4_I2C=m
> CONFIG_RMI4_SMB=m
> CONFIG_HID_RMI=m
> CONFIG_I2C_HID=y
> CONFIG_I2C_HID_ACPI=m
>
> 2. dmesg output (filtered):
>
> [ 1.615300] psmouse serio1: synaptics: Trying to set up SMBus access
> [ 1.618151] psmouse serio1: synaptics: SMbus companion is not ready yet
> [ 17.949336] psmouse serio1: TouchPad at isa0060/serio1/input0 lost
> sync at byte 1
> [ 17.962506] psmouse serio1: issuing reconnect request
> (repeats multiple times)
>
> 3. libinput reports:
>
> $ sudo libinput list-devices | grep -i SynPS
> Device: SynPS/2 Synaptics TouchPad
>
> Interpretation:
>
> - The touchpad is recognized as a SynPS/2 device, i.e., fallback PS/2 mode.
> - SMBus/RMI4 driver stack does not get loaded, despite the kernel
> config enabling modules.
> - The "SMBus companion is not ready yet" messages indicate that
> psmouse attempts SMBus access but cannot reach the device.
> - I2C controllers are functional, yet the touchpad does not enumerate
> as an I2C HID device.
>
> Workarounds:
>
> - Using psmouse.proto=imps avoids lost sync events, confirming
> fallback to generic PS/2 handling.
>
> Observation regarding previous reports:
>
> - Unlike the 2021 report on ThinkPad P14s Gen 2 (AMD), I do not see
> any "bad SMBus base address" messages in dmesg.
> - The kernel attempts SMBus access, but fails because the RMI4/hid-rmi
> stack does not initialize. The device simply falls back to PS/2 mode.
> - Therefore, this does not appear to be the same base address issue as
> the earlier P14s case.
>
> Conclusion:
>
> - Behavior strongly suggests a missing DMI quirk or regression in the
> SMBus detection logic in combination with i2c_piix4 on this Lenovo
> ThinkPad T14 Gen 2 (AMD) with LEN2073 touchpad.
> - This is reproducible on multiple 6.18.x kernel versions on Fedora 43
> stock kernels.
>
> I can provide full dmesg, libinput outputs, and acpidump if required.
>
> Best regards,
> Mate Racz
>
> Rácz Máté <raczm0812@gmail.com> ezt írta (időpont: 2026. márc. 4., Sze, 16:02):
>>
>> This might be related to the earlier report from 2021:
>>
>> https://lore.kernel.org/linux-input/3d6f7f74-3214-4c03-b352-a2a0d27ea42b@amd.com/
>>
>> and a similar report from 2025:
>>
>> https://lore.kernel.org/linux-input/b2d0af40-876e-4a2d-99a2-236b583e9497@gmail.com/
>>
>> The 2021 report describes incorrect SMBus address detection with
>> i2c_piix4 on ThinkPad P14s Gen 2 (AMD), resulting in RMI4/SMBus not
>> functioning correctly and the device remaining in PS/2 mode.
>>
>> On my system (LEN2073), the behaviour appears very similar:
>> - intertouch has no effect
>> - "SMBus companion is not ready yet" in dmesg
>> - device stays in PS/2 mode
>>
>> It seems possible that the same underlying piix4 SMBus detection
>> issue is still present.
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Add support for HID++ Multi-Platform feature (0x4531)
From: Bastien Nocera @ 2026-03-09 9:53 UTC (permalink / raw)
To: DevExalt, jikos, bentiss
Cc: lains, linux-input, linux-kernel, sari.kreitem, hbarnor
In-Reply-To: <20251215125319.33261-1-exalt.dev.team@gmail.com>
Hey,
Sorry for not looking at this earlier, it slipped through the cracks as
it arrived on the mailing-list as I was away.
On Mon, 2025-12-15 at 14:53 +0200, DevExalt wrote:
> From: "Baraa Atta (Dev Exalt)" <exalt.dev.team@gmail.com>
>
> Add support in the Logitech HID++ driver for the HID++ Multi-Platform
> feature (0x4531), which enables HID++ devices to adjust their
> behavior
> based on the host operating system (Linux, ChromeOS, Android).
Can you please explain what the feature actually does ? (the Logitech
docs say "Set the right keyboard layout for your computer operating
system" and mention that some multimedia keys are inoperable unless a
compatible OS is set).
>
> This patch:
> * Adds device IDs for MX Keys S (046d:b378) and Casa Keys
> (046d:b371).
> * Introduces the module parameter "hidpp_platform" to allow
> selecting a
> target platform.
> * Detects whether a device implements feature 0x4531.
> * Validates that the requested platform is supported by the device.
> * Applies the platform index when valid, otherwise leaves the device
> unchanged.
> * Keeps default behavior when "hidpp_platform" is unset or invalid.
Can you explain the benefits of setting this module parameter, compared
to using the keyboard shortcuts to switch to a specific OS
configuration?
What happens when 2 Logitech devices with different supported OSes are
used?
> Supported values for hidpp_platform:
> Android, Linux, Chrome
Any reason why there aren't more supported OSes?
The Logitech docs[1] lists:
WebOS iOS MacOS Android Chrome Linux WinEmb Windows Tizen
as possible values.
[1]:
https://drive.google.com/file/d/1KyiBA5m_5V1s6jQ9eQrgRJN0SbbbI9_I/view
I recently got a K980 which has this functionality, it only documents
Windows, macOS and Chrome, but Solaar also lists Linux as an option.
So my questions would be:
- why not support the whole range of possible OSes in this option?
- why is it a module option instead of, say, a sysfs attribute that
could be changed per device?
- why not implement this in user-space through a udev callout?
Cheers
>
> TEST=Pair MX Keys S and Casa Keys over Bluetooth and verify:
> * Feature 0x4531 is detected.
> * Valid platform values are accepted and applied.
> * Invalid platform values result in no update.
> * Devices without 0x4531 retain default behavior.
> * Platform-specific key behavior is observed once applied.
>
> Signed-off-by: Baraa Atta (Dev Exalt) <exalt.dev.team@gmail.com>
> ---
> drivers/hid/hid-ids.h | 2 +
> drivers/hid/hid-logitech-hidpp.c | 280
> +++++++++++++++++++++++++++++++
> drivers/hid/hid-quirks.c | 2 +
> 3 files changed, 284 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index d31711f1aaec..12de1194d7fa 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -866,6 +866,8 @@
> #define USB_DEVICE_ID_LOGITECH_T651 0xb00c
> #define USB_DEVICE_ID_LOGITECH_DINOVO_EDGE_KBD 0xb309
> #define USB_DEVICE_ID_LOGITECH_CASA_TOUCHPAD 0xbb00
> +#define USB_DEVICE_ID_LOGITECH_CASA_KEYS_KEYBOARD 0xb371
> +#define USB_DEVICE_ID_LOGITECH_MX_KEYS_S_KEYBOARD 0xb378
> #define USB_DEVICE_ID_LOGITECH_C007 0xc007
> #define USB_DEVICE_ID_LOGITECH_C077 0xc077
> #define USB_DEVICE_ID_LOGITECH_RECEIVER 0xc101
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-
> logitech-hidpp.c
> index d5011a5d0890..e94daed31981 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -4373,6 +4373,280 @@ static bool hidpp_application_equals(struct
> hid_device *hdev,
> return report && report->application == application;
> }
>
> +/* -----------------------------------------------------------------
> --------- */
> +/* 0x4531: Multi-Platform
> Support */
> +/* -----------------------------------------------------------------
> --------- */
> +
> +/*
> + * Some Logitech devices expose the HID++ feature 0x4531 (Multi-
> Platform) allowing
> + * the host to specify which operating system platform to use on the
> device. Changing device's
> + * platform may alter the behavior of the device to match the
> specified platform.
> + */
> +
> +static char *hidpp_platform;
> +module_param(hidpp_platform, charp, 0644);
> +MODULE_PARM_DESC(hidpp_platform, "Select host platform type for
> Logitech HID++ Multi-Platform feature "
> + "0x4531, valid values: (linux|chrome|android). If
> unset, no "
> + "change is applied.");
> +
> +#define HIDPP_MULTIPLATFORM_FEAT_ID 0x4531
> +#define HIDPP_MULTIPLATFORM_GET_FEATURE_INFO 0x0F
> +#define HIDPP_MULTIPLATFORM_GET_PLATFORM_DESCRIPTOR 0x1F
> +#define HIDPP_MULTIPLATFORM_SET_CURRENT_PLATFORM 0x3F
> +
> +#define
> HIDPP_MULTIPLATFORM_PLATFORM_MASK_LINUX BIT(10)
> +#define HIDPP_MULTIPLATFORM_PLATFORM_MASK_CHROME BIT(11)
> +#define HIDPP_MULTIPLATFORM_PLATFORM_MASK_ANDROID BIT(12)
> +
> +struct hidpp_platform_desc {
> + u8 plat_idx;
> + u8 desc_idx;
> + u16 plat_mask;
> +};
> +
> +/**
> + * hidpp_multiplatform_mask_from_str() - Convert platform name to an
> HID++ platform mask
> + * @pname: Platform name string
> + *
> + * Converts a platform name string to its corresponding HID++
> platform mask based on
> + * the Multi-Platform feature specification.
> + *
> + * Return: Platform mask corresponding to @pname on success,
> + * or 0 if @pname is NULL or unsupported.
> + */
> +static u16 hidpp_multiplatform_mask_from_str(const char *pname)
> +{
> + if (!pname)
> + return 0;
> +
> + if (!strcasecmp(pname, "linux"))
> + return HIDPP_MULTIPLATFORM_PLATFORM_MASK_LINUX;
> + if (!strcasecmp(pname, "chrome"))
> + return HIDPP_MULTIPLATFORM_PLATFORM_MASK_CHROME;
> + if (!strcasecmp(pname, "android"))
> + return HIDPP_MULTIPLATFORM_PLATFORM_MASK_ANDROID;
> +
> + return 0;
> +}
> +
> +/**
> + * hidpp_multiplatform_get_num_pdesc() - Retrieve number of platform
> descriptors
> + * @hidpp: Pointer to the hidpp_device instance
> + * @feat_index: Feature index of the Multi-Platform feature
> + * @num_desc: Pointer to store the number of platform descriptors
> + *
> + * Retrieves the number of platform descriptors supported by the
> device through
> + * the Multi-Platform feature and stores it in @num_desc.
> + *
> + * Return: 0 on success, or non-zero on failure.
> + */
> +static int hidpp_multiplatform_get_num_pdesc(struct hidpp_device
> *hidpp,
> + u8 feat_index, u8
> *num_desc)
> +{
> + int ret;
> + struct hidpp_report response;
> + struct hid_device *hdev = hidpp->hid_dev;
> +
> + ret = hidpp_send_fap_command_sync(hidpp, feat_index,
> +
> HIDPP_MULTIPLATFORM_GET_FEATURE_INFO,
> + NULL, 0, &response);
> + if (ret) {
> + hid_warn(hdev, "Multiplatform: GET_FEATURE_INFO
> failed (err=%d)", ret);
> + return ret;
> + }
> +
> + *num_desc = response.fap.params[3];
> + hid_dbg(hdev, "Multiplatform: Device supports %d platform
> descriptors", *num_desc);
> +
> + return 0;
> +}
> +
> +/**
> + * hidpp_multiplatform_get_platform_desc() - Retrieve a platform
> descriptor entry
> + * @hidpp: Pointer to the hidpp_device instance
> + * @feat_index: Feature index of the Multi-Platform feature
> + * @platform_idx: Index of the platform descriptor to retrieve
> + * @pdesc: Pointer to store the retrieved platform descriptor
> + *
> + * Retrieves a single platform descriptor identified by
> @platform_idx from the
> + * device and stores the parsed descriptor fields in @pdesc.
> + *
> + * Return: 0 on success, or non-zero on failure.
> + */
> +static int hidpp_multiplatform_get_platform_desc(struct hidpp_device
> *hidpp, u8 feat_index,
> + u8 platform_idx,
> struct hidpp_platform_desc *pdesc)
> +{
> + int ret;
> + struct hidpp_report response;
> + u8 params[1] = { platform_idx };
> + struct hid_device *hdev = hidpp->hid_dev;
> +
> + ret = hidpp_send_fap_command_sync(hidpp, feat_index,
> +
> HIDPP_MULTIPLATFORM_GET_PLATFORM_DESCRIPTOR,
> + params, sizeof(params),
> &response);
> +
> + if (ret) {
> + hid_warn(hdev,
> + "Multiplatform: GET_PLATFORM_DESCRIPTOR
> failed for index %d (err=%d)",
> + platform_idx, ret);
> + return ret;
> + }
> +
> + pdesc->plat_idx = response.fap.params[0];
> + pdesc->desc_idx = response.fap.params[1];
> + pdesc->plat_mask =
> get_unaligned_be16(&response.fap.params[2]);
> +
> + hid_dbg(hdev,
> + "Multiplatform: descriptor %d: plat_idx=%d,
> desc_idx=%d, plat_mask=0x%04x",
> + platform_idx, pdesc->plat_idx, pdesc->desc_idx,
> pdesc->plat_mask);
> +
> + return 0;
> +}
> +
> +/**
> + * hidpp_multiplatform_get_platform_index() - Find platform index
> for a mask
> + * @hidpp: Pointer to the hidpp_device instance
> + * @feat_index: Feature index of the Multi-Platform feature
> + * @plat_mask: Platform mask to search for
> + * @plat_index: Pointer to store the matched platform index
> + *
> + * Iterates through all platform descriptors exposed by the device
> via the
> + * Multi-Platform feature, retrieving each descriptor and comparing
> its
> + * platform mask to @plat_mask. A descriptor matches if its mask
> overlaps with
> + * the requested @plat_mask (i.e. (pdesc.plat_mask & plat_mask) is
> non-zero).
> + *
> + * When a matching descriptor is found, its platform index
> (plat_idx) is
> + * written to @plat_index and the function returns success.
> + *
> + * If no descriptor matches, -ENOENT is returned.
> + *
> + * Return: 0 on success; -ENOENT if no matching descriptor exists;
> + * or non-zero on failure.
> + */
> +static int hidpp_multiplatform_get_platform_index(struct
> hidpp_device *hidpp,
> + u8 feat_index, u16
> plat_mask,
> + u8 *plat_index)
> +{
> + int i;
> + int ret;
> + u8 num_desc;
> + struct hidpp_platform_desc pdesc;
> + struct hid_device *hdev = hidpp->hid_dev;
> +
> + ret = hidpp_multiplatform_get_num_pdesc(hidpp, feat_index,
> &num_desc);
> + if (ret)
> + return ret;
> +
> + for (i = 0; i < num_desc; i++) {
> + ret = hidpp_multiplatform_get_platform_desc(hidpp,
> feat_index, i, &pdesc);
> + if (ret)
> + return ret;
> +
> + if (pdesc.plat_mask & plat_mask) {
> + *plat_index = pdesc.plat_idx;
> + hid_dbg(hdev,
> + "Multiplatform: Selected platform
> index %d for platform '%s'",
> + *plat_index, hidpp_platform);
> + return 0;
> + }
> + }
> +
> + hid_dbg(hdev,
> + "Multiplatform: No matching platform descriptor
> found for platform '%s'",
> + hidpp_platform);
> + return -ENOENT;
> +}
> +
> +/**
> + * hidpp_multiplatform_update_device_platform() - Update the device
> platform
> + * @hidpp: Pointer to the hidpp_device instance
> + * @feat_index: Feature index of the Multi-Platform feature
> + * @plat_index: Platform index to set on the device
> + *
> + * Sends the HID++ Multi-Platform 'SET_CURRENT_PLATFORM' command to
> the device to
> + * update its platform index to @plat_index.
> + *
> + * Return: 0 on success, or non-zero on failure.
> + */
> +static int hidpp_multiplatform_update_device_platform(struct
> hidpp_device *hidpp,
> + u8 feat_index,
> u8 plat_index)
> +{
> + int ret;
> + struct hidpp_report response;
> + /* Byte 0 (hostIndex): 0xFF selects the current host. */
> + u8 params[2] = { 0xFF, plat_index };
> +
> + ret = hidpp_send_fap_command_sync(hidpp, feat_index,
> +
> HIDPP_MULTIPLATFORM_SET_CURRENT_PLATFORM,
> + params, sizeof(params),
> &response);
> +
> + if (ret)
> + hid_warn(hidpp->hid_dev,
> + "Multiplatform: SET_CURRENT_PLATFORM failed
> for index %d (err=%d)",
> + plat_index, ret);
> +
> + return ret;
> +}
> +
> +/**
> + * hidpp_multiplatform_init() - Apply the HID++ Multi-Platform
> (0x4531) feature
> + * @hidpp: Pointer to the hidpp_device instance
> + *
> + * Initializes the Multi-Platform feature by selecting the device
> platform
> + * corresponding to the module parameter @hidpp_platform, if
> provided.
> + *
> + * The function performs the following steps:
> + * 1. Convert the @hidpp_platform string into a platform mask.
> + * 2. Check whether the device supports the Multi-Platform feature
> (0x4531).
> + * 3. Look up the device's platform index whose mask matches the
> host
> + * platform mask.
> + * 4. Apply that platform index to the device via
> 'SET_CURRENT_PLATFORM'.
> + *
> + * If the module parameter is unset or invalid, or the device does
> not support
> + * the feature, or no matching platform descriptor is found, the
> function exits
> + * silently without modifying the device state.
> + *
> + * On success, the device's platform configuration is updated.
> + */
> +static void hidpp_multiplatform_init(struct hidpp_device *hidpp)
> +{
> + int ret;
> + u8 feat_index;
> + u8 plat_index;
> + u16 host_plat_mask;
> + struct hid_device *hdev = hidpp->hid_dev;
> +
> + if (!hidpp_platform)
> + return;
> +
> + host_plat_mask =
> hidpp_multiplatform_mask_from_str(hidpp_platform);
> + if (!host_plat_mask) {
> + hid_warn(hdev,
> + "Multiplatform: Invalid or unsupported
> platform name '%s'",
> + hidpp_platform);
> + return;
> + }
> +
> + ret = hidpp_root_get_feature(hidpp,
> HIDPP_MULTIPLATFORM_FEAT_ID, &feat_index);
> + if (ret) {
> + hid_warn(hdev,
> + "Multiplatform: Failed to get the HID++
> multiplatform feature 0x4531");
> + return;
> + }
> +
> + ret = hidpp_multiplatform_get_platform_index(hidpp,
> feat_index, host_plat_mask,
> + &plat_index);
> + if (ret)
> + return;
> +
> + ret = hidpp_multiplatform_update_device_platform(hidpp,
> feat_index, plat_index);
> + if (ret)
> + return;
> +
> + hid_info(hdev,
> + "Multiplatform: Device platform successfully set to
> '%s'", hidpp_platform);
> +}
> +
> static int hidpp_probe(struct hid_device *hdev, const struct
> hid_device_id *id)
> {
> struct hidpp_device *hidpp;
> @@ -4467,6 +4741,8 @@ static int hidpp_probe(struct hid_device *hdev,
> const struct hid_device_id *id)
> if (hidpp->quirks & HIDPP_QUIRK_DELAYED_INIT)
> connect_mask &= ~HID_CONNECT_HIDINPUT;
>
> + hidpp_multiplatform_init(hidpp);
> +
> /* Now export the actual inputs and hidraw nodes to the
> world */
> hid_device_io_stop(hdev);
> ret = hid_connect(hdev, connect_mask);
> @@ -4664,6 +4940,10 @@ static const struct hid_device_id
> hidpp_devices[] = {
> HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb034) },
> { /* MX Anywhere 3SB mouse over Bluetooth */
> HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
> + { /* Casa Keys keyboard over Bluetooth */
> + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> USB_DEVICE_ID_LOGITECH_CASA_KEYS_KEYBOARD) },
> + { /* MX Keys S keyboard over Bluetooth */
> + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> USB_DEVICE_ID_LOGITECH_MX_KEYS_S_KEYBOARD) },
> {}
> };
>
> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> index c89a015686c0..99ca04b61bda 100644
> --- a/drivers/hid/hid-quirks.c
> +++ b/drivers/hid/hid-quirks.c
> @@ -520,6 +520,8 @@ static const struct hid_device_id
> hid_have_special_driver[] = {
> #endif
> #if IS_ENABLED(CONFIG_HID_LOGITECH_HIDPP)
> { HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
> USB_DEVICE_ID_LOGITECH_G920_WHEEL) },
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> USB_DEVICE_ID_LOGITECH_CASA_KEYS_KEYBOARD) },
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
> USB_DEVICE_ID_LOGITECH_MX_KEYS_S_KEYBOARD) },
> #endif
> #if IS_ENABLED(CONFIG_HID_MAGICMOUSE)
> { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
> USB_DEVICE_ID_APPLE_MAGICMOUSE) },
^ permalink raw reply
* [PATCH 0/2] Input: tsc200x: Improve wakeup source handling
From: phucduc.bui @ 2026-03-09 11:00 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, Ingo Molnar, Thomas Gleixner,
Marek Vasut, Michael Welling, linux-input, devicetree,
linux-kernel, phucduc.bui
From: bui duc phuc <phucduc.bui@gmail.com>
The tsc200x driver already uses device_init_wakeup() to read the
"wakeup-source" property from the Device Tree. However, this property
is currently not documented in the DT binding schema.
In addition, the I2C core already handles wakeup initialization and
IRQ wake management automatically when the "wakeup-source" property
is present. Therefore, the manual wakeup IRQ handling currently done
in the driver is redundant for I2C-based devices (TSC2004).
This series makes the following changes:
1. Document the "wakeup-source" property in the DT bindings.
2. Delegate wakeup IRQ management to the I2C core when running on
BUS_I2C, while keeping manual management for BUS_SPI (TSC2005)
to ensure correct behavior across both interfaces.
Note:
These changes are based on code inspection and the documented behavior
of the I2C core. They have not been tested on physical hardware yet.
bui duc phuc (2):
dt-bindings: input: touchscreen: ti,tsc2005: Add wakeup-source
Input: Touchscreen: tsc200x - delegate wakeup IRQ management to I2C
core
.../bindings/input/touchscreen/ti,tsc2005.yaml | 7 +++++++
drivers/input/touchscreen/tsc200x-core.c | 18 +++++++++++++-----
2 files changed, 20 insertions(+), 5 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/2] dt-bindings: input: touchscreen: ti,tsc2005: Add wakeup-source
From: phucduc.bui @ 2026-03-09 11:00 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, Ingo Molnar, Thomas Gleixner,
Marek Vasut, Michael Welling, linux-input, devicetree,
linux-kernel, phucduc.bui
In-Reply-To: <20260309110045.108209-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
The tsc200x driver uses the "wakeup-source" device tree property to
determine whether the device should be configured as a system wakeup
source.
In the driver, this property is read with:
device_init_wakeup(dev,
device_property_read_bool(dev, "wakeup-source"));
Document this property in the binding to make it visible to DT schema
validation tools and to clarify its usage in device tree descriptions.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
.../devicetree/bindings/input/touchscreen/ti,tsc2005.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
index 7187c390b2f5..c0aae044d7d4 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti,tsc2005.yaml
@@ -55,6 +55,9 @@ properties:
touchscreen-size-x: true
touchscreen-size-y: true
+ wakeup-source:
+ type: boolean
+
allOf:
- $ref: touchscreen.yaml#
- if:
@@ -97,6 +100,8 @@ examples:
ti,x-plate-ohms = <280>;
ti,esd-recovery-timeout-ms = <8000>;
+
+ wakeup-source;
};
};
- |
@@ -124,5 +129,7 @@ examples:
ti,x-plate-ohms = <280>;
ti,esd-recovery-timeout-ms = <8000>;
+
+ wakeup-source;
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] Input: Touchscreen: tsc200x - delegate wakeup IRQ management to I2C core
From: phucduc.bui @ 2026-03-09 11:00 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, Ingo Molnar, Thomas Gleixner,
Marek Vasut, Michael Welling, linux-input, devicetree,
linux-kernel, phucduc.bui
In-Reply-To: <20260309110045.108209-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
The tsc200x driver supports both I2C (tsc2004) and SPI (tsc2005)
interfaces.
Currently, the driver attempts to manually manage the wakeup interrupt by
calling enable_irq_wake() and disable_irq_wake() during suspend and resume.
However, for I2C devices, the I2C core already automatically handles the
wakeup source initialization and IRQ management if the "wakeup-source"
property is present in the device tree. Manually managing it again in the
driver is redundant and can lead to unbalanced IRQ wake reference counts.
Clean up the wakeup IRQ handling by checking the bus type:
- For I2C (BUS_I2C): Rely entirely on the I2C core for wakeup management.
- For SPI (BUS_SPI): Explicitly call device_init_wakeup() in probe and
manually manage enable/disable_irq_wake() during suspend/resume.
The ts->wake_irq_enabled flag is also updated accordingly to ensure the
driver accurately tracks the wakeup state across both buses.
Note: This patch is based on code analysis of the I2C subsystem and
has not been verified on actual hardware yet.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
drivers/input/touchscreen/tsc200x-core.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/tsc200x-core.c b/drivers/input/touchscreen/tsc200x-core.c
index eba53613b005..d14d967845c8 100644
--- a/drivers/input/touchscreen/tsc200x-core.c
+++ b/drivers/input/touchscreen/tsc200x-core.c
@@ -465,6 +465,7 @@ int tsc200x_probe(struct device *dev, int irq, const struct input_id *tsc_id,
ts->idev = input_dev;
ts->regmap = regmap;
ts->tsc200x_cmd = tsc200x_cmd;
+ ts->bustype = tsc_id->bustype;
error = device_property_read_u32(dev, "ti,x-plate-ohms", &x_plate_ohm);
ts->x_plate_ohm = error ? TSC200X_DEF_RESISTOR : x_plate_ohm;
@@ -547,8 +548,9 @@ int tsc200x_probe(struct device *dev, int irq, const struct input_id *tsc_id,
return error;
}
- device_init_wakeup(dev,
- device_property_read_bool(dev, "wakeup-source"));
+ if (ts->bustype == BUS_SPI)
+ device_init_wakeup(dev,
+ device_property_read_bool(dev, "wakeup-source"));
return 0;
}
@@ -565,8 +567,13 @@ static int tsc200x_suspend(struct device *dev)
ts->suspended = true;
- if (device_may_wakeup(dev))
- ts->wake_irq_enabled = enable_irq_wake(ts->irq) == 0;
+ if (device_may_wakeup(dev)) {
+ if (ts->bustype == BUS_SPI)
+ ts->wake_irq_enabled = enable_irq_wake(ts->irq) == 0;
+ else
+ ts->wake_irq_enabled = true;
+ } else
+ ts->wake_irq_enabled = false;
return 0;
}
@@ -578,7 +585,8 @@ static int tsc200x_resume(struct device *dev)
guard(mutex)(&ts->mutex);
if (ts->wake_irq_enabled) {
- disable_irq_wake(ts->irq);
+ if (ts->bustype == BUS_SPI)
+ disable_irq_wake(ts->irq);
ts->wake_irq_enabled = false;
}
--
2.43.0
^ permalink raw reply related
* Re: [6.18.] ThinkPad T14 Gen 2 AMD (LEN2073) - Synaptics touchpad remains PS/2, intertouch=1 ineffective, lost sync events
From: Rácz Máté @ 2026-03-09 11:54 UTC (permalink / raw)
To: Thorsten Leemhuis; +Cc: linux-input, linux-i2c, Linux kernel regressions list
In-Reply-To: <68d90523-33dc-451f-a825-72eaa1c4bcb8@leemhuis.info>
Hi Thorsten,
Thanks for the response.
I have not yet tested with 7.0-rc, but I will try building and booting the
latest mainline release candidate and report whether the issue is still
present.
One additional observation: the touchpad PNP ID on this system is
LEN2073. I noticed that this ID does not appear in the Synaptics SMBus
whitelist in drivers/input/mouse/synaptics.c.
Because of this I am wondering whether the device might simply be
missing from the whitelist rather than this being a regression.
I'll first verify the behaviour on 7.0-rc and then investigate further
(if needed I can also attempt a bisect).
Best regards,
Mate
Thorsten Leemhuis <regressions@leemhuis.info> ezt írta (időpont: 2026.
márc. 9., H, 9:12):
>
> Hi!
>
> On 3/5/26 19:07, Rácz Máté wrote:
> >
> > I did some additional checks on my system with kernel 6.18.13-200.fc43.x86_64:
>
> Have you tried if 7.0-rc is still affected?
>
> And if it is: could you bisect? See
> https://docs.kernel.org/admin-guide/bug-bisect.html
> for details. Without a bisection developers developers from both
> subsystems involved (i2c, input) might not look into this, as everyone
> will suspect it might be some change to the other subsystems that causes
> this.
>
> Ciao, Thorsten
>
> > 1. Kernel configuration (relevant parts):
> >
> > $ grep -i "RMI\|SMBus" /boot/config-$(uname -r)
> > CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y
> > CONFIG_RMI4_CORE=m
> > CONFIG_RMI4_I2C=m
> > CONFIG_RMI4_SMB=m
> > CONFIG_HID_RMI=m
> > CONFIG_I2C_HID=y
> > CONFIG_I2C_HID_ACPI=m
> >
> > 2. dmesg output (filtered):
> >
> > [ 1.615300] psmouse serio1: synaptics: Trying to set up SMBus access
> > [ 1.618151] psmouse serio1: synaptics: SMbus companion is not ready yet
> > [ 17.949336] psmouse serio1: TouchPad at isa0060/serio1/input0 lost
> > sync at byte 1
> > [ 17.962506] psmouse serio1: issuing reconnect request
> > (repeats multiple times)
> >
> > 3. libinput reports:
> >
> > $ sudo libinput list-devices | grep -i SynPS
> > Device: SynPS/2 Synaptics TouchPad
> >
> > Interpretation:
> >
> > - The touchpad is recognized as a SynPS/2 device, i.e., fallback PS/2 mode.
> > - SMBus/RMI4 driver stack does not get loaded, despite the kernel
> > config enabling modules.
> > - The "SMBus companion is not ready yet" messages indicate that
> > psmouse attempts SMBus access but cannot reach the device.
> > - I2C controllers are functional, yet the touchpad does not enumerate
> > as an I2C HID device.
> >
> > Workarounds:
> >
> > - Using psmouse.proto=imps avoids lost sync events, confirming
> > fallback to generic PS/2 handling.
> >
> > Observation regarding previous reports:
> >
> > - Unlike the 2021 report on ThinkPad P14s Gen 2 (AMD), I do not see
> > any "bad SMBus base address" messages in dmesg.
> > - The kernel attempts SMBus access, but fails because the RMI4/hid-rmi
> > stack does not initialize. The device simply falls back to PS/2 mode.
> > - Therefore, this does not appear to be the same base address issue as
> > the earlier P14s case.
> >
> > Conclusion:
> >
> > - Behavior strongly suggests a missing DMI quirk or regression in the
> > SMBus detection logic in combination with i2c_piix4 on this Lenovo
> > ThinkPad T14 Gen 2 (AMD) with LEN2073 touchpad.
> > - This is reproducible on multiple 6.18.x kernel versions on Fedora 43
> > stock kernels.
> >
> > I can provide full dmesg, libinput outputs, and acpidump if required.
> >
> > Best regards,
> > Mate Racz
> >
> > Rácz Máté <raczm0812@gmail.com> ezt írta (időpont: 2026. márc. 4., Sze, 16:02):
> >>
> >> This might be related to the earlier report from 2021:
> >>
> >> https://lore.kernel.org/linux-input/3d6f7f74-3214-4c03-b352-a2a0d27ea42b@amd.com/
> >>
> >> and a similar report from 2025:
> >>
> >> https://lore.kernel.org/linux-input/b2d0af40-876e-4a2d-99a2-236b583e9497@gmail.com/
> >>
> >> The 2021 report describes incorrect SMBus address detection with
> >> i2c_piix4 on ThinkPad P14s Gen 2 (AMD), resulting in RMI4/SMBus not
> >> functioning correctly and the device remaining in PS/2 mode.
> >>
> >> On my system (LEN2073), the behaviour appears very similar:
> >> - intertouch has no effect
> >> - "SMBus companion is not ready yet" in dmesg
> >> - device stays in PS/2 mode
> >>
> >> It seems possible that the same underlying piix4 SMBus detection
> >> issue is still present.
>
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
From: Hendrik Noack @ 2026-03-09 12:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ferass El Hafidi, linux-input, devicetree, linux-kernel
In-Reply-To: <20260308-vivacious-coucal-of-current-2d7ac8@quoll>
Hello Krzysztof,
08.03.2026 10:15:35 Krzysztof Kozlowski <krzk@kernel.org>:
> You received review and instruction what to do. Did you read it?
I read the review of Dmitry and incorporated it into this version.
> Your way of organizing your work makes it difficult for us. Look, try
> yourself:
>
> b4 diff '20260307181557.66927-2-hendrik-noack@gmx.de'
> Checking for older revisions
> Grabbing search results from lore.kernel.org
> Added from v3: 2 patches
> ---
> Analyzing 16 messages in the thread
> Preparing fake-am for v3: dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
> ERROR: v3 series incomplete; unable to create a fake-am range
> ---
> Could not create fake-am range for lower series v3
>
>
> Best regards,
> Krzysztof
The b4 diff error might happen because git didn't add the v3 label on
the 2/2 patch of v3. First running b4 diff on v3 with:
b4 diff '20251205152858.14415-2-hendrik-noack@gmx.de
resulted in a working diff on v4:
b4 diff '20260307181557.66927-2-hendrik-noack@gmx.de'
Grabbing thread from lore.kernel.org/all/20260307181557.66927-2-hendrik-noack@gmx.de/t.mbox.gz
Checking for older revisions
Grabbing search results from lore.kernel.org
Added from v3: 2 patches
---
Analyzing 17 messages in the thread
---
Diffing v3 and v4
Running: git range-diff c371c3410e81..d467d6770a1b 0bfd1357fb44..1c9f51e8b572
---
...
Best regards,
Hendrik
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
From: Krzysztof Kozlowski @ 2026-03-09 12:56 UTC (permalink / raw)
To: Hendrik Noack
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ferass El Hafidi, linux-input, devicetree, linux-kernel
In-Reply-To: <feae85c4-bea1-40b2-87d5-952b26ff3ee3@gmx.de>
On 09/03/2026 13:54, Hendrik Noack wrote:
> Hello Krzysztof,
>
> 08.03.2026 10:15:35 Krzysztof Kozlowski <krzk@kernel.org>:
>
>> You received review and instruction what to do. Did you read it?
>
> I read the review of Dmitry and incorporated it into this version.
So you ignored my email completely or it did not reach you (it is on
lore.kernel.org though)?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
From: Hendrik Noack @ 2026-03-09 13:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ferass El Hafidi, linux-input, devicetree, linux-kernel
In-Reply-To: <fddf0e3b-707e-41b3-805b-2abeffed6c05@kernel.org>
Hello Krzysztof,
09.03.2026 13:56:41 Krzysztof Kozlowski <krzk@kernel.org>:
> On 09/03/2026 13:54, Hendrik Noack wrote:
>> Hello Krzysztof,
>>
>> 08.03.2026 10:15:35 Krzysztof Kozlowski <krzk@kernel.org>:
>>
>>> You received review and instruction what to do. Did you read it?
>>
>> I read the review of Dmitry and incorporated it into this version.
>
> So you ignored my email completely or it did not reach you (it is on
> lore.kernel.org though)?
I don't know what email you mean. You gave reviews on my first verison, which I already incorporated in v2 and then gave a review-by on v2, which I also added on v3, but now dropped, because I added a property to the DT binding.
Best regards,
Hendrik
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: Input: Add Wacom W9000-series penabled touchscreens
From: Krzysztof Kozlowski @ 2026-03-09 13:21 UTC (permalink / raw)
To: Hendrik Noack
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ferass El Hafidi, linux-input, devicetree, linux-kernel
In-Reply-To: <f067754d-229c-4418-a367-6df5feb6cee0@gmx.de>
On 09/03/2026 14:12, Hendrik Noack wrote:
> Hello Krzysztof,
>
> 09.03.2026 13:56:41 Krzysztof Kozlowski <krzk@kernel.org>:
>
>> On 09/03/2026 13:54, Hendrik Noack wrote:
>>> Hello Krzysztof,
>>>
>>> 08.03.2026 10:15:35 Krzysztof Kozlowski <krzk@kernel.org>:
>>>
>>>> You received review and instruction what to do. Did you read it?
>>>
>>> I read the review of Dmitry and incorporated it into this version.
>>
>> So you ignored my email completely or it did not reach you (it is on
>> lore.kernel.org though)?
>
> I don't know what email you mean. You gave reviews on my first verison, which I already incorporated in v2 and then gave a review-by on v2, which I also added on v3, but now dropped, because I added a property to the DT binding.
The instruction I gave you when giving review.
Please wrap your emails to standard email style, so reading will be easier.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/5] iio: buffer: fix timestamp alignment (in rare case)
From: Nuno Sá @ 2026-03-09 14:15 UTC (permalink / raw)
To: David Lechner, Jiri Kosina, Jonathan Cameron, Srinivas Pandruvada,
Nuno Sá, Andy Shevchenko, Lars Möllendorf,
Lars-Peter Clausen, Greg Kroah-Hartman
Cc: Jonathan Cameron, Lixu Zhang, Francesco Lavra, linux-input,
linux-iio, linux-kernel
In-Reply-To: <20260307-iio-fix-timestamp-alignment-v2-0-d1d48fbadbbf@baylibre.com>
On Sat, 2026-03-07 at 19:44 -0600, David Lechner wrote:
> In [1], it was pointed out that the iio_push_to_buffers_with_timestamp()
> function is not putting the timestamp at the correct offset in the scan
> buffer in rare cases where the largest scan element size is larger than
> sizeof(int64_t).
>
> [1]: https://lore.kernel.org/linux-iio/20260215162351.79f40b32@jic23-huawei/
>
> This only affected one driver, namely hid-sensor-rotation since it is
> the only driver that meets the condition. To fix things up, first we
> fix the hid-sensor-rotation driver in a way that preserves compatibility
> with the broken timestamp alignment. Then we are free to fix the core
> IIO code without affecting any users.
>
> The first patch depends on [2] which is now in iio/fixes-togreg. It
> should be OK to apply the first patch there and let the rest of the
> patches go through iio/togreg (the later patches are just preventing
> future bugs).
>
> [2]:
> https://lore.kernel.org/linux-iio/20260228-iio-fix-repeat-alignment-v2-0-d58bfaa2920d@baylibre.com/
>
> Signed-off-by: David Lechner <dlechner@baylibre.com>
> ---
LGTM,
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
> Changes in v2:
> - Don't say "HACK" in comments.
> - Cache timestamp offset instead of largest scan element size.
> - New patch to ensure size/alignment is always power of 2 bytes.
> - Link to v1:
> https://lore.kernel.org/r/20260301-iio-fix-timestamp-alignment-v1-0-1a54980bfb90@baylibre.com
>
> ---
> David Lechner (5):
> iio: orientation: hid-sensor-rotation: add timestamp hack to not break userspace
> iio: buffer: check return value of iio_compute_scan_bytes()
> iio: buffer: cache timestamp offset in scan buffer
> iio: buffer: ensure repeat alignment is a power of two
> iio: buffer: fix timestamp alignment when quaternion in scan
>
> drivers/iio/industrialio-buffer.c | 46 ++++++++++++++++++++-------
> drivers/iio/orientation/hid-sensor-rotation.c | 22 +++++++++++--
> include/linux/iio/buffer.h | 12 +++++--
> include/linux/iio/iio.h | 3 ++
> 4 files changed, 66 insertions(+), 17 deletions(-)
> ---
> base-commit: 6f25a6105c41a7d6b12986dbe80ded396a5667f8
> change-id: 20260228-iio-fix-timestamp-alignment-89ade1af458b
> prerequisite-message-id: <20260228-iio-fix-repeat-alignment-v2-0-d58bfaa2920d@baylibre.com>
> prerequisite-patch-id: e155a526d57c5759a2fcfbfca7f544cb419addfd
> prerequisite-patch-id: 6c69eaad0dd2ae69bd2745e7d387f739fc1a9ba0
>
> Best regards,
> --
> David Lechner <dlechner@baylibre.com>
^ permalink raw reply
* [RFC v3 1/2] HID: core: Mitigate potential OOB by removing bogus memset()
From: Lee Jones @ 2026-03-09 14:59 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
The memset() in hid_report_raw_event() has the good intention of
clearing out bogus data by zeroing the area from the end of the incoming
data string to the assumed end of the buffer. However, as we have
previously seen, doing so can easily result in OOB reads and writes in
the subsequent thread of execution.
The current suggestion from one of the HID maintainers is to remove the
memset() and simply return if the incoming event buffer size is not
large enough to fill the associated report.
Suggested-by Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
---
v2 -> v3: Instead of removing the check entirely, show a warning and return early
RFC query: Is it better to return SUCCESS or -EINVAL?
drivers/hid/hid-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index a5b3a8ca2fcb..da9231ca42bc 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2057,9 +2057,9 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
rsize = max_buffer_size;
if (csize < rsize) {
- dbg_hid("report %d is too short, (%d < %d)\n", report->id,
- csize, rsize);
- memset(cdata + csize, 0, rsize - csize);
+ hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %d)\n",
+ report->id, rsize, csize);
+ goto out;
}
if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
--
2.53.0.473.g4a7958ca14-goog
^ permalink raw reply related
* [RFC v3 2/2] HID: core: Check to ensure report responses match the request
From: Lee Jones @ 2026-03-09 14:59 UTC (permalink / raw)
To: lee, Jiri Kosina, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260309145942.1496072-1-lee@kernel.org>
It is possible for a malicious (or clumsy) device to respond to a
specific report's feature request using a completely different report
ID. This can cause confusion in the HID core resulting in nasty
side-effects such as OOB writes.
Add a check to ensure that the report ID in the response, matches the
one that was requested.
Signed-off-by: Lee Jones <lee@kernel.org>
---
v2 -> v3: Cover more bases by moving the check up a layer from MT to HID Core
RFC query: Is this always okay?
Should the report number always match the request?
Are there legitimate times where the two would differ?
drivers/hid/hid-core.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index da9231ca42bc..da4078554331 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2490,8 +2490,17 @@ int __hid_hw_raw_request(struct hid_device *hdev,
if (ret)
return ret;
- return hdev->ll_driver->raw_request(hdev, reportnum, buf, len,
- rtype, reqtype);
+ ret = hdev->ll_driver->raw_request(hdev, reportnum, buf, len,
+ rtype, reqtype);
+ if (ret)
+ return ret;
+
+ if (reportnum != buf[0]) {
+ hid_err(hdev, "Returned feature report did not match the request\n");
+ return -EINVAL;
+ }
+
+ return 0;
}
/**
--
2.53.0.473.g4a7958ca14-goog
^ permalink raw reply related
* Re: [PATCH 1/2] iio: hid-sensor-gyro-3d: move iio_device_register() to end of probe()
From: srinivas pandruvada @ 2026-03-09 15:42 UTC (permalink / raw)
To: Jonathan Cameron, Bhargav Joshi
Cc: jikos, dlechner, nuno.sa, andy, linux-iio, linux-kernel,
linux-input
In-Reply-To: <20260307142153.26bab5b0@jic23-huawei>
On Sat, 2026-03-07 at 14:21 +0000, Jonathan Cameron wrote:
> On Mon, 2 Mar 2026 01:00:06 +0530
> Bhargav Joshi <rougueprince47@gmail.com> wrote:
>
> > On Sun, Mar 1, 2026 at 5:15 PM Jonathan Cameron <jic23@kernel.org>
> > wrote:
> > >
> > > On Sun, 1 Mar 2026 00:43:59 +0530
> > > Bhargav Joshi <rougueprince47@gmail.com> wrote:
> > >
> > > > Currently, calling iio_device_register() before
> > > > sensor_hub_register_callback() may create a race condition
> > > > where the
> > > > device is exposed to userspace before callbacks are wired.
> > >
> > > We needs some more here on 'why' this is a problem.
> > > Whilst this is an unusual arrangement, I couldn't immediately
> > > find
> > > anything that was actually broken. It's possible data will turn
> > > up
> > > after we tear down the callbacks and before the userspace
> > > interfaces
> > > are removed, but I think that just results in dropping data.
> > > Given it's
> > > in a race anyway I don't think we care about that. The callbacks
> > > don't seem to be involved in device configuration which can go on
> > > whether
> > > or not the callbacks are registered. Maybe there is something
> > > that
> > > won't get acknowledged if they aren't in place in time?
> > >
> > > For a fix like this we'd normally want to see a clear flow that
> > > leads to a bug.
> > >
> > > Also a fixes tag so we know how far to backport.
> > >
> >
> > Hi Jonathan,
> >
> > I originally submitted the patch for the driver because calling
> > iio_device_register() before the callbacks are wired up violates
> > standard IIO LIFO ordering. I assumed this created a dangerous race
> > condition with userspace. However, as you correctly pointed out,
> > the
> > HID sensor hub safely drops those early events without crashing,
> > even
> > if it is unusual behaviour still won't have a hard crash.
> >
> > My underlying goal was simply a structural cleanup to align the
> > probe() and remove() sequences with standard IIO architecture.
> >
> > Would you like me to send a v2 of this patch with a revised commit
> > message classifying it purely as a structural cleanup (and without
> > a
> > Fixes tag), or is the current driver behavior acceptable enough
> > that I
> > should just drop this patch entirely?
>
> My gut is leave this one alone. It's a rather unusual driver in lots
> of ways, so I don't really mind one more ;)
>
> Lets see if anyone else has strong views one way or the other.
>
> Srinivas?
>
I don't see anything wrong with this. If you register callback before,
then iio_push_to_buffers_with_timestamp() can be called before
iio_device_register(), although it will not happen because nobody
powered on sensors in the hub.
Thanks,
Srinivs
> >
> > Thanks,
> > Bhargav
> >
> > > >
> > > > Move iio_device_register() to the end of the probe() function
> > > > to prevent
> > > > race condition.
> > > >
> > > > Consequently, update the error handling path in probe() and in
> > > > remove()
> > > > ensuring that iio_device_unregister() is called first to cut
> > > > off
> > > > userspace access before the hardware callbacks are removed.
> > > >
> > > > Signed-off-by: Bhargav Joshi <rougueprince47@gmail.com>
> > > > ---
> > > > drivers/iio/gyro/hid-sensor-gyro-3d.c | 20 ++++++++++---------
> > > > -
> > > > 1 file changed, 10 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c
> > > > b/drivers/iio/gyro/hid-sensor-gyro-3d.c
> > > > index c43990c518f7..8e3628cd8529 100644
> > > > --- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
> > > > +++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
> > > > @@ -333,12 +333,6 @@ static int hid_gyro_3d_probe(struct
> > > > platform_device *pdev)
> > > > return ret;
> > > > }
> > > >
> > > > - ret = iio_device_register(indio_dev);
> > > > - if (ret) {
> > > > - dev_err(&pdev->dev, "device register failed\n");
> > > > - goto error_remove_trigger;
> > > > - }
> > > > -
> > > > gyro_state->callbacks.send_event = gyro_3d_proc_event;
> > > > gyro_state->callbacks.capture_sample =
> > > > gyro_3d_capture_sample;
> > > > gyro_state->callbacks.pdev = pdev;
> > > > @@ -346,13 +340,19 @@ static int hid_gyro_3d_probe(struct
> > > > platform_device *pdev)
> > > > &gyro_state->callbacks);
> > > > if (ret < 0) {
> > > > dev_err(&pdev->dev, "callback reg failed\n");
> > > > - goto error_iio_unreg;
> > > > + goto error_remove_trigger;
> > > > + }
> > > > +
> > > > + ret = iio_device_register(indio_dev);
> > > > + if (ret) {
> > > > + dev_err(&pdev->dev, "device register failed\n");
> > > > + goto error_remove_callback;
> > > > }
> > > >
> > > > return ret;
> > > >
> > > > -error_iio_unreg:
> > > > - iio_device_unregister(indio_dev);
> > > > +error_remove_callback:
> > > > + sensor_hub_remove_callback(hsdev,
> > > > HID_USAGE_SENSOR_GYRO_3D);
> > > > error_remove_trigger:
> > > > hid_sensor_remove_trigger(indio_dev, &gyro_state-
> > > > >common_attributes);
> > > > return ret;
> > > > @@ -365,8 +365,8 @@ static void hid_gyro_3d_remove(struct
> > > > platform_device *pdev)
> > > > struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> > > > struct gyro_3d_state *gyro_state = iio_priv(indio_dev);
> > > >
> > > > - sensor_hub_remove_callback(hsdev,
> > > > HID_USAGE_SENSOR_GYRO_3D);
> > > > iio_device_unregister(indio_dev);
> > > > + sensor_hub_remove_callback(hsdev,
> > > > HID_USAGE_SENSOR_GYRO_3D);
> > > > hid_sensor_remove_trigger(indio_dev, &gyro_state-
> > > > >common_attributes);
> > > > }
> > > >
> > >
^ permalink raw reply
* [PATCH v3] usbhid: tolerate intermittent errors
From: Liam Mitchell @ 2026-03-09 15:52 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Alan Stern, Oliver Neukum, linux-usb, linux-input, linux-kernel,
Liam Mitchell
Modifies usbhid error handling to better tolerate intermittent
errors, reducing URB resubmission delay and device resets.
---
Protocol errors like EPROTO can occur randomly, sometimes frequently and
are often not fixed by a device reset.
The current error handling will only resubmit the URB after at least 13ms
delay and may reset the USB device if another error occurs 1-1.5s later,
regardless of error type or count.
These delays and device resets increase the chance that input events will be
missed and that users see symptoms like missed or sticky keyboard keys.
This patch reduces the threshold used to assume device is working after
discussion in V2. Truly disconnected devices should error after 3 polling
intervals.
It allows single protocol errors to be retried immediately for minimal
downtime.
It changes the retry timeout to be relative to the last input URB
submission so time spent active counts towards the delay.
This makes it more likely that subsequent intermittent errors can be
retried on the next tick.
It only tries reset after 20 errors, roughly about 2s, longer than the
previous time based threshold of 1-1.5s.
Signed-off-by: Liam Mitchell <mitchell.liam@gmail.com>
Link: https://lore.kernel.org/linux-input/CAOQ1CL6Q+4GNy=kgisLzs0UBXFT3b02PG8t-0rPuW-Wf6NhQ6g@mail.gmail.com/
---
Changes in v3:
- uses shorter threshold to assume device is working
- stop_retry & retry_delay -> error_count & last_in
- retry after 20 errors
- includes running time in retry timeout calc
- immediate retry case is integrated with other error logic
- shortens initial retry delay to 1ms
- changes max delay to 128ms
- Link to v2: https://lore.kernel.org/r/20260307-usbhid-eproto-v2-1-e5a8abce4652@gmail.com
Changes in v2:
- revert changes to hid_io_error
- add more specific fix in hid_irq_in
- Link to v1: https://lore.kernel.org/r/20260208-usbhid-eproto-v1-1-5872c10d90bb@gmail.com
---
drivers/hid/usbhid/hid-core.c | 44 ++++++++++++++++++++++++++++---------------
drivers/hid/usbhid/usbhid.h | 4 ++--
2 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 758eb21430cd..233c1950632a 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -70,6 +70,12 @@ MODULE_PARM_DESC(quirks, "Add/modify USB HID quirks by specifying "
" quirks=vendorID:productID:quirks"
" where vendorID, productID, and quirks are all in"
" 0x-prefixed hex");
+
+/* Threshold at which we can assume a device is working correctly.
+ * A disconnected device should fail within 3 polling intervals.
+ * Most HID devices poll 8ms or faster. */
+#define HID_ASSUME_WORKING msecs_to_jiffies(100)
+
/*
* Input submission and I/O error handler.
*/
@@ -90,6 +96,7 @@ static int hid_start_in(struct hid_device *hid)
!test_bit(HID_DISCONNECTED, &usbhid->iofl) &&
!test_bit(HID_SUSPENDED, &usbhid->iofl) &&
!test_and_set_bit(HID_IN_RUNNING, &usbhid->iofl)) {
+ usbhid->last_in = jiffies;
rc = usb_submit_urb(usbhid->urbin, GFP_ATOMIC);
if (rc != 0) {
clear_bit(HID_IN_RUNNING, &usbhid->iofl);
@@ -154,19 +161,13 @@ static void hid_io_error(struct hid_device *hid)
goto done;
/* If it has been a while since the last error, we'll assume
- * this a brand new error and reset the retry timeout. */
- if (time_after(jiffies, usbhid->stop_retry + HZ/2))
- usbhid->retry_delay = 0;
-
- /* When an error occurs, retry at increasing intervals */
- if (usbhid->retry_delay == 0) {
- usbhid->retry_delay = 13; /* Then 26, 52, 104, 104, ... */
- usbhid->stop_retry = jiffies + msecs_to_jiffies(1000);
- } else if (usbhid->retry_delay < 100)
- usbhid->retry_delay *= 2;
+ * this a brand new error and reset the error count. */
+ if (time_after(jiffies, usbhid->last_in + HID_ASSUME_WORKING))
+ usbhid->error_count = 0;
- if (time_after(jiffies, usbhid->stop_retry)) {
+ usbhid->error_count++;
+ if (usbhid->error_count >= 20) {
/* Retries failed, so do a port reset unless we lack bandwidth*/
if (!test_bit(HID_NO_BANDWIDTH, &usbhid->iofl)
&& !test_and_set_bit(HID_RESET_PENDING, &usbhid->iofl)) {
@@ -176,8 +177,13 @@ static void hid_io_error(struct hid_device *hid)
}
}
- mod_timer(&usbhid->io_retry,
- jiffies + msecs_to_jiffies(usbhid->retry_delay));
+ /* Retry time is relative to the last start time and increases
+ * with error count: 1, 2, 4, 8, 16, 32, 64, 128, 128... ms.
+ * By including running time in the backoff, it should be possible
+ * to retry many intermittent errors in the next tick. */
+ mod_timer(&usbhid->io_retry, usbhid->last_in +
+ msecs_to_jiffies(1U << (min(usbhid->error_count, 8U) - 1)));
+
done:
spin_unlock_irqrestore(&usbhid->lock, flags);
}
@@ -278,7 +284,7 @@ static void hid_irq_in(struct urb *urb)
switch (urb->status) {
case 0: /* success */
- usbhid->retry_delay = 0;
+ usbhid->error_count = 0;
if (!test_bit(HID_OPENED, &usbhid->iofl))
break;
usbhid_mark_busy(usbhid);
@@ -312,6 +318,13 @@ static void hid_irq_in(struct urb *urb)
case -EPROTO: /* protocol error or unplug */
case -ETIME: /* protocol error or unplug */
case -ETIMEDOUT: /* Should never happen, but... */
+ /* Allow first error to retry immediately */
+ if (usbhid->error_count == 0 ||
+ time_after(jiffies, usbhid->last_in + HID_ASSUME_WORKING)) {
+ dev_dbg(&usbhid->intf->dev, "retrying intr urb immediately\n");
+ usbhid->error_count = 1;
+ break;
+ }
usbhid_mark_busy(usbhid);
clear_bit(HID_IN_RUNNING, &usbhid->iofl);
hid_io_error(hid);
@@ -321,6 +334,7 @@ static void hid_irq_in(struct urb *urb)
urb->status);
}
+ usbhid->last_in = jiffies;
status = usb_submit_urb(urb, GFP_ATOMIC);
if (status) {
clear_bit(HID_IN_RUNNING, &usbhid->iofl);
@@ -1504,7 +1518,7 @@ static void hid_restart_io(struct hid_device *hid)
if (clear_halt || reset_pending)
schedule_work(&usbhid->reset_work);
- usbhid->retry_delay = 0;
+ usbhid->error_count = 0;
spin_unlock_irq(&usbhid->lock);
if (reset_pending || !test_bit(HID_STARTED, &usbhid->iofl))
diff --git a/drivers/hid/usbhid/usbhid.h b/drivers/hid/usbhid/usbhid.h
index 75fe85d3d27a..b5dbfa588dc8 100644
--- a/drivers/hid/usbhid/usbhid.h
+++ b/drivers/hid/usbhid/usbhid.h
@@ -84,8 +84,8 @@ struct usbhid_device {
spinlock_t lock; /* fifo spinlock */
unsigned long iofl; /* I/O flags (CTRL_RUNNING, OUT_RUNNING) */
struct timer_list io_retry; /* Retry timer */
- unsigned long stop_retry; /* Time to give up, in jiffies */
- unsigned int retry_delay; /* Delay length in ms */
+ unsigned int error_count; /* Number of consecutive errors */
+ unsigned long last_in; /* Time of last in URB submission */
struct work_struct reset_work; /* Task context for resets */
wait_queue_head_t wait; /* For sleeping */
};
---
base-commit: b91e36222ccfb1b0985d1fcc4fb13b68fb99c972
change-id: 20260208-usbhid-eproto-152c7abcb185
Best regards,
--
Liam Mitchell <mitchell.liam@gmail.com>
^ permalink raw reply related
* Re: [PATCH 2/2] HID: input: Add HID_BATTERY_QUIRK_DYNAMIC for Elan touchscreens
From: Jiri Kosina @ 2026-03-09 18:11 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Hans de Goede, Dmitry Torokhov, Benjamin Tissoires, linux-input,
ggrundik
In-Reply-To: <aaWvxHt5RPeSRGxJ@venus>
On Mon, 2 Mar 2026, Sebastian Reichel wrote:
> The rationale and the patch LGTM.
Could I then please get your Acked-by: / Reviewed-by: recorded, so that it
can be added when applying?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: input: use __free(kfree) to clean up temporary buffers
From: Jiri Kosina @ 2026-03-09 18:21 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <aaPIp-z92hMsI7J5@google.com>
On Sat, 28 Feb 2026, Dmitry Torokhov wrote:
> The __free() cleanup automatically releases given resource when leaving
> the scope, so use it to make the code less cluttered with error
> handling.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Applied to hid.git#for-7.1/core. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq
From: Jiri Kosina @ 2026-03-09 18:34 UTC (permalink / raw)
To: Benoît Sevens
Cc: Ping Cheng, Jason Gerecke, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20260303135828.2374069-1-bsevens@google.com>
On Tue, 3 Mar 2026, Benoît Sevens wrote:
> The wacom_intuos_bt_irq() function processes Bluetooth HID reports
> without sufficient bounds checking. A maliciously crafted short report
> can trigger an out-of-bounds read when copying data into the wacom
> structure.
>
> Specifically, report 0x03 requires at least 22 bytes to safely read
> the processed data and battery status, while report 0x04 (which
> falls through to 0x03) requires 32 bytes.
>
> Add explicit length checks for these report IDs and log a warning if
> a short report is received.
>
> Signed-off-by: Benoît Sevens <bsevens@google.com>
Applied to hid.git#for-7.0/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: (subset) [PATCH 2/3] dt-bindings: mfd: convert fsl-imx25-tsadc.txt to yaml format
From: Lee Jones @ 2026-03-09 18:51 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Frank Li
Cc: linux-input, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260211-yaml_mfd-v1-2-05cb48bc6f09@nxp.com>
On Wed, 11 Feb 2026 16:41:05 -0500, Frank Li wrote:
> Convert fsl-imx25-tsadc.txt to yaml format.
>
> Addtional changes:
> - Add ranges.
>
>
Applied, thanks!
[2/3] dt-bindings: mfd: convert fsl-imx25-tsadc.txt to yaml format
commit: 61b80ec6685a08addd76ea6622636d709e7d989d
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 7/9] leds: Add driver for Asus Transformer LEDs
From: Lee Jones @ 2026-03-09 19:04 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Pavel Machek, Arnd Bergmann, Greg Kroah-Hartman,
Sebastian Reichel, Michał Mirosław, Ion Agorria,
devicetree, linux-kernel, linux-input, linux-leds, linux-pm
In-Reply-To: <CAPVz0n0jnuhmvsSPckfFOQ0NZ3VMe6W2p_Bb5a9pdVZYhVSJhQ@mail.gmail.com>
On Fri, 06 Mar 2026, Svyatoslav Ryhel wrote:
> пт, 6 бер. 2026 р. о 12:04 Lee Jones <lee@kernel.org> пише:
> >
> > On Mon, 09 Feb 2026, Svyatoslav Ryhel wrote:
> >
> > > From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > >
> > > Asus Transformer tablets have a green and an amber LED on both the Pad
> > > and the Dock. If both LEDs are enabled simultaneously, the emitted light
> > > will be yellow.
> > >
> > > Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > > ---
> > > drivers/leds/Kconfig | 11 ++++
> > > drivers/leds/Makefile | 1 +
> > > drivers/leds/leds-asus-ec.c | 104 ++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 116 insertions(+)
> > > create mode 100644 drivers/leds/leds-asus-ec.c
[
...]
> > > +static int asus_ec_led_probe(struct platform_device *pdev)
> > > +{
> > > + struct asusec_info *ec = cell_to_ec(pdev);
> >
> > Please remove all of your abstraction layers. They serve little purpose
> > other than to complicate things. Just use dev_get_drvdata() here.
> >
> > Remove the "_info" part and change "ec" to "ddata".
> >
>
> Controller exposes only required stuff, exposing controllers internal
> parts is not desired. Is there any written convention that driver
> private data pointer MUST be named "ddata"? "priv" is pretty well
> fitting to. You are just nitpicking.
[...]
> > Lots of repetition here.
> >
> > I'd make a sub-function that takes the differences.
> >
> > Same with the set brightness functions.
> >
> > Think to yourself - what if I had to support 16 different LEDs?
> >
>
> That is not of my concern what you would do. I have 2 LEDs and I see
> no point in "abstraction for he sake of abstraction".
Your attitude stinks!
All of your submissions are now on hold until I can be bothered to look
at them again. In the mean time, I suggest you look inward and
re-evaluate how you choose to communicate with others.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v7 3/3] Documentation: thinkpad-acpi - Document doubletap_enable attribute
From: Vishnu Sankar @ 2026-03-10 1:37 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Mark Pearson, dmitry.torokhov, hmh, Hans de Goede, corbet,
derekjohn.clark, linux-input, LKML, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar
In-Reply-To: <991f8a08-7c5d-5611-7904-6c5d336a74a3@linux.intel.com>
Ilpo,
Thank you for the review comments.
On Mon, Mar 9, 2026 at 5:04 PM Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Mon, 9 Feb 2026, Vishnu Sankar wrote:
>
> > Document the doubletap_enable sysfs attribute for ThinkPad ACPI driver.
> >
> > Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
> > ---
>
> > + * 1 - doubletap events are processed (default)
> > + * 0 - doubletap events are filtered out (ignored)
>
> There's something odd in space vs tab here.
I will check this.
>
> --
> i.
>
--
Regards,
Vishnu Sankar
^ permalink raw reply
* Re: [PATCH v7 1/3] input: trackpoint - Enable doubletap by default on capable devices
From: Vishnu Sankar @ 2026-03-10 2:11 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Mark Pearson, dmitry.torokhov, hmh, Hans de Goede, corbet,
derekjohn.clark, linux-input, LKML, ibm-acpi-devel, linux-doc,
platform-driver-x86, vsankar
In-Reply-To: <fdd1d48e-61b7-2543-8a30-c7ad416f5dd3@linux.intel.com>
Hi Ilpo,
Thank you so much for the review.
On Mon, Mar 9, 2026 at 5:01 PM Ilpo Järvinen
<ilpo.jarvinen@linux.intel.com> wrote:
>
> On Mon, 9 Feb 2026, Vishnu Sankar wrote:
>
> > Enable doubletap functionality by default on TrackPoint devices that
> > support it. The feature is detected using firmware ID pattern matching
> > (PNP: LEN03xxx) with a deny list of incompatible devices.
> >
> > This provides immediate doubletap functionality without requiring
> > userspace configuration. The hardware is enabled during device
> > detection, while event filtering continues to be handled by the
> > thinkpad_acpi driver as before.
> >
> > Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com>
> > Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
> > Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
> > Changes in v7:
> > - Removed unwanted comments
> > - Removed psmouse_info ()
> >
> > Changes in v6:
> > - No Changes
> >
> > Changes in v5:
> > - Renamed function to trackpoint_is_dt_capable()
> > - Simplified string comparison without sscanf()
> > - Removed wrapper function as suggested
> > - Fixed missing period in comment
> >
> > Changes in v4:
> > - Simplified approach: removed all sysfs attributes and user interface
> > - Enable doubletap by default during device detection
> > - Removed global variables and complex attribute infrastructure
> > - Uses minimal firmware ID detection with deny list
> > - Follows KISS principle as suggested by reviewers
> >
> > Changes in v3:
> > - No changes
> >
> > Changes in v2:
> > - Improve commit messages
> > - Sysfs attributes moved to trackpoint.c
> > - Removed unnecessary comments
> > - Removed unnecessary debug messages
> > - Using strstarts() instead of strcmp()
> > - is_trackpoint_dt_capable() modified
> > - Removed _BIT suffix and used BIT() define
> > - Reverse the trackpoint_doubletap_status() logic to return error first
> > - Removed export functions as a result of the design change
> > - Changed trackpoint_dev->psmouse to parent_psmouse
> > - The path of trackpoint.h is not changed
> > ---
> > drivers/input/mouse/trackpoint.c | 45 ++++++++++++++++++++++++++++++++
> > drivers/input/mouse/trackpoint.h | 5 ++++
> > 2 files changed, 50 insertions(+)
> >
> > diff --git a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
> > index 5f6643b69a2c..e12d76350252 100644
> > --- a/drivers/input/mouse/trackpoint.c
> > +++ b/drivers/input/mouse/trackpoint.c
> > @@ -393,6 +393,45 @@ static int trackpoint_reconnect(struct psmouse *psmouse)
> > return 0;
> > }
> >
> > +/* List of known incapable device PNP IDs */
> > +static const char * const dt_incompatible_devices[] = {
> > + "LEN0304",
> > + "LEN0306",
> > + "LEN0317",
> > + "LEN031A",
> > + "LEN031B",
> > + "LEN031C",
> > + "LEN031D",
> > +};
> > +
> > +/*
> > + * Checks if it's a doubletap capable device.
> > + * The PNP ID format is "PNP: LEN030d PNP0f13".
> > + */
> > +static bool trackpoint_is_dt_capable(const char *pnp_id)
> > +{
> > + size_t i;
> > +
> > + if (!pnp_id)
> > + return false;
> > +
> > + /* Must start with "PNP: LEN03" */
> > + if (!strstarts(pnp_id, "PNP: LEN03"))
>
> Missing include.
Sorry, I am a bit confused here:
strstarts() is already available through the existing
#include <linux/string.h> in thinkpad_acpi.c.
Do you think I should do anything else here?
>
> > + return false;
> > +
> > + /* Ensure enough length before comparing */
> > + if (strlen(pnp_id) < 12)
> > + return false;
> > +
> > + /* Check deny-list */
> > + for (i = 0; i < ARRAY_SIZE(dt_incompatible_devices); i++) {
>
> Missing include for ARRAY_SIZE().
Acked.
Will add linux/array_size.h to the include list.
>
> > + if (!strncmp(pnp_id + 5,
> > + dt_incompatible_devices[i], 7))
>
> Fits to one line.
Understood.
will come up with v8 soon.
>
> > + return false;
> > + }
> > + return true;
> > +}
> > +
> > int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
> > {
> > struct ps2dev *ps2dev = &psmouse->ps2dev;
> > @@ -470,6 +509,12 @@ int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
> > psmouse->vendor, firmware_id,
> > (button_info & 0xf0) >> 4, button_info & 0x0f);
> >
> > + if (trackpoint_is_dt_capable(ps2dev->serio->firmware_id)) {
> > + error = trackpoint_write(ps2dev, TP_DOUBLETAP, TP_DOUBLETAP_ENABLE);
> > + if (error)
> > + psmouse_warn(psmouse, "Failed to enable doubletap: %d\n", error);
> > + }
> > +
> > return 0;
> > }
> >
> > diff --git a/drivers/input/mouse/trackpoint.h b/drivers/input/mouse/trackpoint.h
> > index eb5412904fe0..3e03cdb39449 100644
> > --- a/drivers/input/mouse/trackpoint.h
> > +++ b/drivers/input/mouse/trackpoint.h
> > @@ -69,6 +69,8 @@
> > /* (how hard it is to drag */
> > /* with Z-axis pressed) */
> >
> > +#define TP_DOUBLETAP 0x58 /* TrackPoint doubletap register */
> > +
> > #define TP_MINDRAG 0x59 /* Minimum amount of force needed */
> > /* to trigger dragging */
> >
> > @@ -110,6 +112,9 @@
> > external device will be forced to 1 */
> > #define TP_MASK_EXT_TAG 0x04
> >
> > +/* Doubletap register values */
> > +#define TP_DOUBLETAP_ENABLE 0xFF /* Enable value */
> > +#define TP_DOUBLETAP_DISABLE 0xFE /* Disable value */
> >
> > /* Power on Self Test Results */
> > #define TP_POR_SUCCESS 0x3B
> >
>
> --
> i.
>
--
Regards,
Vishnu Sankar
^ 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