* [PATCH 2/7] hid-asus: Add missing Zenbook Duo hotkeys
From: Paolo Pisati @ 2026-05-13 16:32 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20260513163248.16483-1-p.pisati@gmail.com>
From: Joshua Leivenzon <hacker1024@users.sourceforge.net>
Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
---
drivers/hid/hid-asus.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index ce246efba74d3..cba638b19465f 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1046,6 +1046,7 @@ static int asus_input_mapping(struct hid_device *hdev,
case 0x6c: asus_map_key_clear(KEY_SLEEP); break;
case 0x7c: asus_map_key_clear(KEY_MICMUTE); break;
case 0x82: asus_map_key_clear(KEY_CAMERA); break;
+ case 0x86: asus_map_key_clear(KEY_CONTROLPANEL); break; /* MyASUS */
case 0x88: asus_map_key_clear(KEY_RFKILL); break;
case 0xb5: asus_map_key_clear(KEY_CALC); break;
case 0xc4: asus_map_key_clear(KEY_KBDILLUMUP); break;
@@ -1066,6 +1067,18 @@ static int asus_input_mapping(struct hid_device *hdev,
case 0xb3: asus_map_key_clear(KEY_PROG3); break; /* Fn+Left next aura */
case 0x6a: asus_map_key_clear(KEY_F13); break; /* Screenpad toggle */
case 0x4b: asus_map_key_clear(KEY_F14); break; /* Arrows/Pg-Up/Dn toggle */
+ case 0x9c: asus_map_key_clear(KEY_F19); break; /* Screen swap */
+
+ /* Mutually exclusive section: Special keys from different devices can
+ * bind to the same keycodes without concern, as they will never
+ * conflict.
+ *
+ * Note that devices with removable keyboards that connect over a
+ * standard interface (e.g. Zenbook Duo UX8406 with USB/Bluetooth) do
+ * not belong in this section, as such keyboards can be connected to
+ * another ASUS device that also uses this driver for its own keyboard.
+ */
+ /* ROG Ally */
case 0xa5: asus_map_key_clear(KEY_F15); break; /* ROG Ally left back */
case 0xa6: asus_map_key_clear(KEY_F16); break; /* ROG Ally QAM button */
case 0xa7: asus_map_key_clear(KEY_F17); break; /* ROG Ally ROG long-press */
--
2.53.0
^ permalink raw reply related
* [PATCH 1/7] hid-asus: Fix up Zenbook Duo report descriptors
From: Paolo Pisati @ 2026-05-13 16:32 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <20260513163248.16483-1-p.pisati@gmail.com>
From: Joshua Leivenzon <hacker1024@users.sourceforge.net>
This is similar to the T100CHI/T90CHI keyboard dock fix.
Without it, all reports log:
Unmapped Asus vendor usagepage code 0x76
Signed-off-by: Joshua Leivenzon <hacker1024@users.sourceforge.net>
---
drivers/hid/hid-asus.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 3f5e96900b67a..ce246efba74d3 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -99,6 +99,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
#define QUIRK_ROG_CLAYMORE_II_KEYBOARD BIT(12)
#define QUIRK_ROG_ALLY_XPAD BIT(13)
#define QUIRK_HID_FN_LOCK BIT(14)
+#define QUIRK_ZENBOOK_DUO_KEYBOARD BIT(15)
#define I2C_KEYBOARD_QUIRKS (QUIRK_FIX_NOTEBOOK_REPORT | \
QUIRK_NO_INIT_REPORTS | \
@@ -1384,17 +1385,20 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
hid_info(hdev, "Fixing up Asus T100 keyb report descriptor\n");
rdesc[74] &= ~HID_MAIN_ITEM_CONSTANT;
}
- /* For the T100CHI/T90CHI keyboard dock */
- if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI)) {
+ /* For the T100CHI/T90CHI keyboard dock and Zenbook Duo 2024+ keyboards */
+ if (drvdata->quirks & (QUIRK_T100CHI | QUIRK_T90CHI | QUIRK_ZENBOOK_DUO_KEYBOARD)) {
int rsize_orig;
int offs;
if (drvdata->quirks & QUIRK_T100CHI) {
rsize_orig = 403;
offs = 388;
- } else {
+ } else if (drvdata->quirks & QUIRK_T90CHI) {
rsize_orig = 306;
offs = 291;
+ } else if (drvdata->quirks & QUIRK_ZENBOOK_DUO_KEYBOARD) {
+ rsize_orig = 257;
+ offs = 176;
}
/*
@@ -1414,7 +1418,8 @@ static const __u8 *asus_report_fixup(struct hid_device *hdev, __u8 *rdesc,
hid_info(hdev, "Fixing up %s keyb report descriptor\n",
drvdata->quirks & QUIRK_T100CHI ?
- "T100CHI" : "T90CHI");
+ "T100CHI" : drvdata->quirks & QUIRK_T90CHI ?
+ "T90CHI" : "ZENBOOK DUO");
memcpy(new_rdesc, rdesc, rsize_orig);
*rsize = rsize_orig + 1;
--
2.53.0
^ permalink raw reply related
* [PATCH 0/7] ASUS Zenbook Duo keyboard support
From: Paolo Pisati @ 2026-05-13 16:32 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input
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
Tested by many on all Zenbook Duo SKUs: UX8406MA, UX8406CA and UX8407AA.
Joshua Leivenzon (6):
hid-asus: Fix up Zenbook Duo report descriptors
hid-asus: Add missing Zenbook Duo hotkeys
hid-asus: Add report descriptor fixup offsets for UX8406MA USB
keyboard
hid-asus: Remove more bogus zero bytes from some report descriptors
hid-asus: Fix input mapping on dedicated vendor HID interfaces
hid-asus: Allow adding custom hotkey handler logic
Luke Jones (1):
hid-asus: add prod-id, quirk for Zenbook Duo keyboard
drivers/hid/hid-asus.c | 126 +++++++++++++++++++++++++++++++++++++----
drivers/hid/hid-ids.h | 6 ++
2 files changed, 121 insertions(+), 11 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH] HID: Expose LattePanda IOTA UPS as a power_supply device
From: Andrew Maney @ 2026-05-13 15:57 UTC (permalink / raw)
To: jikos; +Cc: bentiss, linux-kernel, linux-input, Andrew Maney
This driver exposes the DFRobot LattePanda IOTA UPS board as a standard
power_supply device, allowing desktop environments and power management
tools such as UPower and systemd-logind to display battery status,
remaining capacity, and charging status without any special
configuration. It also enables automatic suspend or shutdown on low
battery and power profile configuration via any tool that supports the
standard power_supply interface.
The UPS presents itself as an Arduino Leonardo HID device running custom
firmware (VID 0x2341, PID 0x8036). It reports status and capacity via
HID reports 0x07 and 0x0C respectively.
The charge limit (80% or 100%) is configured via a physical DIP switch
on the UPS board and cannot be detected automatically. Userspace can
inform the driver of the configured limit via
charge_control_end_threshold.
Known issue: the driver occasionally reports 0% capacity briefly on
initial load before the first valid HID report is received. I am
investigating the cause.
Signed-off-by: Andrew Maney <andrewmaney05@gmail.com>
---
Changes in v2:
- Rebased on top of the current tree
- Moved vendor and device IDs to drivers/hid/hid-ids.h
- Added Kconfig entry under HID bus support -> Special HID drivers
- Added build rule to drivers/hid/Makefile
---
MAINTAINERS | 6 +
drivers/hid/Kconfig | 10 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-ids.h | 3 +
drivers/hid/hid-lattepanda-iota-ups.c | 354 ++++++++++++++++++++++++++
5 files changed, 374 insertions(+)
create mode 100644 drivers/hid/hid-lattepanda-iota-ups.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b2040011a..fd2947a80 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11410,6 +11410,12 @@ F: include/uapi/linux/hid*
F: samples/hid/
F: tools/testing/selftests/hid/
+HID LATTEPANDA IOTA UPS DRIVER
+M: Andrew Maney <andrewmaney05@gmail.com>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: drivers/hid/hid-lattepanda-iota-ups.c
+
HID LOGITECH DRIVERS
R: Filipe Laíns <lains@riseup.net>
L: linux-input@vger.kernel.org
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index ff2f580b6..3c1efef3d 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -105,6 +105,16 @@ config HID_HAPTIC
menu "Special HID drivers"
+config HID_LATTEPANDA_IOTA_UPS
+ tristate "LattePanda IOTA UPS"
+ depends on USB_HID && X86
+ help
+ Support for the LattePanda IOTA UPS (DFRobot, VID 0x2341 PID 0x8036).
+ Exposes the battery status and capacity via the power_supply interface.
+
+ To compile as a module, choose M here: the module will be
+ called hid-lattepanda-iota-ups.
+
config HID_A4TECH
tristate "A4TECH mice"
help
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 0597fd6a4..7ba44223c 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -24,6 +24,7 @@ hid-logitech-$(CONFIG_LOGIWHEELS_FF) += hid-lg4ff.o
hid-wiimote-y := hid-wiimote-core.o hid-wiimote-modules.o
hid-wiimote-$(CONFIG_DEBUG_FS) += hid-wiimote-debug.o
+obj-$(CONFIG_HID_LATTEPANDA_IOTA_UPS) += hid-lattepanda-iota-ups.o
obj-$(CONFIG_HID_A4TECH) += hid-a4tech.o
obj-$(CONFIG_HID_ACCUTOUCH) += hid-accutouch.o
obj-$(CONFIG_HID_ALPS) += hid-alps.o
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 0cf637423..3b69b072c 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -25,6 +25,9 @@
#define USB_VENDOR_ID_8BITDO 0x2dc8
#define USB_DEVICE_ID_8BITDO_PRO_3 0x6009
+#define USB_VENDOR_ID_LATTEPANDA_IOTA 0x2341
+#define USB_DEVICE_ID_LATTEPANDA_IOTA_UPS 0x8036
+
#define USB_VENDOR_ID_A4TECH 0x09da
#define USB_DEVICE_ID_A4TECH_WCP32PU 0x0006
#define USB_DEVICE_ID_A4TECH_X5_005D 0x000a
diff --git a/drivers/hid/hid-lattepanda-iota-ups.c b/drivers/hid/hid-lattepanda-iota-ups.c
new file mode 100644
index 000000000..cb0c2a6f3
--- /dev/null
+++ b/drivers/hid/hid-lattepanda-iota-ups.c
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/completion.h>
+#include <linux/hid.h>
+#include <linux/module.h>
+#include <linux/power_supply.h>
+#include <linux/spinlock.h>
+#include <linux/usb.h>
+#include "hid-ids.h"
+
+#define REPORT_ID_STATUS 0x07
+#define REPORT_ID_CAPACITY 0x0C
+
+#define STATUS_PLUGGED_IN BIT(0)
+#define STATUS_DISCHARGING BIT(1)
+#define STATUS_CHARGING BIT(2)
+
+MODULE_AUTHOR("Andrew Maney");
+MODULE_DESCRIPTION("LattePanda IOTA UPS power supply driver");
+MODULE_LICENSE("GPL");
+
+struct iota_ups {
+ struct hid_device *hiddev;
+ struct power_supply *psu;
+ struct power_supply_desc psu_desc;
+ spinlock_t lock; /* Protects all cached HID report values */
+
+ /* Cached values updated from HID reports */
+ char serial[64];
+ bool plugged_in;
+ int psu_status;
+ int capacity;
+ int charge_limit;
+
+ /*
+ * Wait for both status and capacity reports before registering
+ * with the power_supply core, so initial values are correct.
+ */
+ struct completion got_initial_data;
+ bool data_ready;
+ bool got_status;
+ bool got_capacity;
+};
+
+static enum power_supply_property iota_ups_properties[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_SCOPE,
+ POWER_SUPPLY_PROP_TECHNOLOGY,
+ POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD,
+ POWER_SUPPLY_PROP_CAPACITY_LEVEL,
+ POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
+ POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_MANUFACTURER,
+ POWER_SUPPLY_PROP_MODEL_NAME,
+ POWER_SUPPLY_PROP_SERIAL_NUMBER,
+};
+
+static const struct hid_device_id iota_ups_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_LATTEPANDA_IOTA,
+ USB_DEVICE_ID_LATTEPANDA_IOTA_UPS) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, iota_ups_devices);
+
+static int iota_ups_get_property(struct power_supply *supply,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct iota_ups *ups = power_supply_get_drvdata(supply);
+ unsigned long flags;
+
+ spin_lock_irqsave(&ups->lock, flags);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_STATUS:
+ val->intval = ups->psu_status;
+ break;
+ /* Remaining capacity as a percentage, 0-100 */
+ case POWER_SUPPLY_PROP_CAPACITY:
+ val->intval = ups->capacity;
+ break;
+ /* Always present if the driver is loaded */
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = 1;
+ break;
+ /* Whether mains power is connected */
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = ups->plugged_in ? 1 : 0;
+ break;
+ /* System-level UPS, not a laptop battery */
+ case POWER_SUPPLY_PROP_SCOPE:
+ val->intval = POWER_SUPPLY_SCOPE_SYSTEM;
+ break;
+ /* V1.0 only accepts 18650 Li-ion cells */
+ case POWER_SUPPLY_PROP_TECHNOLOGY:
+ val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
+ break;
+ /* 80% or 100%, configured via DIP switch on the board */
+ case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD:
+ val->intval = ups->charge_limit;
+ break;
+ /* V1.0 does not report capacity level via HID */
+ case POWER_SUPPLY_PROP_CAPACITY_LEVEL:
+ val->intval = POWER_SUPPLY_CAPACITY_LEVEL_NORMAL;
+ break;
+ /* V1.0 does not report time remaining */
+ case POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW:
+ case POWER_SUPPLY_PROP_TIME_TO_FULL_NOW:
+ val->intval = 0;
+ break;
+ /* V1.0 does not report health; assume good */
+ case POWER_SUPPLY_PROP_HEALTH:
+ val->intval = POWER_SUPPLY_HEALTH_GOOD;
+ break;
+ /* 3.7V in microvolts, typical Li-ion resting voltage */
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ val->intval = 3700000;
+ break;
+ case POWER_SUPPLY_PROP_MANUFACTURER:
+ val->strval = "DFRobot";
+ break;
+ case POWER_SUPPLY_PROP_MODEL_NAME:
+ val->strval = "LattePanda IOTA UPS";
+ break;
+ /* Retrieved from the USB descriptor */
+ case POWER_SUPPLY_PROP_SERIAL_NUMBER:
+ val->strval = ups->serial;
+ break;
+ default:
+ spin_unlock_irqrestore(&ups->lock, flags);
+ return -EINVAL;
+ }
+
+ spin_unlock_irqrestore(&ups->lock, flags);
+ return 0;
+}
+
+static int iota_ups_set_property(struct power_supply *supply,
+ enum power_supply_property psp,
+ const union power_supply_propval *val)
+{
+ struct iota_ups *ups = power_supply_get_drvdata(supply);
+
+ if (psp == POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD) {
+ /*
+ * V1.0 supports 80% and 100% charge limits only, set via
+ * DIP switch on the board. This property allows userspace
+ * to inform the driver which limit is configured.
+ */
+ if (val->intval != 80 && val->intval != 100)
+ return -EINVAL;
+ ups->charge_limit = val->intval;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static int iota_ups_property_is_writable(struct power_supply *supply,
+ enum power_supply_property psp)
+{
+ return psp == POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD;
+}
+
+static int iota_ups_raw_event(struct hid_device *hdev,
+ struct hid_report *report,
+ u8 *data, int size)
+{
+ struct iota_ups *ups = hid_get_drvdata(hdev);
+ unsigned long flags;
+ bool changed = false;
+
+ /* All UPS reports are at least 2 bytes */
+ if (size < 2)
+ return 0;
+
+ spin_lock_irqsave(&ups->lock, flags);
+
+ switch (data[0]) {
+ case REPORT_ID_STATUS: {
+ u8 status = data[1];
+ int new_status;
+ bool plugged_in = !!(status & STATUS_PLUGGED_IN);
+
+ if (status & STATUS_CHARGING) {
+ if (ups->capacity >= ups->charge_limit)
+ new_status = POWER_SUPPLY_STATUS_FULL;
+ else
+ new_status = POWER_SUPPLY_STATUS_CHARGING;
+ } else if (status & STATUS_DISCHARGING) {
+ new_status = POWER_SUPPLY_STATUS_DISCHARGING;
+ } else if (plugged_in) {
+ new_status = POWER_SUPPLY_STATUS_FULL;
+ } else {
+ new_status = POWER_SUPPLY_STATUS_UNKNOWN;
+ }
+
+ if (new_status != ups->psu_status ||
+ plugged_in != ups->plugged_in) {
+ ups->plugged_in = plugged_in;
+ ups->psu_status = new_status;
+ changed = true;
+ }
+
+ ups->got_status = true;
+ break;
+ }
+ case REPORT_ID_CAPACITY: {
+ int new_cap = clamp((int)data[1], 0, 100);
+
+ if (new_cap != ups->capacity) {
+ ups->capacity = new_cap;
+ changed = true;
+ }
+
+ ups->got_capacity = true;
+ break;
+ }
+ }
+
+ /*
+ * Signal ready only once both status and capacity have been
+ * received, so the power_supply is registered with valid data.
+ */
+ if (!ups->data_ready && ups->got_status && ups->got_capacity) {
+ ups->data_ready = true;
+ complete(&ups->got_initial_data);
+ }
+
+ spin_unlock_irqrestore(&ups->lock, flags);
+
+ /*
+ * Notify the power_supply core outside the spinlock. This
+ * triggers UPower's PropertiesChanged signal with the new values.
+ */
+ if (changed && ups->psu)
+ power_supply_changed(ups->psu);
+
+ return 0;
+}
+
+static int iota_ups_probe(struct hid_device *hdev,
+ const struct hid_device_id *id)
+{
+ struct power_supply_config psu_config = {};
+ struct usb_device *udev;
+ struct iota_ups *ups;
+ int ret;
+
+ ups = devm_kzalloc(&hdev->dev, sizeof(*ups), GFP_KERNEL);
+ if (!ups)
+ return -ENOMEM;
+
+ ups->hiddev = hdev;
+ ups->psu_status = POWER_SUPPLY_STATUS_UNKNOWN;
+ ups->capacity = 50;
+ /*
+ * Default to 100% — the DIP switch may be set to 80% but there
+ * is no way to detect this automatically from HID reports.
+ * Userspace can update this via charge_control_end_threshold.
+ */
+ ups->charge_limit = 100;
+ ups->data_ready = false;
+ ups->got_status = false;
+ ups->got_capacity = false;
+
+ init_completion(&ups->got_initial_data);
+ spin_lock_init(&ups->lock);
+ hid_set_drvdata(hdev, ups);
+
+ /* Retrieve serial number from the USB descriptor */
+ udev = to_usb_device(hdev->dev.parent->parent);
+ if (udev->serial)
+ strscpy(ups->serial, udev->serial, sizeof(ups->serial));
+ else
+ strscpy(ups->serial, "Unknown", sizeof(ups->serial));
+
+ ret = hid_parse(hdev);
+ if (ret) {
+ hid_err(hdev, "HID parse failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
+ if (ret) {
+ hid_err(hdev, "HID hw start failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = hid_hw_open(hdev);
+ if (ret) {
+ hid_err(hdev, "HID hw open failed: %d\n", ret);
+ goto err_stop;
+ }
+
+ /*
+ * Wait for both status and capacity reports before registering.
+ * The device sends reports every ~1 second; 3 seconds is safe.
+ */
+ wait_for_completion_timeout(&ups->got_initial_data,
+ msecs_to_jiffies(3000));
+
+ ups->psu_desc.name = "lattepanda-iota-ups";
+ ups->psu_desc.type = POWER_SUPPLY_TYPE_BATTERY;
+ ups->psu_desc.properties = iota_ups_properties;
+ ups->psu_desc.num_properties = ARRAY_SIZE(iota_ups_properties);
+ ups->psu_desc.get_property = iota_ups_get_property;
+ ups->psu_desc.set_property = iota_ups_set_property;
+ ups->psu_desc.property_is_writeable = iota_ups_property_is_writable;
+ psu_config.drv_data = ups;
+
+ ups->psu = devm_power_supply_register(&hdev->dev,
+ &ups->psu_desc,
+ &psu_config);
+ if (IS_ERR(ups->psu)) {
+ ret = PTR_ERR(ups->psu);
+ hid_err(hdev, "power_supply register failed: %d\n", ret);
+ goto err_close;
+ }
+
+ /*
+ * Force an immediate notification so UPower reads the correct
+ * initial state right after registration.
+ */
+ power_supply_changed(ups->psu);
+
+ hid_info(hdev, "LattePanda IOTA UPS registered as power supply\n");
+ return 0;
+
+err_close:
+ hid_hw_close(hdev);
+err_stop:
+ hid_hw_stop(hdev);
+ return ret;
+}
+
+static void iota_ups_remove(struct hid_device *hdev)
+{
+ hid_hw_close(hdev);
+ hid_hw_stop(hdev);
+}
+
+static struct hid_driver iota_ups_driver = {
+ .name = "lattepanda-iota-ups",
+ .id_table = iota_ups_devices,
+ .probe = iota_ups_probe,
+ .remove = iota_ups_remove,
+ .raw_event = iota_ups_raw_event,
+};
+module_hid_driver(iota_ups_driver);
--
2.54.0
^ permalink raw reply related
* [PATCH] input/evdev: move kill_fasync() outside buffer_lock to fix SOFTIRQ deadlock
From: Rik van Riel @ 2026-05-13 15:50 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, kernel-team
buffer_lock is a SOFTIRQ-safe spinlock. kill_fasync() acquires fa_lock
(SOFTIRQ-unsafe), creating a potential SOFTIRQ-safe->SOFTIRQ-unsafe lock
ordering violation that lockdep flags as a deadlock.
Fix by moving the kill_fasync() call to evdev_pass_values() after
buffer_lock is released, alongside the existing wake_up_interruptible_poll().
The wakeup condition check is the same in __pass_event() and
evdev_pass_values()
Found by syzkaller
Assisted-by: Claude:claude-opus-4.7
Signed-off-by: Rik van Riel <riel@surriel.com>
---
drivers/input/evdev.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index c7325226cb86..bda63f7a507a 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -235,10 +235,8 @@ static void __pass_event(struct evdev_client *client,
client->packet_head = client->tail;
}
- if (event->type == EV_SYN && event->code == SYN_REPORT) {
+ if (event->type == EV_SYN && event->code == SYN_REPORT)
client->packet_head = client->head;
- kill_fasync(&client->fasync, SIGIO, POLL_IN);
- }
}
static void evdev_pass_values(struct evdev_client *client,
@@ -280,9 +278,11 @@ static void evdev_pass_values(struct evdev_client *client,
spin_unlock(&client->buffer_lock);
- if (wakeup)
+ if (wakeup) {
+ kill_fasync(&client->fasync, SIGIO, POLL_IN);
wake_up_interruptible_poll(&client->wait,
EPOLLIN | EPOLLOUT | EPOLLRDNORM | EPOLLWRNORM);
+ }
}
/*
--
2.53.0-Meta
^ permalink raw reply related
* Re: [PATCH 1/1] HID: wacom: Fix OOB write in wacom_hid_set_device_mode()
From: Ping Cheng @ 2026-05-13 15:47 UTC (permalink / raw)
To: Lee Jones
Cc: Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel, stable
In-Reply-To: <20260513075935.1715836-1-lee@kernel.org>
On Wed, May 13, 2026 at 1:05 AM Lee Jones <lee@kernel.org> wrote:
>
> wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE
> usage is always located in the first field (field[0]) of the feature report.
> However, a device can specify HID_DG_INPUTMODE in a different field.
>
> If HID_DG_INPUTMODE is in a field other than the first one and the first
> field has a report_count smaller than the usage_index of HID_DG_INPUTMODE,
> this leads to an out-of-bounds write to r->field[0]->value.
>
> Fix this by storing the field index of HID_DG_INPUTMODE in 'struct
> hid_data' during feature mapping. In wacom_hid_set_device_mode(), use
> this stored field index to access the correct field and add bounds
> checks to ensure both the field index and the value index are within
> valid ranges before writing.
>
> Cc: stable@vger.kernel.org
> Fixes: 5ae6e89f7409 ("HID: wacom: implement the finger part of the HID generic handling")
> Signed-off-by: Lee Jones <lee@kernel.org>
Patch looks sensible to me. Thank you for your effort, Lee!
Tested-by: Ping Cheng <ping.cheng@wacom.com>
Reviewed-by: Ping Cheng <ping.cheng@wacom.com>
Cheers,
Ping
> ---
> drivers/hid/wacom_sys.c | 13 ++++++++++---
> drivers/hid/wacom_wac.h | 1 +
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 1b1112772777..a6c5281afa06 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -341,6 +341,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
>
> hid_data->inputmode = field->report->id;
> hid_data->inputmode_index = usage->usage_index;
> + hid_data->inputmode_field_index = field->index;
> break;
>
> case HID_UP_DIGITIZER:
> @@ -556,9 +557,14 @@ static int wacom_hid_set_device_mode(struct hid_device *hdev)
>
> re = &(hdev->report_enum[HID_FEATURE_REPORT]);
> r = re->report_id_hash[hid_data->inputmode];
> - if (r) {
> - r->field[0]->value[hid_data->inputmode_index] = 2;
> - hid_hw_request(hdev, r, HID_REQ_SET_REPORT);
> + if (r && hid_data->inputmode_field_index >= 0 &&
> + hid_data->inputmode_field_index < r->maxfield) {
> + struct hid_field *field = r->field[hid_data->inputmode_field_index];
> +
> + if (field && hid_data->inputmode_index < field->report_count) {
> + field->value[hid_data->inputmode_index] = 2;
> + hid_hw_request(hdev, r, HID_REQ_SET_REPORT);
> + }
> }
> return 0;
> }
> @@ -2819,6 +2825,7 @@ static int wacom_probe(struct hid_device *hdev,
> return error;
>
> wacom_wac->hid_data.inputmode = -1;
> + wacom_wac->hid_data.inputmode_field_index = -1;
> wacom_wac->mode_report = -1;
>
> if (hid_is_usb(hdev)) {
> diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
> index c8803d5c6a71..b2e74d7ab3c4 100644
> --- a/drivers/hid/wacom_wac.h
> +++ b/drivers/hid/wacom_wac.h
> @@ -298,6 +298,7 @@ struct wacom_shared {
> struct hid_data {
> __s16 inputmode; /* InputMode HID feature, -1 if non-existent */
> __s16 inputmode_index; /* InputMode HID feature index in the report */
> + __s16 inputmode_field_index; /* InputMode HID feature field index in the report */
> bool sense_state;
> bool inrange_state;
> bool invert_state;
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS b7710233c16c1f42e0b58a1f0485658fc4fa61c1
From: kernel test robot @ 2026-05-13 14:37 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: b7710233c16c1f42e0b58a1f0485658fc4fa61c1 Input: atmel_mxt_ts - use __free() for obuf in mxt_object_show
elapsed time: 1225m
configs tested: 244
configs skipped: 14
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc nsimosci_defconfig gcc-15.2.0
arc randconfig-001-20260513 gcc-14.3.0
arc randconfig-002-20260513 gcc-14.3.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm gemini_defconfig clang-20
arm ixp4xx_defconfig gcc-15.2.0
arm randconfig-001-20260513 gcc-14.3.0
arm randconfig-002-20260513 gcc-14.3.0
arm randconfig-003-20260513 gcc-14.3.0
arm randconfig-004-20260513 gcc-14.3.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260513 clang-23
arm64 randconfig-001-20260513 gcc-12.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260513 clang-23
arm64 randconfig-002-20260513 gcc-12.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260513 clang-23
arm64 randconfig-003-20260513 gcc-12.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260513 clang-23
arm64 randconfig-004-20260513 gcc-12.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001 clang-23
csky randconfig-001-20260513 clang-23
csky randconfig-001-20260513 gcc-12.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260513 clang-23
csky randconfig-002-20260513 gcc-12.5.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260513 gcc-11.5.0
hexagon randconfig-001-20260513 gcc-8.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260513 gcc-11.5.0
hexagon randconfig-002-20260513 gcc-8.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260513 clang-20
i386 buildonly-randconfig-002-20260513 clang-20
i386 buildonly-randconfig-003-20260513 clang-20
i386 buildonly-randconfig-004-20260513 clang-20
i386 buildonly-randconfig-005-20260513 clang-20
i386 buildonly-randconfig-006-20260513 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260513 clang-20
i386 randconfig-002-20260513 clang-20
i386 randconfig-003-20260513 clang-20
i386 randconfig-004-20260513 clang-20
i386 randconfig-005-20260513 clang-20
i386 randconfig-006-20260513 clang-20
i386 randconfig-007-20260513 clang-20
i386 randconfig-011-20260513 clang-20
i386 randconfig-012-20260513 clang-20
i386 randconfig-012-20260513 gcc-14
i386 randconfig-013-20260513 clang-20
i386 randconfig-014-20260513 clang-20
i386 randconfig-015-20260513 clang-20
i386 randconfig-016-20260513 clang-20
i386 randconfig-017-20260513 clang-20
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260513 gcc-11.5.0
loongarch randconfig-001-20260513 gcc-8.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260513 gcc-11.5.0
loongarch randconfig-002-20260513 gcc-8.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k atari_defconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips loongson3_defconfig gcc-15.2.0
mips maltaup_xpa_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260513 gcc-11.5.0
nios2 randconfig-001-20260513 gcc-8.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260513 gcc-11.5.0
nios2 randconfig-002-20260513 gcc-8.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260513 gcc-8.5.0
parisc randconfig-002-20260513 gcc-8.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc mpc832x_rdb_defconfig gcc-15.2.0
powerpc mpc834x_itx_defconfig clang-16
powerpc rainier_defconfig gcc-15.2.0
powerpc randconfig-001-20260513 gcc-8.5.0
powerpc randconfig-002-20260513 gcc-8.5.0
powerpc64 randconfig-001-20260513 gcc-8.5.0
powerpc64 randconfig-002-20260513 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260513 gcc-15.2.0
riscv randconfig-002-20260513 gcc-15.2.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260513 gcc-15.2.0
s390 randconfig-002-20260513 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh kfr2r09-romimage_defconfig gcc-15.2.0
sh randconfig-001-20260513 gcc-15.2.0
sh randconfig-002-20260513 gcc-15.2.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001 gcc-11.5.0
sparc randconfig-001-20260513 gcc-11.5.0
sparc randconfig-002 gcc-11.5.0
sparc randconfig-002-20260513 gcc-11.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001 gcc-11.5.0
sparc64 randconfig-001-20260513 gcc-11.5.0
sparc64 randconfig-002 gcc-11.5.0
sparc64 randconfig-002-20260513 gcc-11.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001 gcc-11.5.0
um randconfig-001-20260513 gcc-11.5.0
um randconfig-002 gcc-11.5.0
um randconfig-002-20260513 gcc-11.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001 gcc-12
x86_64 buildonly-randconfig-001-20260513 gcc-12
x86_64 buildonly-randconfig-002 gcc-12
x86_64 buildonly-randconfig-002-20260513 gcc-12
x86_64 buildonly-randconfig-003 gcc-12
x86_64 buildonly-randconfig-003-20260513 gcc-12
x86_64 buildonly-randconfig-004 gcc-12
x86_64 buildonly-randconfig-004-20260513 gcc-12
x86_64 buildonly-randconfig-005 gcc-12
x86_64 buildonly-randconfig-005-20260513 gcc-12
x86_64 buildonly-randconfig-006 gcc-12
x86_64 buildonly-randconfig-006-20260513 gcc-12
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260513 clang-20
x86_64 randconfig-002-20260513 clang-20
x86_64 randconfig-003-20260513 clang-20
x86_64 randconfig-004-20260513 clang-20
x86_64 randconfig-005-20260513 clang-20
x86_64 randconfig-006-20260513 clang-20
x86_64 randconfig-011-20260513 gcc-14
x86_64 randconfig-012-20260513 gcc-14
x86_64 randconfig-013-20260513 gcc-14
x86_64 randconfig-014-20260513 gcc-14
x86_64 randconfig-015-20260513 gcc-14
x86_64 randconfig-016-20260513 gcc-14
x86_64 randconfig-071-20260513 gcc-14
x86_64 randconfig-072-20260513 gcc-14
x86_64 randconfig-073-20260513 gcc-14
x86_64 randconfig-074-20260513 gcc-14
x86_64 randconfig-075-20260513 gcc-14
x86_64 randconfig-076-20260513 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa allyesconfig gcc-15.2.0
xtensa randconfig-001 gcc-11.5.0
xtensa randconfig-001-20260513 gcc-11.5.0
xtensa randconfig-002 gcc-11.5.0
xtensa randconfig-002-20260513 gcc-11.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 5/6 RESEND] mfd: motorola-cpcap: diverge configuration per-board
From: Lee Jones @ 2026-05-13 14:05 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pavel Machek, David Lechner, Tony Lindgren, linux-input,
devicetree, linux-kernel, linux-leds
In-Reply-To: <CAPVz0n1Ubvj9MHHMcM2BpxAcTCCheMihr3aJUqcDVoi_V0OQ5g@mail.gmail.com>
On Thu, 07 May 2026, Svyatoslav Ryhel wrote:
> чт, 7 трав. 2026 р. о 17:05 Lee Jones <lee@kernel.org> пише:
> >
> > On Tue, 28 Apr 2026, Svyatoslav Ryhel wrote:
> >
> > > MFD have rigid subdevice structure which does not allow flexible dynamic
> > > subdevice linking. Address this by diverging CPCAP subdevice composition
> > > to take into account board specific configuration.
> > >
> > > Create a common default subdevice composition, rename existing subdevice
> > > composition into cpcap_mapphone_mfd_devices since it targets mainly
> > > Mapphone board.
> > >
> > > Removed st,6556002 as it is no longer applicable to all cases and
> > > duplicates motorola,cpcap, which is used as the default composition.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> >
> > Changelog?
> >
>
> Changelog is in the cover.
>
> > > drivers/mfd/motorola-cpcap.c | 101 ++++++++++++++++++++++++++++-------
> > > 1 file changed, 83 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> > > index d8243b956f87..516d1e33affa 100644
> > > --- a/drivers/mfd/motorola-cpcap.c
> > > +++ b/drivers/mfd/motorola-cpcap.c
> > > @@ -12,6 +12,7 @@
> > > #include <linux/kernel.h>
> > > #include <linux/module.h>
> > > #include <linux/mod_devicetable.h>
> > > +#include <linux/property.h>
> > > #include <linux/regmap.h>
> > > #include <linux/sysfs.h>
> > >
> > > @@ -24,10 +25,16 @@
> > > #define CPCAP_REGISTER_SIZE 4
> > > #define CPCAP_REGISTER_BITS 16
> > >
> > > +struct cpcap_chip_data {
> > > + const struct mfd_cell *mfd_devices;
> > > + unsigned int num_devices;
> > > +};
> >
> > This is a red flag.
> >
> > > struct cpcap_ddata {
> > > struct spi_device *spi;
> > > struct regmap_irq *irqs;
> > > struct regmap_irq_chip_data *irqdata[CPCAP_NR_IRQ_CHIPS];
> > > + const struct cpcap_chip_data *cdata;
> > > const struct regmap_config *regmap_conf;
> > > struct regmap *regmap;
> > > };
> > > @@ -195,20 +202,6 @@ static int cpcap_init_irq(struct cpcap_ddata *cpcap)
> > > return 0;
> > > }
> > >
> > > -static const struct of_device_id cpcap_of_match[] = {
> > > - { .compatible = "motorola,cpcap", },
> > > - { .compatible = "st,6556002", },
> > > - {},
> > > -};
> > > -MODULE_DEVICE_TABLE(of, cpcap_of_match);
> > > -
> > > -static const struct spi_device_id cpcap_spi_ids[] = {
> > > - { .name = "cpcap", },
> > > - { .name = "6556002", },
> > > - {},
> > > -};
> > > -MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
> > > -
> > > static const struct regmap_config cpcap_regmap_config = {
> > > .reg_bits = 16,
> > > .reg_stride = 4,
> > > @@ -241,7 +234,56 @@ static int cpcap_resume(struct device *dev)
> > >
> > > static DEFINE_SIMPLE_DEV_PM_OPS(cpcap_pm, cpcap_suspend, cpcap_resume);
> > >
> > > -static const struct mfd_cell cpcap_mfd_devices[] = {
> > > +static const struct mfd_cell cpcap_default_mfd_devices[] = {
> > > + {
> > > + .name = "cpcap_adc",
> > > + .of_compatible = "motorola,cpcap-adc",
> > > + }, {
> > > + .name = "cpcap_battery",
> > > + .of_compatible = "motorola,cpcap-battery",
> > > + }, {
> > > + .name = "cpcap-regulator",
> > > + .of_compatible = "motorola,cpcap-regulator",
> > > + }, {
> > > + .name = "cpcap-rtc",
> > > + .of_compatible = "motorola,cpcap-rtc",
> > > + }, {
> > > + .name = "cpcap-pwrbutton",
> > > + .of_compatible = "motorola,cpcap-pwrbutton",
> > > + }, {
> > > + .name = "cpcap-usb-phy",
> > > + .of_compatible = "motorola,cpcap-usb-phy",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 0,
> > > + .of_compatible = "motorola,cpcap-led-red",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 1,
> > > + .of_compatible = "motorola,cpcap-led-green",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 2,
> > > + .of_compatible = "motorola,cpcap-led-blue",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 3,
> > > + .of_compatible = "motorola,cpcap-led-adl",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 4,
> > > + .of_compatible = "motorola,cpcap-led-cp",
> > > + }, {
> > > + .name = "cpcap-codec",
> > > + },
> > > +};
> > > +
> > > +static const struct cpcap_chip_data cpcap_default_data = {
> > > + .mfd_devices = cpcap_default_mfd_devices,
> > > + .num_devices = ARRAY_SIZE(cpcap_default_mfd_devices),
> > > +};
> > > +
> > > +static const struct mfd_cell cpcap_mapphone_mfd_devices[] = {
> > > {
> > > .name = "cpcap_adc",
> > > .of_compatible = "motorola,mapphone-cpcap-adc",
> > > @@ -285,7 +327,12 @@ static const struct mfd_cell cpcap_mfd_devices[] = {
> > > .of_compatible = "motorola,cpcap-led-cp",
> > > }, {
> > > .name = "cpcap-codec",
> > > - }
> > > + },
> > > +};
> > > +
> > > +static const struct cpcap_chip_data cpcap_mapphone_data = {
> > > + .mfd_devices = cpcap_mapphone_mfd_devices,
> > > + .num_devices = ARRAY_SIZE(cpcap_mapphone_mfd_devices),
> > > };
> > >
> > > static int cpcap_probe(struct spi_device *spi)
> > > @@ -297,9 +344,17 @@ static int cpcap_probe(struct spi_device *spi)
> > > if (!cpcap)
> > > return -ENOMEM;
> > >
> > > + cpcap->cdata = device_get_match_data(&spi->dev);
> > > + if (!cpcap->cdata)
> > > + return -ENODEV;
> > > +
> > > cpcap->spi = spi;
> > > spi_set_drvdata(spi, cpcap);
> > >
> > > @@ -331,16 +382,24 @@ static int cpcap_probe(struct spi_device *spi)
> > > spi->dev.coherent_dma_mask = 0;
> > > spi->dev.dma_mask = &spi->dev.coherent_dma_mask;
> > >
> > > - return devm_mfd_add_devices(&spi->dev, 0, cpcap_mfd_devices,
> > > - ARRAY_SIZE(cpcap_mfd_devices), NULL, 0, NULL);
> > > + return devm_mfd_add_devices(&spi->dev, 0, cpcap->cdata->mfd_devices,
> > > + cpcap->cdata->num_devices, NULL, 0, NULL);
> > > }
> > >
> > > +static const struct of_device_id cpcap_of_match[] = {
> > > + { .compatible = "motorola,cpcap", .data = &cpcap_default_data },
> > > + { .compatible = "motorola,mapphone-cpcap", .data = &cpcap_mapphone_data },
> >
> > We don't allow data from one device registration API (MFD) to be passed
> > through another (OF) because it tends to lead to all sorts of "creative
> > solutions". Pass a value instead and match on that in a switch()
> > statement like all of the other MFD drivers do.
> >
>
> You don't allow this. I have not seen this enforced anywhere in the
> kernel except the mfd subsystem. Fine, does not matter, if this makes
> you happy I will adjust.
Where else would this rule be applicable? I can't think of anywhere.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v4 5/6 RESEND] mfd: motorola-cpcap: diverge configuration per-board
From: Lee Jones @ 2026-05-13 14:04 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Pavel Machek, David Lechner, Tony Lindgren, linux-input,
devicetree, linux-kernel, linux-leds
In-Reply-To: <CAPVz0n24U3=hwda5BTXUhHiiFHKmWUfLy_nxJp_CFHBHEYDWsA@mail.gmail.com>
On Thu, 07 May 2026, Svyatoslav Ryhel wrote:
> чт, 7 трав. 2026 р. о 17:05 Lee Jones <lee@kernel.org> пише:
> >
> > On Tue, 28 Apr 2026, Svyatoslav Ryhel wrote:
> >
> > > MFD have rigid subdevice structure which does not allow flexible dynamic
> > > subdevice linking. Address this by diverging CPCAP subdevice composition
> > > to take into account board specific configuration.
> > >
> > > Create a common default subdevice composition, rename existing subdevice
> > > composition into cpcap_mapphone_mfd_devices since it targets mainly
> > > Mapphone board.
> > >
> > > Removed st,6556002 as it is no longer applicable to all cases and
> > > duplicates motorola,cpcap, which is used as the default composition.
> > >
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > ---
> >
> > Changelog?
> >
> > > drivers/mfd/motorola-cpcap.c | 101 ++++++++++++++++++++++++++++-------
> > > 1 file changed, 83 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> > > index d8243b956f87..516d1e33affa 100644
> > > --- a/drivers/mfd/motorola-cpcap.c
> > > +++ b/drivers/mfd/motorola-cpcap.c
> > > @@ -12,6 +12,7 @@
> > > #include <linux/kernel.h>
> > > #include <linux/module.h>
> > > #include <linux/mod_devicetable.h>
> > > +#include <linux/property.h>
> > > #include <linux/regmap.h>
> > > #include <linux/sysfs.h>
> > >
> > > @@ -24,10 +25,16 @@
> > > #define CPCAP_REGISTER_SIZE 4
> > > #define CPCAP_REGISTER_BITS 16
> > >
> > > +struct cpcap_chip_data {
> > > + const struct mfd_cell *mfd_devices;
> > > + unsigned int num_devices;
> > > +};
> >
> > This is a red flag.
> >
> > > struct cpcap_ddata {
> > > struct spi_device *spi;
> > > struct regmap_irq *irqs;
> > > struct regmap_irq_chip_data *irqdata[CPCAP_NR_IRQ_CHIPS];
> > > + const struct cpcap_chip_data *cdata;
> > > const struct regmap_config *regmap_conf;
> > > struct regmap *regmap;
> > > };
> > > @@ -195,20 +202,6 @@ static int cpcap_init_irq(struct cpcap_ddata *cpcap)
> > > return 0;
> > > }
> > >
> > > -static const struct of_device_id cpcap_of_match[] = {
> > > - { .compatible = "motorola,cpcap", },
> > > - { .compatible = "st,6556002", },
> > > - {},
> > > -};
> > > -MODULE_DEVICE_TABLE(of, cpcap_of_match);
> > > -
> > > -static const struct spi_device_id cpcap_spi_ids[] = {
> > > - { .name = "cpcap", },
> > > - { .name = "6556002", },
> > > - {},
> > > -};
> > > -MODULE_DEVICE_TABLE(spi, cpcap_spi_ids);
> > > -
> > > static const struct regmap_config cpcap_regmap_config = {
> > > .reg_bits = 16,
> > > .reg_stride = 4,
> > > @@ -241,7 +234,56 @@ static int cpcap_resume(struct device *dev)
> > >
> > > static DEFINE_SIMPLE_DEV_PM_OPS(cpcap_pm, cpcap_suspend, cpcap_resume);
> > >
> > > -static const struct mfd_cell cpcap_mfd_devices[] = {
> > > +static const struct mfd_cell cpcap_default_mfd_devices[] = {
> > > + {
> > > + .name = "cpcap_adc",
> > > + .of_compatible = "motorola,cpcap-adc",
> > > + }, {
> > > + .name = "cpcap_battery",
> > > + .of_compatible = "motorola,cpcap-battery",
> > > + }, {
> > > + .name = "cpcap-regulator",
> > > + .of_compatible = "motorola,cpcap-regulator",
> > > + }, {
> > > + .name = "cpcap-rtc",
> > > + .of_compatible = "motorola,cpcap-rtc",
> > > + }, {
> > > + .name = "cpcap-pwrbutton",
> > > + .of_compatible = "motorola,cpcap-pwrbutton",
> > > + }, {
> > > + .name = "cpcap-usb-phy",
> > > + .of_compatible = "motorola,cpcap-usb-phy",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 0,
> > > + .of_compatible = "motorola,cpcap-led-red",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 1,
> > > + .of_compatible = "motorola,cpcap-led-green",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 2,
> > > + .of_compatible = "motorola,cpcap-led-blue",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 3,
> > > + .of_compatible = "motorola,cpcap-led-adl",
> > > + }, {
> > > + .name = "cpcap-led",
> > > + .id = 4,
> > > + .of_compatible = "motorola,cpcap-led-cp",
> > > + }, {
> > > + .name = "cpcap-codec",
> > > + },
> > > +};
>
> Lee, would you mind if I convert these mfd_cell structures to use
> macros in this commit since I am refactoring them anyway?
Sure.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH RESEND 2] HID: Add force feedback support for Speedlink Cougar Vibration Flightstick
From: Harald Judt @ 2026-05-13 13:12 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
In-Reply-To: <af5tJlRJr_GFTjVH@google.com>
Hi,
Am 09.05.26 um 01:14 schrieb Dmitry Torokhov:
[ ... ]
>>> + strong = (strong / 0xff) * 0x1f / 0xff;
>>> + weak = (weak / 0xff) * 0x1f / 0xff;
>>> +
>>> + /* ... and to support the notions of strong vs weak rumble effects,
>>> + * increase the magnitude for the strong rumble effect if it is below the
>>> + * half of the maximum value, as the strong motor has the same strength as
>>> + * the weak one. Likewise, decrease the magnitude for the weak effect.
>>> + */
>>> + if (strong < 0x10 && !weak) /* fftest effect 4 strong rumble */
>>> + strong *= 2;
>>> + else if (!strong && weak >= 0x10) /* fftest effect 5 weak rumble */
>>> + weak /= 2;
>>
>> Will this cause issues with non-monotonic force feedback behavior and
>> unintended truncation?
I thought about this too. I have not experienced any negative behavior with
this solution, the stick seems to work fine with it. But honestly, there
are not many tests available. fftest and SuperTuxKart have been the only
applications I found supporting force feedback, it worked fine there,
but the stick is also a bit limited in capabilities, it does not really
support "force feedback", only some degrees of rumble.
Since I wrote this patch some time passed and I have gained a bit more
experience with force feedback in general and implementing support for it.
>> Since the math uses integer division, any input value below 255 for strong
>> or weak will evaluate to zero during the first division by 0xff.
I am aware of this but IIRC this does not have any practical impact for
this stick. It seems to correspond to the values I got from the SET_REPORTs
in Windows and the vibrating behaviour.
>> Additionally, could the conditional scaling cause abrupt changes in rumble
>> strength? For instance, if a game requests a strong magnitude that scales
>> down to 15, it gets doubled to 30 because of the strong < 0x10 check.
>> However, a slightly stronger requested magnitude that scales to 16 will
>> remain 16, meaning an increase in requested strength results in a drop in
>> physical rumble.
True. I have tested this only with fftest and observed the behaviour in
SuperTuxKart, where it worked fine, as it uses both strong and weak
attributes. Existing implementations for other devices in the kernel
source I found sometimes use a "left" motor and a "right" motor,
other times a "strong" motor and a "weak" motor. But the games do a
variation of strong vs weak. So I finally decided to somehow get it
to work with the game I could test it with. I will do more checks
with other parameters/gain and try to improve this or think about
another, better solution. I might probably need to write some
ff tests myself for this, but why not...
>> [ ... ]
>>
>>> +static int gembird_joy_probe(struct hid_device *hdev, const struct hid_device_id *id)
>>> +{
>>> + int ret;
>>> +
>>> + ret = hid_parse(hdev);
>>> + if (ret) {
>>> + hid_err(hdev, "parse failed\n");
>>> + return ret;
>>> + }
>>> +
>>> + ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT & ~HID_CONNECT_FF);
>>> + if (ret) {
>>> + hid_err(hdev, "hw start failed\n");
>>> + return ret;
>>> + }
>>> +
>>> + gembird_joy_init(hdev);
>>> +
>>> + return 0;
>>> +}
>>
>> What happens if gembird_joy_init fails?
>>
>> If input_ff_create_memless returns an error, gembird_joy_init
>> propagates it, but the return value is ignored here and probe succeeds.
>>
>> Because set_bit(FF_RUMBLE, dev->ffbit) was already called, the device
>> remains registered and advertises rumble support. If userspace then issues
>> an EVIOCSFF ioctl, the kernel will allow it, which could lead to a panic
>> when it tries to dereference the missing force feedback structures.
>
> Need to have error handling.
I have looked at some other implementations, and if I have not missed
anything, then they do it similarly (hid-gaff.c, hid-sjoy.c, hid-emsff.c,
hid-megaworld.c). I will take a closer look again and try to fix it.
> Thanks.
Thank you for your suggestions and spending your time on this review.
I will try to improve it and send a new patch when ready.
Regards,
Harald
--
`Experience is the best teacher.'
PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD
^ permalink raw reply
* Re: [PATCH v2] HID: multitouch: Fix Yoga Book 9 14IAH10 touchscreen misclassification
From: Dave Carey @ 2026-05-13 12:57 UTC (permalink / raw)
To: Jiri Kosina; +Cc: linux-input, bentiss
In-Reply-To: <364r776o-6771-o29n-8ss3-857n32071op7@xreary.bet>
It's pretty rad. Have one more patch coming in a bit to fix a trailing
ghost touch issue.
On 5/12/26 11:39 AM, Jiri Kosina wrote:
> On Mon, 13 Apr 2026, Dave Carey wrote:
>
>> The Lenovo Yoga Book 9 14IAH10 (83KJ) (17EF:6161) firmware includes a
>> HID_DG_TOUCHPAD application collection designed for the Windows inbox HID
>> driver's Win8 PTP touchpad mode. On Linux the HID_DG_TOUCHSCREEN
>> collections provide the correct direct-touch interface. The presence of
>> the touchpad collection causes hid-multitouch to misclassify the
>> touchscreen nodes as indirect buttonpads, leaving them non-functional.
>>
>> Within the touchpad collection:
>> - HID_UP_BUTTON usages trigger the touchscreen-with-buttons heuristic
>> that sets INPUT_MT_POINTER on the touchscreen applications.
>> - The HID_DG_TOUCHPAD application itself sets INPUT_MT_POINTER via
>> mt_allocate_application(), propagating to all touchscreen nodes.
>> - A HID_DG_BUTTONTYPE feature (report 0x51) returns MT_BUTTONTYPE_CLICKPAD,
>> setting td->is_buttonpad = true for the entire device.
>>
>> Additionally, the firmware resets if any USB control request arrives while
>> the CDC-ACM interface is initialising (~1.18 s after enumeration).
>> The Win8 compliance blob (0xff00:0xc5) and Contact Count Max feature
>> reports in the touchscreen collections trigger GET_REPORT calls at probe
>> that hit this window. Surface Switch (0x57) and Button Switch (0x58)
>> feature reports are sent by mt_set_modes() on every input-device open and
>> close, repeatedly hitting this window throughout device lifetime.
>>
>> The firmware also leaves a persistent ghost contact in its contact buffer
>> (contact ID 2, fixed coordinates, tip always asserted) on every enumeration.
>> This ghost occupies a multitouch slot and prevents KWin from seeing a clean
>> finger-lift, causing stuck touch state. The ghost is cleared when Input
>> Mode is set via HID_REQ_SET_REPORT at probe.
> Oh man, what a device.
> Applied, thanks.
>
^ permalink raw reply
* Re: [PATCH RESEND 2] HID: Add force feedback support for Speedlink Cougar Vibration Flightstick
From: Harald Judt @ 2026-05-13 12:00 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <1q46pn22-177p-9no9-q4p7-4qq8n38po504@xreary.bet>
Hi,
Thanks for reviewing this.
Am 12.05.26 um 18:11 schrieb Jiri Kosina:
> On Fri, 8 May 2026, Harald Judt wrote:
[...]
>> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
>> index 04420a713be0..b4e2c8f67728 100644
>> --- a/drivers/hid/Kconfig
>> +++ b/drivers/hid/Kconfig
>> @@ -406,6 +406,14 @@ config HID_GEMBIRD
>> help
>> Support for Gembird JPD-DualForce 2.
>>
>> +config HID_GEMBIRD_JOY_FF
>> + tristate "Gembird Joysticks force feedback support"
>> + depends on USB_HID
>> + select INPUT_FF_MEMLESS
>> + help
>> + Force feedback support for Gembird (Vendor ID 0x12bd) based devices:
>> + - Speed Link Cougar Vibration Flightstick (SL-6630)
>> +
>> config HID_GFRM
>> tristate "Google Fiber TV Box remote control support"
>> help
>> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
>> index 361a7daedeb8..593a429661ed 100644
>> --- a/drivers/hid/Makefile
>> +++ b/drivers/hid/Makefile
>> @@ -54,6 +54,7 @@ obj-$(CONFIG_HID_EVISION) += hid-evision.o
>> obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
>> obj-$(CONFIG_HID_FT260) += hid-ft260.o
>> obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
>> +obj-$(CONFIG_HID_GEMBIRD_JOY_FF) += hid-gembird-joy.o
>
> Would it be possible to link this support to hid-gembird if enabled?
The problem I encountered is that gembird != gembird, that is,
the USB Vendor IDs differ. These are defined:
#define USB_VENDOR_ID_GEMBIRD 0x11ff
#define USB_DEVICE_ID_GEMBIRD_JPD_DUALFORCE2 0x3331
#define USB_VENDOR_ID_GEMBIRD_JOY 0x12bd
#define USB_DEVICE_ID_GEMBIRD_JOY_SL_6630 0xa02f
What would be the best way to solve this? Can my implementation
reside in separate files or should it be integrated into the
existing hid-gembird implementation? I am pretty new to
writing kernel modules, and doing it separately simply seemed
more suited for an easier start...
Regards,
Harald
--
`Experience is the best teacher.'
PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD
^ permalink raw reply
* [PATCH 1/1] HID: wacom: Fix OOB write in wacom_hid_set_device_mode()
From: Lee Jones @ 2026-05-13 7:59 UTC (permalink / raw)
To: lee, Ping Cheng, Jason Gerecke, Jiri Kosina, Benjamin Tissoires,
linux-input, linux-kernel
Cc: stable
wacom_hid_set_device_mode() currently assumes that the HID_DG_INPUTMODE
usage is always located in the first field (field[0]) of the feature report.
However, a device can specify HID_DG_INPUTMODE in a different field.
If HID_DG_INPUTMODE is in a field other than the first one and the first
field has a report_count smaller than the usage_index of HID_DG_INPUTMODE,
this leads to an out-of-bounds write to r->field[0]->value.
Fix this by storing the field index of HID_DG_INPUTMODE in 'struct
hid_data' during feature mapping. In wacom_hid_set_device_mode(), use
this stored field index to access the correct field and add bounds
checks to ensure both the field index and the value index are within
valid ranges before writing.
Cc: stable@vger.kernel.org
Fixes: 5ae6e89f7409 ("HID: wacom: implement the finger part of the HID generic handling")
Signed-off-by: Lee Jones <lee@kernel.org>
---
drivers/hid/wacom_sys.c | 13 ++++++++++---
drivers/hid/wacom_wac.h | 1 +
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 1b1112772777..a6c5281afa06 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -341,6 +341,7 @@ static void wacom_feature_mapping(struct hid_device *hdev,
hid_data->inputmode = field->report->id;
hid_data->inputmode_index = usage->usage_index;
+ hid_data->inputmode_field_index = field->index;
break;
case HID_UP_DIGITIZER:
@@ -556,9 +557,14 @@ static int wacom_hid_set_device_mode(struct hid_device *hdev)
re = &(hdev->report_enum[HID_FEATURE_REPORT]);
r = re->report_id_hash[hid_data->inputmode];
- if (r) {
- r->field[0]->value[hid_data->inputmode_index] = 2;
- hid_hw_request(hdev, r, HID_REQ_SET_REPORT);
+ if (r && hid_data->inputmode_field_index >= 0 &&
+ hid_data->inputmode_field_index < r->maxfield) {
+ struct hid_field *field = r->field[hid_data->inputmode_field_index];
+
+ if (field && hid_data->inputmode_index < field->report_count) {
+ field->value[hid_data->inputmode_index] = 2;
+ hid_hw_request(hdev, r, HID_REQ_SET_REPORT);
+ }
}
return 0;
}
@@ -2819,6 +2825,7 @@ static int wacom_probe(struct hid_device *hdev,
return error;
wacom_wac->hid_data.inputmode = -1;
+ wacom_wac->hid_data.inputmode_field_index = -1;
wacom_wac->mode_report = -1;
if (hid_is_usb(hdev)) {
diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
index c8803d5c6a71..b2e74d7ab3c4 100644
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -298,6 +298,7 @@ struct wacom_shared {
struct hid_data {
__s16 inputmode; /* InputMode HID feature, -1 if non-existent */
__s16 inputmode_index; /* InputMode HID feature index in the report */
+ __s16 inputmode_field_index; /* InputMode HID feature field index in the report */
bool sense_state;
bool inrange_state;
bool invert_state;
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH] Input: elan_i2c - prevent division by zero on invalid device parameters
From: Ranjan Kumar @ 2026-05-13 7:39 UTC (permalink / raw)
To: dmitry.torokhov
Cc: bleung, dusonlin, bentiss, linux-input, linux-kernel,
Ranjan Kumar
The Elan I2C touchpad driver queries the device for its physical
dimensions and trace counts to calculate the device resolution and width.
However, if the device firmware or device tree provides invalid zero
values for x_traces, y_traces, x_mm, or y_mm, it results in a fatal
division-by-zero exception leading to a kernel panic during device probe.
Add sanity checks to ensure these physical parameters are non-zero
before performing the division. If invalid values are detected, log an
error and return -EINVAL to gracefully abort the initialization and
maintain system stability.
Fixes: 6696777c6506 ("Input: add driver for Elan I2C/SMbus touchpad")
Fixes: e3a9a1290688 ("Input: elan_i2c - do not query the info if they are provided")
Signed-off-by: Ranjan Kumar <kumarranja@chromium.org>
---
drivers/input/mouse/elan_i2c_core.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index fee1796da3d0..b5fd63928afd 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -425,6 +425,14 @@ static int elan_query_device_parameters(struct elan_tp_data *data)
if (error)
return error;
}
+
+ if (unlikely(x_traces == 0 || y_traces == 0)) {
+ dev_err(&client->dev,
+ "Invalid trace numbers: x=%u, y=%u\n",
+ x_traces, y_traces);
+ return -EINVAL;
+ }
+
data->width_x = data->max_x / x_traces;
data->width_y = data->max_y / y_traces;
@@ -440,6 +448,14 @@ static int elan_query_device_parameters(struct elan_tp_data *data)
data->x_res = elan_convert_resolution(hw_x_res, data->pattern);
data->y_res = elan_convert_resolution(hw_y_res, data->pattern);
} else {
+
+ if (unlikely(x_mm == 0 || y_mm == 0)) {
+ dev_err(&client->dev,
+ "Invalid physical dimensions: x_mm=%u, y_mm=%u\n",
+ x_mm, y_mm);
+ return -EINVAL;
+ }
+
data->x_res = (data->max_x + 1) / x_mm;
data->y_res = (data->max_y + 1) / y_mm;
}
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH] HID: mcp2221: Fix heap buffer overflow in mcp2221_raw_event()
From: Benoît Sevens @ 2026-05-13 7:22 UTC (permalink / raw)
To: Jiri Kosina
Cc: Rishi Gupta, Benjamin Tissoires, linux-i2c, linux-input,
linux-kernel
In-Reply-To: <417rqoq0-1q2q-r96q-p258-240n74nr3n14@xreary.bet>
On Tue, 12 May 2026 at 17:47, Jiri Kosina <jikos@kernel.org> wrote:
>
> On Wed, 15 Apr 2026, Benoit Sevens wrote:
>
> > From: Benoît Sevens <bsevens@google.com>
> >
> > A heap buffer overflow can occur in the mcp2221_raw_event() function
> > when handling I2C read responses. The driver failed to check if the
> > total incoming data length fits within the originally allocated buffer
> > `mcp->rxbuf`.
> >
> > Fix this by introducing `rxbuf_len` to `struct mcp2221` to keep track
> > of the allocated buffer size. Initialize it in `mcp_i2c_smbus_read()`
> > and `mcp_smbus_xfer()`, and ensure the copied data length combined with
> > the current index does not exceed this length in `mcp2221_raw_event()`.
> >
> > Signed-off-by: Benoît Sevens <bsevens@google.com>
>
> Unfortunately the patch seems to have been somehow mangled by your mail
> client:
>
> patching file drivers/hid/hid-mcp2221.c
> Hunk #1 succeeded at 126 (offset 7 lines).
> Hunk #2 FAILED at 324.
> patch: **** malformed patch at line 173: u16 addr,
>
> Fix for the same issue has later been submitted by Florian Pradines [1],
> so I will be taking that one and adding you as Reported-by: or so, ok?
>
> Thanks.
>
> [1] https://lore.kernel.org/all/20260509094517.2691246-1-florian.pradines@gmail.com/
>
> --
> Jiri Kosina
> SUSE Labs
>
Hi Jiri,
That sounds good to me. Thanks for adding me in the Reported-by
One thing though: Florian's patch doesn't set `mcp->rxbuf_size` in all
places. I believe it should be set in every place where `mcp->rxbuf`
is set. There are 2 places in `mcp_smbus_xfer` where it is missing
(see my original patch):
```c
@@ -538,6 +541,7 @@ static int mcp_smbus_xfer(struct i2c_adapter
*adapter, u16 addr,
mcp->rxbuf_idx = 0;
mcp->rxbuf = data->block;
+ mcp->rxbuf_size = sizeof(data->block);
mcp->txbuf[0] = MCP2221_I2C_GET_DATA;
ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
if (ret)
@@ -561,6 +565,7 @@ static int mcp_smbus_xfer(struct i2c_adapter
*adapter, u16 addr,
mcp->rxbuf_idx = 0;
mcp->rxbuf = data->block;
+ mcp->rxbuf_size = sizeof(data->block);
mcp->txbuf[0] = MCP2221_I2C_GET_DATA;
ret = mcp_send_data_req_status(mcp, mcp->txbuf, 1);
if (ret)
```
Thanks,
Benoit
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS 6f89d96fff65aec1ff12bc566fca0eb1bb59e16e
From: kernel test robot @ 2026-05-13 7:09 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 6f89d96fff65aec1ff12bc566fca0eb1bb59e16e Input: atlas - check ACPI_COMPANION() against NULL
elapsed time: 778m
configs tested: 212
configs skipped: 9
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260513 gcc-14.3.0
arc randconfig-002-20260513 gcc-14.3.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm gemini_defconfig clang-20
arm randconfig-001-20260513 gcc-14.3.0
arm randconfig-002-20260513 gcc-14.3.0
arm randconfig-003-20260513 gcc-14.3.0
arm randconfig-004-20260513 gcc-14.3.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260513 clang-23
arm64 randconfig-001-20260513 gcc-12.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260513 clang-23
arm64 randconfig-002-20260513 gcc-12.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260513 clang-23
arm64 randconfig-003-20260513 gcc-12.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260513 clang-23
arm64 randconfig-004-20260513 gcc-12.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001 clang-23
csky randconfig-001-20260513 clang-23
csky randconfig-001-20260513 gcc-12.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260513 clang-23
csky randconfig-002-20260513 gcc-12.5.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260513 gcc-8.5.0
hexagon randconfig-002-20260513 gcc-8.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260513 clang-20
i386 buildonly-randconfig-002-20260513 clang-20
i386 buildonly-randconfig-003-20260513 clang-20
i386 buildonly-randconfig-004-20260513 clang-20
i386 buildonly-randconfig-005-20260513 clang-20
i386 buildonly-randconfig-006-20260513 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260513 clang-20
i386 randconfig-002-20260513 clang-20
i386 randconfig-003-20260513 clang-20
i386 randconfig-004-20260513 clang-20
i386 randconfig-005-20260513 clang-20
i386 randconfig-006-20260513 clang-20
i386 randconfig-007-20260513 clang-20
i386 randconfig-011-20260513 clang-20
i386 randconfig-012-20260513 clang-20
i386 randconfig-012-20260513 gcc-14
i386 randconfig-013-20260513 clang-20
i386 randconfig-014-20260513 clang-20
i386 randconfig-015-20260513 clang-20
i386 randconfig-016-20260513 clang-20
i386 randconfig-017-20260513 clang-20
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260513 gcc-8.5.0
loongarch randconfig-002-20260513 gcc-8.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k atari_defconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips maltaup_xpa_defconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260513 gcc-8.5.0
nios2 randconfig-002-20260513 gcc-8.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260513 gcc-8.5.0
parisc randconfig-002-20260513 gcc-8.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc mpc834x_itx_defconfig clang-16
powerpc rainier_defconfig gcc-15.2.0
powerpc randconfig-001-20260513 gcc-8.5.0
powerpc randconfig-002-20260513 gcc-8.5.0
powerpc64 randconfig-001-20260513 gcc-8.5.0
powerpc64 randconfig-002-20260513 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260513 gcc-15.2.0
riscv randconfig-002-20260513 gcc-15.2.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260513 gcc-15.2.0
s390 randconfig-002-20260513 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260513 gcc-15.2.0
sh randconfig-002-20260513 gcc-15.2.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260513 gcc-11.5.0
sparc randconfig-002-20260513 gcc-11.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260513 gcc-11.5.0
sparc64 randconfig-002-20260513 gcc-11.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260513 gcc-11.5.0
um randconfig-002-20260513 gcc-11.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260513 gcc-12
x86_64 buildonly-randconfig-002-20260513 gcc-12
x86_64 buildonly-randconfig-003-20260513 gcc-12
x86_64 buildonly-randconfig-004-20260513 gcc-12
x86_64 buildonly-randconfig-005-20260513 gcc-12
x86_64 buildonly-randconfig-006-20260513 gcc-12
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260513 clang-20
x86_64 randconfig-002-20260513 clang-20
x86_64 randconfig-003-20260513 clang-20
x86_64 randconfig-004-20260513 clang-20
x86_64 randconfig-005-20260513 clang-20
x86_64 randconfig-006-20260513 clang-20
x86_64 randconfig-011-20260513 gcc-14
x86_64 randconfig-012-20260513 gcc-14
x86_64 randconfig-013-20260513 gcc-14
x86_64 randconfig-014-20260513 gcc-14
x86_64 randconfig-015-20260513 gcc-14
x86_64 randconfig-016-20260513 gcc-14
x86_64 randconfig-071-20260513 gcc-14
x86_64 randconfig-072-20260513 gcc-14
x86_64 randconfig-073-20260513 gcc-14
x86_64 randconfig-074-20260513 gcc-14
x86_64 randconfig-075-20260513 gcc-14
x86_64 randconfig-076-20260513 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260513 gcc-11.5.0
xtensa randconfig-002-20260513 gcc-11.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] HID: google: hammer: stop hardware on devres action failure
From: Myeonghun Pak @ 2026-05-13 6:52 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <42o9po52-64po-n8o8-or3q-q439o09s2p0p@xreary.bet>
Dear Jiri,
Thanks for applying the patch.
Best regards,
Myeonghun
2026년 5월 13일 (수) 오전 1:01, Jiri Kosina <jikos@kernel.org>님이 작성:
>
> On Fri, 24 Apr 2026, 박명훈 wrote:
>
> > From: Myeonghun Pak <mhun512@gmail.com>
> >
> > hammer_probe() starts the HID hardware before registering the devres
> > action that stops it. If devm_add_action() fails, probe returns an
> > error with the hardware still started because the cleanup action was
> > never registered and the driver's remove callback is not called after a
> > failed probe.
> >
> > Use devm_add_action_or_reset() so the stop action runs immediately on
> > registration failure while preserving the existing devres-managed cleanup
> > path for later probe failures and remove.
> >
> > Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> > ---
> > drivers/hid/hid-google-hammer.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
> > index 1af477e584..c99c3c0d44 100644
> > --- a/drivers/hid/hid-google-hammer.c
> > +++ b/drivers/hid/hid-google-hammer.c
> > @@ -496,7 +496,7 @@ static int hammer_probe(struct hid_device *hdev,
> > if (error)
> > return error;
> >
> > - error = devm_add_action(&hdev->dev, hammer_stop, hdev);
> > + error = devm_add_action_or_reset(&hdev->dev, hammer_stop, hdev);
>
> Makes sense, thanks for catching it. Applied.
>
> --
> Jiri Kosina
> SUSE Labs
>
^ permalink raw reply
* [PATCH] Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490
From: contacto @ 2026-05-13 4:57 UTC (permalink / raw)
To: dmitry.torokhov; +Cc: linux-input, linux-kernel, Nicolás Bazaes
From: Nicolás Bazaes <contacto@bazaes.cl>
The Lenovo ThinkPad E490 (PNP ID: LEN2058) has a Synaptics TM3471-020
touchpad that supports SMBus/RMI4 mode but is not listed in
smbus_pnp_ids[]. Without this entry, psmouse ignores the
synaptics_intertouch parameter and falls back to PS/2 mode even when
explicitly requested.
Adding LEN2058 to the passlist enables RMI4 over SMBus, which provides
better multitouch support and matches the behavior of similar ThinkPad
models already in the list (E480/LEN2054, E580/LEN2055).
Tested on ThinkPad E490 with kernel 7.0.5-zen1 and Arch Linux.
Signed-off-by: Nicolás Bazaes <contacto@bazaes.cl>
Assisted-by: Claude <claude.ai>
---
drivers/input/mouse/synaptics.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 26071128f..c70502e24 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -190,6 +190,7 @@ static const char * const smbus_pnp_ids[] = {
"LEN2044", /* L470 */
"LEN2054", /* E480 */
"LEN2055", /* E580 */
+ "LEN2058", /* E490 */
"LEN2068", /* T14 Gen 1 */
"SYN1221", /* TUXEDO InfinityBook Pro 14 v5 */
"SYN3003", /* HP EliteBook 850 G1 */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 6/6] iio: pressure: HID: hid-sensor-press: Refactor channel initialization
From: sashiko-bot @ 2026-05-13 3:30 UTC (permalink / raw)
To: Natália Salvino André; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260512012302.20883-7-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The struct iio_scan_type compound literal uses a non-existent field `.format` instead of `.sign`.
--
commit a042b8c22df5e0522e82213c0d6f025b115babe7
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: pressure: HID: hid-sensor-press: Refactor channel initialization
This commit refactors the initialization of the pressure sensor's scan_type
by replacing a local helper function with a compound literal to improve
code readability.
> diff --git a/drivers/iio/pressure/hid-sensor-press.c b/drivers/iio/pressure/hid-sensor-press.c
> index 5f1d6abda3e40..a039b99d9851d 100644
> --- a/drivers/iio/pressure/hid-sensor-press.c
> +++ b/drivers/iio/pressure/hid-sensor-press.c
[ ... ]
> @@ -225,8 +215,11 @@ static int press_parse_report(struct platform_device *pdev,
> &st->press_attr);
> if (ret < 0)
> return ret;
> - press_adjust_channel_bit_mask(channels, CHANNEL_SCAN_INDEX_PRESSURE,
> - st->press_attr.size);
> + channels[CHANNEL_SCAN_INDEX_PRESSURE].scan_type = (struct iio_scan_type) {
> + .format = 's',
Is .format correct here? Looking at struct iio_scan_type in
include/linux/iio/iio.h, it appears the member for indicating the sign is
named .sign, not .format.
Could this assignment cause a compilation error due to a missing member?
> + .realbits = BYTES_TO_BITS(st->press_attr.size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
>
> dev_dbg(&pdev->dev, "press %x:%x\n", st->press_attr.index,
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512012302.20883-1-natalia.andre@ime.usp.br?part=6
^ permalink raw reply
* RE: [PATCH v3 0/6] iio: hid-sensor: standardize scan_type initialization
From: Zhang, Lixu @ 2026-05-13 3:27 UTC (permalink / raw)
To: Jonathan Cameron, Natália Salvino André
Cc: andy@kernel.org, Lechner, David, jikos@kernel.org,
nuno.sa@analog.com, srinivas.pandruvada@linux.intel.com,
linux-iio@vger.kernel.org, linux-input@vger.kernel.org
In-Reply-To: <20260512154853.10aa2902@jic23-huawei>
>-----Original Message-----
>From: Jonathan Cameron <jic23@kernel.org>
>Sent: Tuesday, May 12, 2026 10:49 PM
>To: Natália Salvino André <natalia.andre@ime.usp.br>
>Cc: andy@kernel.org; Lechner, David <dlechner@baylibre.com>;
>jikos@kernel.org; nuno.sa@analog.com; srinivas.pandruvada@linux.intel.com;
>linux-iio@vger.kernel.org; linux-input@vger.kernel.org; Zhang, Lixu
><lixu.zhang@intel.com>
>Subject: Re: [PATCH v3 0/6] iio: hid-sensor: standardize scan_type initialization
>
>On Mon, 11 May 2026 22:16:16 -0300
>Natália Salvino André <natalia.andre@ime.usp.br> wrote:
>
>> This series refactors the HID sensor drivers to standardize the
>> initialization of the iio_chan_spec scan_type structure.
>> Direct initialization using compound literals was used.
>>
>> This change improves code readability and ensures that all fields of
>> the scan_type structure are properly zero-initialized.
>> Additionally, for the hid-sensor-accel-3d driver, the channel
>> initialization loop was refactored to iterate directly over the scan
>> indices, eliminating redundant logic.
>
>Series looks good to me but I'll leave it on the list a while to both let sashiko catch
>up and anyone else who wants to can have time to look. Also ideally get some
>testing.
>
>Lixu, if you don't mind, please can you give this a test on top of the more radical
>refactor patches?
Sure, I'll test this series on top of the refactor patches when I have some time.
Thanks,
Lixu
>
>To me it looks safe enough but this is the sort of series that subtle typos can hide
>in!
>
>Thanks,
>
>Jonathan
>
^ permalink raw reply
* Re: [PATCH v3 5/6] iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel initialization
From: sashiko-bot @ 2026-05-13 3:19 UTC (permalink / raw)
To: Natália Salvino André; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260512012302.20883-6-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The refactored code uses a non-existent member `.format` in `struct iio_scan_type` instead of `.sign`, leading to a compilation error.
--
commit 579bb9f2450aced0e3f18e7e7316e70845e6e72b
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: magnetometer: HID: hid-sensor-magn-3d: Refactor channel initialization
This commit replaces the local magn_3d_adjust_channel_bit_mask() function
with a compound literal for scan_type initialization to improve code
readability.
> diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> index c673f9323e476..3b26dc41dd4cf 100644
> --- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> +++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
[ ... ]
> @@ -418,9 +408,11 @@ static int magn_3d_parse_report(struct platform_device *pdev,
> if (i != CHANNEL_SCAN_INDEX_TIMESTAMP) {
> /* Set magn_val_addr to iio value address */
> st->magn_val_addr[i] = &st->iio_vals[*chan_count];
> - magn_3d_adjust_channel_bit_mask(_channels,
> - *chan_count,
> - st->magn[i].size);
> + _channels[*chan_count].scan_type = (struct iio_scan_type) {
> + .format = 's',
Will this regression cause a compilation error?
Looking at struct iio_scan_type in include/linux/iio/iio.h, there is a member
named sign, but no member named format.
For example, other channel setups use sign:
include/linux/iio/iio.h:
#define IIO_CHAN_SOFT_TIMESTAMP(_si) { \
... \
.scan_type = { \
.sign = 's', \
.realbits = 64, \
.storagebits = 64, \
}, \
}
Should this compound literal be updated to use .sign = 's' instead?
> + .realbits = BYTES_TO_BITS(st->magn[i].size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
> }
> (*chan_count)++;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512012302.20883-1-natalia.andre@ime.usp.br?part=5
^ permalink raw reply
* Re: [PATCH v3 4/6] iio: light: HID: hid-sensor-prox: Refactor channel initialization
From: sashiko-bot @ 2026-05-13 3:10 UTC (permalink / raw)
To: Natália Salvino André; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260512012302.20883-5-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces a compilation error by incorrectly initializing a non-existent '.format' field in `struct iio_scan_type`.
--
commit b9cbff53934f8976c34e3030a4b171bfc276e140
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: light: HID: hid-sensor-prox: Refactor channel initialization
This commit refactors the initialization of the scan_type field for proximity
sensor channels by replacing the prox_adjust_channel_bit_mask() function with
a compound literal.
> diff --git a/drivers/iio/light/hid-sensor-prox.c b/drivers/iio/light/hid-sensor-prox.c
> index efa904a70d0ef..edc9274a2c076 100644
> --- a/drivers/iio/light/hid-sensor-prox.c
> +++ b/drivers/iio/light/hid-sensor-prox.c
[ ... ]
> @@ -250,8 +240,11 @@ static int prox_parse_report(struct platform_device *pdev,
> st->scan_mask[0] |= BIT(index);
> channels[index] = prox_channels[i];
> channels[index].scan_index = index;
> - prox_adjust_channel_bit_mask(channels, index,
> - st->prox_attr[index].size);
> + channels[index].scan_type = (struct iio_scan_type) {
> + .format = 's',
Will this cause a compilation error? struct iio_scan_type does not have a
member named format. The previous code set the sign member to 's'. Should
this be .sign instead of .format?
> + .realbits = BYTES_TO_BITS(st->prox_attr[index].size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
> dev_dbg(&pdev->dev, "prox %x:%x\n", st->prox_attr[index].index,
> st->prox_attr[index].report_id);
> st->scale_precision[index] =
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512012302.20883-1-natalia.andre@ime.usp.br?part=4
^ permalink raw reply
* Re: [PATCH v3 3/6] iio: light: HID: hid-sensor-als: Refactor channel initialization
From: sashiko-bot @ 2026-05-13 3:00 UTC (permalink / raw)
To: Natália Salvino André; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260512012302.20883-4-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch introduces a build error by initializing a non-existent `.format` field in `struct iio_scan_type`.
--
commit 0b0eb5f75d5c3745616a7e7de9ace24a35760cff
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: light: HID: hid-sensor-als: Refactor channel initialization
This commit replaces the local als_adjust_channel_bit_mask() function
with a compound literal for scan_type initialization to improve code
readability.
> diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
> index 830e5ae7f34a7..e5b4c5e80f1cf 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c
[ ... ]
> @@ -334,7 +324,11 @@ static int als_parse_report(struct platform_device *pdev,
>
> channels[index] = als_channels[i];
> st->als_scan_mask[0] |= BIT(i);
> - als_adjust_channel_bit_mask(channels, index, st->als[i].size);
> + channels[index].scan_type = (struct iio_scan_type) {
> + .format = 's',
Does this cause a build failure? Looking at struct iio_scan_type in
include/linux/iio/iio.h, there is no field named format.
The removed code assigned this value to the sign field:
channels[channel].scan_type.sign = 's';
Should this compound literal initialize .sign instead of .format?
> + .realbits = BYTES_TO_BITS(st->als[i].size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
> ++index;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512012302.20883-1-natalia.andre@ime.usp.br?part=3
^ permalink raw reply
* Re: [PATCH v3 2/6] iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
From: sashiko-bot @ 2026-05-13 2:50 UTC (permalink / raw)
To: Natália Salvino André; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260512012302.20883-3-natalia.andre@ime.usp.br>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The struct iio_scan_type does not have a member named 'format', which causes a build failure.
--
commit 8a26f68e644f245021a8896a54c6e164b2d81277
Author: Natália Salvino André <natalia.andre@ime.usp.br>
iio: gyro: HID: hid-sensor-gyro-3d: Refactor channel initialization
This commit refactors the channel initialization in the hid-sensor-gyro-3d
driver by replacing the local gyro_3d_adjust_channel_bit_mask function with
a compound literal for scan_type initialization to improve readability.
> diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c b/drivers/iio/gyro/hid-sensor-gyro-3d.c
> index c43990c518f77..be8406da32f0e 100644
> --- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
> +++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
[ ... ]
> -/* Adjust channel real bits based on report descriptor */
> -static void gyro_3d_adjust_channel_bit_mask(struct iio_chan_spec *channels,
> - int channel, int size)
> -{
> - channels[channel].scan_type.sign = 's';
> - /* Real storage bits will change based on the report desc. */
> - channels[channel].scan_type.realbits = size * 8;
> - /* Maximum size of a sample to capture is u32 */
> - channels[channel].scan_type.storagebits = sizeof(u32) * 8;
> -}
> -
[ ... ]
> @@ -251,16 +241,20 @@ static int gyro_3d_parse_report(struct platform_device *pdev,
> int i;
>
> for (i = 0; i <= CHANNEL_SCAN_INDEX_Z; ++i) {
[ ... ]
> - gyro_3d_adjust_channel_bit_mask(channels,
> - CHANNEL_SCAN_INDEX_X + i,
> - st->gyro[CHANNEL_SCAN_INDEX_X + i].size);
> + channels[ch].scan_type = (struct iio_scan_type) {
> + .format = 's',
Will this cause a build failure?
Struct iio_scan_type defines the field as sign, not format. The original
code being replaced here correctly assigned the value using
channels[channel].scan_type.sign = 's'.
> + .realbits = BYTES_TO_BITS(st->gyro[ch].size),
> + .storagebits = BITS_PER_TYPE(u32),
> + };
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260512012302.20883-1-natalia.andre@ime.usp.br?part=2
^ permalink raw reply
* [PATCH v2] HID: lenovo: Fix buffer over-read and unaligned access in X12 Tab raw_event handler
From: Kean @ 2026-05-13 2:40 UTC (permalink / raw)
To: Derek J . Clark, Mark Pearson, linux-input
Cc: Kean, Jiri Kosina, Benjamin Tissoires, linux-kernel
In-Reply-To: <20260511132854.1351379-1-rh_king%40163.com>
In lenovo_raw_event(), the X12 Tab keyboard handler reads a 4-byte
little-endian value via *(__le32 *)data but only guards the access
with a size >= 3 check. If a 3-byte report with ID 0x03 is received,
the code reads one byte beyond the end of the buffer.
Change the size check to >= 4 to match the actual access width.
Additionally, casting a u8 *data pointer directly to __le32 * can
trigger unaligned access faults on architectures that enforce memory
alignment (ARM, MIPS, SPARC). The HID core provides no alignment
guarantee for the data buffer — for example, uhid payloads via
UHID_INPUT2 start at offset 6 in the uhid_event struct, giving only
2-byte alignment.
Use get_unaligned_le32() to safely read the little-endian value
regardless of the buffer's alignment. get_unaligned_le32() already
handles the LE-to-CPU conversion, so the le32_to_cpu() wrapper is
no longer needed.
Signed-off-by: Kean <rh_king@163.com>
---
Thank you for the review!
Both issues you identified are correct. This v2 addresses both memory
safety concerns in one patch:
1. Buffer over-read: size >= 3 → size >= 4 to match the 4-byte access.
2. Unaligned access: *( __le32 *)data cast → get_unaligned_le32(data),
which safely handles the uhid scenario you described (2-byte alignment
at offset 6 of uhid_event). get_unaligned_le32() already does the
LE-to-CPU conversion so le32_to_cpu() is no longer needed.
Regarding the missing key capability registration — you are correct
that these hotkey events would be silently dropped by the input core.
I'll need some time to reproduce and test this on the actual hardware
before submitting a separate patch for it.
drivers/hid/hid-lenovo.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index a6b73e03c16b..10c86f4e1467 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -31,6 +31,7 @@
#include <linux/input.h>
#include <linux/leds.h>
#include <linux/workqueue.h>
+#include <linux/unaligned.h>
#include "hid-ids.h"
@@ -793,8 +794,8 @@ static int lenovo_raw_event(struct hid_device *hdev,
*/
if (unlikely((hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB
|| hdev->product == USB_DEVICE_ID_LENOVO_X12_TAB2)
- && size >= 3 && report->id == 0x03))
- return lenovo_raw_event_TP_X12_tab(hdev, le32_to_cpu(*(__le32 *)data));
+ && size >= 4 && report->id == 0x03))
+ return lenovo_raw_event_TP_X12_tab(hdev, get_unaligned_le32(data));
return 0;
}
--
2.47.3
^ permalink raw reply related
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