* Re: [PATCH v2 9/9] Input: cap11xx - add support for CAP1114
From: sashiko-bot @ 2026-06-12 7:42 UTC (permalink / raw)
To: Jun Yan; +Cc: dmitry.torokhov, linux-input, devicetree, robh, conor+dt
In-Reply-To: <20260612072237.1177304-10-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Buffer overflow when parsing the 'microchip,calib-sensitivity' device tree property for devices with more than 8 channels.
- [Medium] Integer truncation silently drops signal guard configurations for channels 8-13.
- [Low] Out-of-bounds `GENMASK` generates an 11-bit mask for an 8-bit LED control register.
- [Low] Unnecessary 9th threshold register added to regmap defaults.
--
commit a843fc20f78c2766e479b33ffb3dcd6238d1f3f0
Author: Jun Yan <jerrysteve1101@gmail.com>
Input: cap11xx - add support for CAP1114
CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
and hardware reset support. The CAP1114 uses two control registers
for LED output management and requires two button status registers
for touch input state reporting.
> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index d45bb231d7a1f..e4da0e26c34a8 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
[ ... ]
> @@ -98,6 +105,9 @@ static const struct reg_default cap11xx_reg_defaults[] = {
> { CAP11XX_REG_SENSOR_THRESH(3), 0x40 },
> { CAP11XX_REG_SENSOR_THRESH(4), 0x40 },
> { CAP11XX_REG_SENSOR_THRESH(5), 0x40 },
> + { CAP11XX_REG_SENSOR_THRESH(6), 0x40 },
> + { CAP11XX_REG_SENSOR_THRESH(7), 0x40 },
> + { CAP11XX_REG_SENSOR_THRESH(8), 0x40 },
[Severity: Low]
Does this code inadvertently add a 9th threshold register?
Since the indexing is 0-based, an 8-threshold device should only need indices
0 through 7.
Register index 8 appears to map to an unused register.
> { CAP11XX_REG_CONFIG2, 0x40 },
> };
[ ... ]
> @@ -394,6 +442,14 @@ static int cap11xx_init_leds(struct device *dev,
> if (error)
> return error;
>
> + if (num_leds > 8) {
> + error = regmap_update_bits(priv->regmap,
> + priv->model->led_output_control_reg_base + 1,
> + GENMASK(num_leds - 8 - 1, 0), 0);
[Severity: Low]
Can this result in an out-of-bounds mask generation when num_leds > 8?
In cap11xx_init_leds() just prior to this addition, the code calls:
error = regmap_update_bits(priv->regmap,
priv->model->led_output_control_reg_base,
GENMASK(num_leds - 1, 0), 0);
When num_leds is 11 for the CAP1114 model, this generates an 11-bit mask
to update an 8-bit register.
While the regmap core safely masks this, should the mask be clamped to
min(num_leds, 8) to accurately reflect the hardware register's capacity?
> + if (error)
> + return error;
> + }
[ ... ]
> @@ -572,6 +628,14 @@ static const struct cap11xx_hw_model cap1106_model = {
> .has_repeat_en = true,
> };
>
> +static const struct cap11xx_hw_model cap1114_model = {
> + .product_id = 0x3a,
> + .num_channels = 14, .num_leds = 11, .num_sensor_thresholds = 8,
[Severity: High]
Does this code overflow the calib_sensitivities array during initialization?
In struct cap11xx_priv, the array is rigidly sized to 8 elements:
u32 calib_sensitivities[8];
u32 keycodes[];
During cap11xx_init_keys(), when parsing "microchip,calib-sensitivity", the
driver reads priv->model->num_channels elements:
of_property_read_u32_array(node, "microchip,calib-sensitivity",
priv->calib_sensitivities,
priv->model->num_channels)
With num_channels set to 14, won't this write 14 elements into an 8-element
array, clobbering the adjacent keycodes flexible array member and potentially
causing memory corruption or a kernel panic?
[Severity: Medium]
Will this configuration lead to integer truncation when parsing the
"microchip,signal-guard" property?
In struct cap11xx_priv, the mask is defined as an 8-bit value:
u8 signal_guard_inputs_mask;
During cap11xx_init_keys(), a loop iterates up to num_channels (14) and shifts
the bits:
priv->signal_guard_inputs_mask |= 0x01 << i;
For channels 8 to 13, won't this bitwise shift exceed the 8-bit variable width
and silently truncate to 0?
Even if the CAP1114 doesn't support signal guards, this drops the bitmask for
the upper channels, bypassing the capability check and failing to emit the
intended 'unsupported' warning.
> + .led_output_control_reg_base = CAP1114_REG_LED_OUTPUT_CONTROL1,
> + .sensor_input_reg_base = CAP1114_REG_BUTTON_STATUS1,
> + .has_grouped_sensors = true,
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612072237.1177304-1-jerrysteve1101@gmail.com?part=9
^ permalink raw reply
* Re: [PATCH v2 0/2] vsprintf: add upper case to %p[mM] et alia
From: Petr Mladek @ 2026-06-12 9:19 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jiri Kosina, Daniel J. Ogorchock, Tamir Duberstein, linux-doc,
linux-kernel, linux-input, Steven Rostedt, Rasmus Villemoes,
Sergey Senozhatsky, Jonathan Corbet, Shuah Khan,
Benjamin Tissoires, Andrew Morton
In-Reply-To: <20260603104351.152085-1-andriy.shevchenko@linux.intel.com>
On Wed 2026-06-03 12:34:01, Andy Shevchenko wrote:
> The first patch induced by Sashiko rightfully rises a concern on
> potential ABI breakage. To avoid that and allow the user (patch 2)
> to be converted to use unified output introduce %p[mM][...]U for
> printing in upper case. Tests are included and passed.
>
> Changelog v2:
> - added first patch (Sashiko)
>
> Andy Shevchenko (2):
> vsprintf: Add upper case flavour to %p[mM]
> HID: nintendo: Use %pM format specifier for MAC addresses
For the whole series:
Reviewed-by: Petr Mladek <pmladek@suse.com>
I am going to queue it via printk tree.
Best Regards,
Petr
PS: I am sorry for "late" review. My queue is quite long
at the moment...
^ permalink raw reply
* [PATCH v5] HID: i2c-hid: Refactor _DSM helper and add i2c-hid-acpi-prp0001 driver
From: 谢致邦 (XIE Zhibang) @ 2026-06-12 10:38 UTC (permalink / raw)
To: linux-input, hansg, dmitry.torokhov, bentiss, sashiko-bot
Cc: sashiko-reviews, 谢致邦 (XIE Zhibang),
Jiri Kosina, Mario Limonciello (AMD), Douglas Anderson,
linux-kernel
In-Reply-To: <20260609110608.3F4C21F00898@smtp.kernel.org>
Move the _DSM call that gets the HID descriptor address from
i2c-hid-acpi.c into i2c-hid-acpi.h as a static inline so both the ACPI
and the new PRP0001 driver can use it. While refactoring, move the
blacklist check and the _DSM call to the top of probe() to avoid a
pointless alloc when the device is blacklisted or does not implement the
_DSM.
Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3,
are declared with _HID "PRP0001" and _DSD compatible "hid-over-i2c" but
lack "hid-descr-addr" from the _DSD and provide the HID descriptor
address only through an ACPI _DSM. The OF driver fails to probe them
because it requires hid-descr-addr. Add a new driver that handles these
devices by calling the shared _DSM helper.
Fixes: b33752c30023 ("HID: i2c-hid: Reorganize so ACPI and OF are separate modules")
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
---
v2: Name the unused parameter and document why
acpi_device_fix_up_power() is skipped.
v3: Add a dev_warn() asking users to contact vendors for firmware
updates, and use existing locals in devm_kzalloc() and
acpi_device_fix_up_power().
v4: Double the power-up delay from 250ms to 500ms.
v5: Document why of_match_ptr() on the of_match_table is safe when
CONFIG_OF=n.
drivers/hid/i2c-hid/Kconfig | 18 ++++
drivers/hid/i2c-hid/Makefile | 1 +
drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c | 104 +++++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid-acpi.c | 52 +++--------
drivers/hid/i2c-hid/i2c-hid-acpi.h | 32 +++++++
5 files changed, 169 insertions(+), 38 deletions(-)
create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi.h
diff --git a/drivers/hid/i2c-hid/Kconfig b/drivers/hid/i2c-hid/Kconfig
index e8d51f410cc1..7db8b2abff78 100644
--- a/drivers/hid/i2c-hid/Kconfig
+++ b/drivers/hid/i2c-hid/Kconfig
@@ -22,6 +22,24 @@ config I2C_HID_ACPI
will be called i2c-hid-acpi. It will also build/depend on the
module i2c-hid.
+config I2C_HID_ACPI_PRP0001
+ tristate "Driver for PRP0001 devices missing hid-descr-addr"
+ depends on ACPI
+ depends on DRM || !DRM
+ select I2C_HID_CORE
+ help
+ Say Y here if you want support for I2C HID touchpads that
+ are declared with _HID "PRP0001" and _DSD compatible
+ "hid-over-i2c" but lack the "hid-descr-addr" property from
+ the _DSD. The HID descriptor address is instead provided
+ through an ACPI _DSM. Known affected devices include the
+ Lenovo KaiTian N60d and Inspur CP300L3.
+
+ If unsure, say N.
+
+ This support is also available as a module. If so, the
+ module will be called i2c-hid-acpi-prp0001.
+
config I2C_HID_OF
tristate "HID over I2C transport layer Open Firmware driver"
# No "depends on OF" because this can also be used for manually
diff --git a/drivers/hid/i2c-hid/Makefile b/drivers/hid/i2c-hid/Makefile
index 55bd5e0f35af..da420c1a8ec6 100644
--- a/drivers/hid/i2c-hid/Makefile
+++ b/drivers/hid/i2c-hid/Makefile
@@ -9,6 +9,7 @@ i2c-hid-objs = i2c-hid-core.o
i2c-hid-$(CONFIG_DMI) += i2c-hid-dmi-quirks.o
obj-$(CONFIG_I2C_HID_ACPI) += i2c-hid-acpi.o
+obj-$(CONFIG_I2C_HID_ACPI_PRP0001) += i2c-hid-acpi-prp0001.o
obj-$(CONFIG_I2C_HID_OF) += i2c-hid-of.o
obj-$(CONFIG_I2C_HID_OF_ELAN) += i2c-hid-of-elan.o
obj-$(CONFIG_I2C_HID_OF_GOODIX) += i2c-hid-of-goodix.o
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c b/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
new file mode 100644
index 000000000000..05469d220c39
--- /dev/null
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi-prp0001.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * HID over I2C driver for PRP0001 devices missing hid-descr-addr
+ *
+ * Some devices, for example the Lenovo KaiTian N60d and Inspur CP300L3, use
+ * _HID "PRP0001" with _DSD compatible "hid-over-i2c" but lack "hid-descr-addr"
+ * from the _DSD. The HID descriptor address is provided only through an ACPI
+ * _DSM. The TPD0 node in the DSDT shows _DSM Function 1 returning 0x20.
+ *
+ * Copyright (C) 2026 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+
+#include "i2c-hid.h"
+#include "i2c-hid-acpi.h"
+
+static int i2c_hid_acpi_prp0001_power_up(struct i2chid_ops *ops)
+{
+ /* give the device time to power up */
+ msleep(500);
+ return 0;
+}
+
+static struct i2chid_ops i2c_hid_acpi_prp0001_ops = {
+ .power_up = i2c_hid_acpi_prp0001_power_up,
+ /*
+ * No .restore_sequence needed: the _DSM on these devices returns a
+ * constant (0x20) with no side effects, unlike some PNP0C50 _DSM
+ * implementations that switch the hardware between PS/2 and I2C modes.
+ */
+};
+
+static int i2c_hid_acpi_prp0001_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct acpi_device *adev;
+ u16 hid_descriptor_address;
+ int ret;
+
+ /* If hid-descr-addr is present, let i2c-hid-of handle it */
+ if (device_property_present(dev, "hid-descr-addr"))
+ return -ENODEV;
+
+ adev = ACPI_COMPANION(dev);
+ if (!adev)
+ return -ENODEV;
+
+ ret = i2c_hid_acpi_get_descriptor(adev);
+ if (ret < 0)
+ return ret;
+ dev_warn(dev,
+ "hid-descr-addr device property NOT found, using ACPI _DSM fallback. Contact vendor for firmware update!\n");
+ hid_descriptor_address = ret;
+
+ /*
+ * No acpi_device_fix_up_power() needed: TPD0 has no _PS0, _PS3, _PSC
+ * or _PRx methods and follows I2C bus power.
+ */
+ return i2c_hid_core_probe(client, &i2c_hid_acpi_prp0001_ops,
+ hid_descriptor_address, 0);
+}
+
+static const struct of_device_id i2c_hid_acpi_prp0001_of_match[] = {
+ { .compatible = "hid-over-i2c" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, i2c_hid_acpi_prp0001_of_match);
+
+static const struct i2c_device_id i2c_hid_acpi_prp0001_id[] = {
+ { .name = "hid-over-i2c" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, i2c_hid_acpi_prp0001_id);
+
+static struct i2c_driver i2c_hid_acpi_prp0001_driver = {
+ .driver = {
+ .name = "i2c_hid_acpi_prp0001",
+ .pm = &i2c_hid_core_pm,
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ /*
+ * of_match_ptr() makes this NULL when CONFIG_OF=n, but that's
+ * fine: the I2C id_table with "hid-over-i2c" handles matching
+ * via client->name (set by acpi_set_modalias() from the _DSD
+ * compatible property).
+ */
+ .of_match_table = of_match_ptr(i2c_hid_acpi_prp0001_of_match),
+ },
+
+ .probe = i2c_hid_acpi_prp0001_probe,
+ .remove = i2c_hid_core_remove,
+ .shutdown = i2c_hid_core_shutdown,
+ .id_table = i2c_hid_acpi_prp0001_id,
+};
+
+module_i2c_driver(i2c_hid_acpi_prp0001_driver);
+
+MODULE_DESCRIPTION("HID over I2C driver for PRP0001 devices missing hid-descr-addr");
+MODULE_AUTHOR("谢致邦 (XIE Zhibang) <Yeking@Red54.com>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index abd700a101f4..13f977d6aab6 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -25,9 +25,9 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pm.h>
-#include <linux/uuid.h>
#include "i2c-hid.h"
+#include "i2c-hid-acpi.h"
struct i2c_hid_acpi {
struct i2chid_ops ops;
@@ -48,39 +48,11 @@ static const struct acpi_device_id i2c_hid_acpi_blacklist[] = {
{ }
};
-/* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
-static guid_t i2c_hid_guid =
- GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
- 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
-
-static int i2c_hid_acpi_get_descriptor(struct i2c_hid_acpi *ihid_acpi)
-{
- struct acpi_device *adev = ihid_acpi->adev;
- acpi_handle handle = acpi_device_handle(adev);
- union acpi_object *obj;
- u16 hid_descriptor_address;
-
- if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
- return -ENODEV;
-
- obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid, 1, 1, NULL,
- ACPI_TYPE_INTEGER);
- if (!obj) {
- acpi_handle_err(handle, "Error _DSM call to get HID descriptor address failed\n");
- return -ENODEV;
- }
-
- hid_descriptor_address = obj->integer.value;
- ACPI_FREE(obj);
-
- return hid_descriptor_address;
-}
-
static void i2c_hid_acpi_restore_sequence(struct i2chid_ops *ops)
{
struct i2c_hid_acpi *ihid_acpi = container_of(ops, struct i2c_hid_acpi, ops);
- i2c_hid_acpi_get_descriptor(ihid_acpi);
+ i2c_hid_acpi_get_descriptor(ihid_acpi->adev);
}
static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
@@ -93,24 +65,28 @@ static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
static int i2c_hid_acpi_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
+ struct acpi_device *adev = ACPI_COMPANION(dev);
struct i2c_hid_acpi *ihid_acpi;
u16 hid_descriptor_address;
int ret;
- ihid_acpi = devm_kzalloc(&client->dev, sizeof(*ihid_acpi), GFP_KERNEL);
+ if (acpi_match_device_ids(adev, i2c_hid_acpi_blacklist) == 0)
+ return -ENODEV;
+
+ ret = i2c_hid_acpi_get_descriptor(adev);
+ if (ret < 0)
+ return ret;
+ hid_descriptor_address = ret;
+
+ ihid_acpi = devm_kzalloc(dev, sizeof(*ihid_acpi), GFP_KERNEL);
if (!ihid_acpi)
return -ENOMEM;
- ihid_acpi->adev = ACPI_COMPANION(dev);
+ ihid_acpi->adev = adev;
ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
ihid_acpi->ops.restore_sequence = i2c_hid_acpi_restore_sequence;
- ret = i2c_hid_acpi_get_descriptor(ihid_acpi);
- if (ret < 0)
- return ret;
- hid_descriptor_address = ret;
-
- acpi_device_fix_up_power(ihid_acpi->adev);
+ acpi_device_fix_up_power(adev);
return i2c_hid_core_probe(client, &ihid_acpi->ops,
hid_descriptor_address, 0);
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.h b/drivers/hid/i2c-hid/i2c-hid-acpi.h
new file mode 100644
index 000000000000..8cebbeebcc23
--- /dev/null
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef _I2C_HID_ACPI_H
+#define _I2C_HID_ACPI_H
+
+#include <linux/acpi.h>
+#include <linux/uuid.h>
+
+static inline int i2c_hid_acpi_get_descriptor(struct acpi_device *adev)
+{
+ /* HID I²C Device: 3cdff6f7-4267-4555-ad05-b30a3d8938de */
+ static const guid_t i2c_hid_guid =
+ GUID_INIT(0x3CDFF6F7, 0x4267, 0x4555,
+ 0xAD, 0x05, 0xB3, 0x0A, 0x3D, 0x89, 0x38, 0xDE);
+
+ acpi_handle handle = acpi_device_handle(adev);
+ union acpi_object *obj;
+ u16 addr;
+
+ obj = acpi_evaluate_dsm_typed(handle, &i2c_hid_guid,
+ 1, 1, NULL, ACPI_TYPE_INTEGER);
+ if (!obj) {
+ acpi_handle_err(handle, "Error _DSM call to get HID descriptor address failed\n");
+ return -ENODEV;
+ }
+
+ addr = obj->integer.value;
+ ACPI_FREE(obj);
+ return addr;
+}
+
+#endif
--
2.52.0
^ permalink raw reply related
* [PATCH] HID: asus: add i2c entry for FA808UM and other TUFs
From: Denis Benato @ 2026-06-12 12:48 UTC (permalink / raw)
To: linux-kernel
Cc: linux-input, Benjamin Tissoires, Jiri Kosina, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Denis Benato
On newer TUF laptops the keyboard HID device uses the same PID/VID of a
USB device that was found in ROG laptops: add it to hid-asus as i2c too.
Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
drivers/hid/hid-asus.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index d34d74df3dc0..ef3a49847be2 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1500,6 +1500,9 @@ static const struct hid_device_id asus_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2),
QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_HID_FN_LOCK },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ASUSTEK,
+ USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2),
+ QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_HID_FN_LOCK },
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_ROG_Z13_LIGHTBAR),
QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] HID: asus: add i2c entry for FA808UM and other TUFs
From: sashiko-bot @ 2026-06-12 13:01 UTC (permalink / raw)
To: Denis Benato; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260612124830.984592-1-denis.benato@linux.dev>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Use-After-Free during device removal if asus_kbd_register_leds() fails
- [High] Invalid type cast and Out-of-Bounds read for non-USB devices mimicking QUIRK_ROG_ALLY_XPAD
--
commit 8b4f857c02ac46f316151cd7e8bd26fec4c17401
Author: Denis Benato <denis.benato@linux.dev>
HID: asus: add i2c entry for FA808UM and other TUFs
This patch adds an I2C HID device entry for the ASUS ROG NKEY Keyboard 2
in the hid-asus driver. This allows newer TUF laptops, which use the same
PID/VID over I2C instead of USB, to successfully bind to the driver.
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 3f5e96900b67a..5a2ab3cfef0b5 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -1494,6 +1494,9 @@ static const struct hid_device_id asus_devices[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2),
> QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_HID_FN_LOCK },
> + { HID_I2C_DEVICE(USB_VENDOR_ID_ASUSTEK,
> + USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2),
> + QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_HID_FN_LOCK },
[Severity: High]
This isn't a bug introduced by this patch, but while looking at the
QUIRK_USE_KBD_BACKLIGHT initialization, could there be a use-after-free
during device removal if asus_kbd_register_leds() fails?
If asus_hid_register_listener() fails within asus_kbd_register_leds() (e.g.,
due to missing asus-wmi or another keyboard already being registered), the
allocated drvdata->kbd_backlight is freed using devm_kfree():
ret = asus_hid_register_listener(&drvdata->kbd_backlight->listener);
if (ret < 0) {
/* No need to have this still around */
devm_kfree(&hdev->dev, drvdata->kbd_backlight);
}
However, the pointer itself is not set to NULL. Since this error is
intentionally ignored by the caller (asus_probe()), the device probe
succeeds.
When the device is later unbound or unplugged, asus_remove() checks
if (drvdata->kbd_backlight) and dereferences the dangling pointer to
unregister the listener:
static void asus_remove(struct hid_device *hdev)
{
...
if (drvdata->kbd_backlight) {
asus_hid_unregister_listener(&drvdata->kbd_backlight->listener);
Will this unconditionally dereference the dangling pointer, leading to a
use-after-free?
[Severity: High]
This is a pre-existing issue, but while looking at devices mimicking
QUIRK_ROG_ALLY_XPAD, could asus_kbd_register_leds() perform an invalid
type cast and out-of-bounds read?
In asus_kbd_register_leds(), devices with QUIRK_ROG_ALLY_XPAD unconditionally
cast the parent device to a usb_interface:
if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
intf = to_usb_interface(hdev->dev.parent);
udev = interface_to_usbdev(intf);
validate_mcu_fw_version(hdev,
le16_to_cpu(udev->descriptor.idProduct));
}
This assumes the device is always backed by a USB transport.
However, a local user can use uhid to inject a fake HID device with matching
USB vendor and product IDs, causing this driver to bind to it. For uhid
devices, the parent is the uhid character device, not a USB interface.
Would this blind cast lead to type confusion, memory corruption, and
out-of-bounds reads when attempting to access the USB device descriptor?
Should there be a hid_is_usb(hdev) check before treating the parent as a
USB interface?
> { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> USB_DEVICE_ID_ASUSTEK_ROG_Z13_LIGHTBAR),
> QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612124830.984592-1-denis.benato@linux.dev?part=1
^ permalink raw reply
* Re: [PATCH v2 0/2] vsprintf: add upper case to %p[mM] et alia
From: Petr Mladek @ 2026-06-12 13:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jiri Kosina, Daniel J. Ogorchock, Tamir Duberstein, linux-doc,
linux-kernel, linux-input, Steven Rostedt, Rasmus Villemoes,
Sergey Senozhatsky, Jonathan Corbet, Shuah Khan,
Benjamin Tissoires, Andrew Morton
In-Reply-To: <20260603104351.152085-1-andriy.shevchenko@linux.intel.com>
On Wed 2026-06-03 12:34:01, Andy Shevchenko wrote:
> The first patch induced by Sashiko rightfully rises a concern on
> potential ABI breakage. To avoid that and allow the user (patch 2)
> to be converted to use unified output introduce %p[mM][...]U for
> printing in upper case. Tests are included and passed.
>
> Changelog v2:
> - added first patch (Sashiko)
>
> Andy Shevchenko (2):
> vsprintf: Add upper case flavour to %p[mM]
> HID: nintendo: Use %pM format specifier for MAC addresses
JFYI, the patchset has been committed into printk/linux.git,
branch for-7.2-vsprintf-pmM-uppercase.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH] HID: asus: add support for xgm led
From: Denis Benato @ 2026-06-12 13:09 UTC (permalink / raw)
To: sashiko-reviews; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260611222102.2528F1F000E9@smtp.kernel.org>
On 6/12/26 00:21, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The `asus_xgm_led_set` function is incorrectly assigned to the non-blocking `brightness_set` LED callback, but it performs sleeping operations.
> - [Medium] The XGM LED class device name is hardcoded, which causes device probe failures due to sysfs naming collisions.
> --
>
> commit 55bc647f99f9d2c64c1e99f0ee43e81efa5a6298
> Author: Denis Benato <denis.benato@linux.dev>
>
> HID: asus: add support for xgm led
>
> XG mobile stations have very bright leds behind the fan that can be
> turned either ON or OFF: add a cled interface to allow controlling the
> brightness of those red leds.
>
>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>> index 3f5e96900b67a..8a5f364b7535f 100644
>> --- a/drivers/hid/hid-asus.c
>> +++ b/drivers/hid/hid-asus.c
> [ ... ]
>
>> @@ -1303,6 +1327,32 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>> }
>> }
>>
>> + if (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID) &&
>> + ((hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2022) ||
>> + (hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2023))) {
>> + drvdata->xgm_led = devm_kzalloc(&hdev->dev, sizeof(*drvdata->xgm_led), GFP_KERNEL);
>> + if (drvdata->xgm_led == NULL) {
>> + ret = -ENOMEM;
>> + goto err_stop_hw;
>> + }
>> + drvdata->xgm_led->hdev = hdev;
>> + drvdata->xgm_led->cdev.name = "asus:xgm:led";
> [Severity: Medium]
> If multiple XG Mobile docks are connected, or if an ungraceful disconnect
> leaves a stale sysfs entry behind, will this hardcoded name cause a sysfs
> naming collision? A duplicate name error here would cause
> led_classdev_register() to fail and abort the entire HID device probe.
ASUS has no models that can support two XGM devices: the connector
is a mixed usb-c+proprietary pci-e and no model has more than one:
there is no way one device can have more than one of these and I think
hardcoding the name is absolutely acceptable here.
> Should this use a dynamic identifier, perhaps incorporating dev_name(),
> to ensure uniqueness?
>
>> + drvdata->xgm_led->cdev.brightness = 1;
>> + drvdata->xgm_led->cdev.max_brightness = 1;
>> + drvdata->xgm_led->cdev.brightness_set = asus_xgm_led_set;
> [Severity: High]
> Can this cause a sleep-in-atomic bug if the LED is triggered by a software
> blink (such as a timer or heartbeat sysfs trigger)?
>
> When software blinking is used, the LED core invokes the brightness_set
> callback directly from softirq context. However, asus_xgm_led_set() calls
> asus_kbd_set_report(), which performs a GFP_KERNEL allocation and a blocking
> USB transaction via hid_hw_raw_request().
>
> Should this callback be assigned to brightness_set_blocking instead,
> so the LED core knows to defer the sleeping work to a workqueue?
Will test this and produce a v2 regardless of the outcome.
>> + ret = led_classdev_register(&hdev->dev, &drvdata->xgm_led->cdev);
>> + if (ret) {
>> + hid_err(hdev, "Asus failed to register xgm led: %d\n", ret);
>> + goto err_stop_hw;
>> + }
>> +
>> + /*
>> + * Sometimes after a reboot LEDs are ON, sometimes are OFF: set them to
>> + * what the default brightness resets when doing a cold boot.
>> + */
>> + asus_xgm_led_set(&drvdata->xgm_led->cdev, drvdata->xgm_led->cdev.brightness);
>> + }
>> +
^ permalink raw reply
* [PATCH v2 0/4] HID: asus: security fixes and more hardware support
From: Denis Benato @ 2026-06-12 14:23 UTC (permalink / raw)
To: linux-kernel
Cc: linux-input, Benjamin Tissoires, Jiri Kosina, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Denis Benato, Antheas Kapenekakis
Hi all,
I have added support for controlling the (way too bright) XG mobile
LEDs in hid-asus and added the i2c version of already supported
hardware that was probed only when it's a USB.
Auto-review bot has spotted two pre-existing possible security problems
alongside problems in my own code therefore I am producing a V2 including
those fixes and improvements.
Link: https://lore.kernel.org/all/20260612124830.984592-1-denis.benato@linux.dev/
Link: https://lore.kernel.org/all/30258f28-4036-4e99-9494-031212544dc2@linux.dev/
Best regards,
Denis Benato
Changelog:
- v1
- Initial submission (as separate patches)
- v2
- HID: asus: add i2c entry for FA808UM and other TUFs
- Joined to the patchset
- HID: asus: add support for xgm led
- Use the correct callback set_brightness_blocking
- Stop hardcoding the cled name
- HID: asus: prevent wrong pointer cast
- Added
- HID: asus: mitigate possible use-after-free
- Added
Denis Benato (4):
HID: asus: mitigate possible use-after-free
HID: asus: prevent wrong pointer cast
HID: asus: add support for xgm led
HID: asus: add i2c entry for FA808UM and other TUFs
drivers/hid/hid-asus.c | 76 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 75 insertions(+), 1 deletion(-)
--
2.47.3
^ permalink raw reply
* [PATCH v2 1/4] HID: asus: mitigate possible use-after-free
From: Denis Benato @ 2026-06-12 14:23 UTC (permalink / raw)
To: linux-kernel
Cc: linux-input, Benjamin Tissoires, Jiri Kosina, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Denis Benato, Antheas Kapenekakis,
sashiko-bot
In-Reply-To: <20260612142326.1704858-1-denis.benato@linux.dev>
The kbd_backlight pointer is not being set to NULL after being freed in
asus_kbd_register_leds and other portions of the driver checks that field,
therefore set the pointer to NULL after being freed.
Link: https://lore.kernel.org/all/20260612130125.AAAE71F000E9@smtp.kernel.org/
Suggested-by: sashiko-bot@kernel.org
Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
drivers/hid/hid-asus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index d34d74df3dc0..4d7110b892bd 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -777,6 +777,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
if (ret < 0) {
/* No need to have this still around */
devm_kfree(&hdev->dev, drvdata->kbd_backlight);
+ drvdata->kbd_backlight = NULL;
}
return ret;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 2/4] HID: asus: prevent wrong pointer cast
From: Denis Benato @ 2026-06-12 14:23 UTC (permalink / raw)
To: linux-kernel
Cc: linux-input, Benjamin Tissoires, Jiri Kosina, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Denis Benato, Antheas Kapenekakis,
sashiko-bot
In-Reply-To: <20260612142326.1704858-1-denis.benato@linux.dev>
The firmware version check for ROG ally devices assumes the parent device
is a USB device, therefore prevent possible out-of-bounds access by using
hid_is_usb() to mitigate possible out-of-bounds access.
Link: https://lore.kernel.org/all/20260612130125.AAAE71F000E9@smtp.kernel.org/
Fixes: 56d1b33e644c ("HID: asus: simplify RGB init sequence")
Suggested-by: sashiko-bot@kernel.org
Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
drivers/hid/hid-asus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 4d7110b892bd..323dc0b7f3ff 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -753,7 +753,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
return ret;
}
- if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
+ if (hid_is_usb(hdev) && (drvdata->quirks & QUIRK_ROG_ALLY_XPAD)) {
intf = to_usb_interface(hdev->dev.parent);
udev = interface_to_usbdev(intf);
validate_mcu_fw_version(hdev,
--
2.47.3
^ permalink raw reply related
* [PATCH v2 3/4] HID: asus: add support for xgm led
From: Denis Benato @ 2026-06-12 14:23 UTC (permalink / raw)
To: linux-kernel
Cc: linux-input, Benjamin Tissoires, Jiri Kosina, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Denis Benato, Antheas Kapenekakis
In-Reply-To: <20260612142326.1704858-1-denis.benato@linux.dev>
XG mobile stations have very bright leds behind the fan that can be
turned either ON or OFF: add a cled interface to allow controlling the
brightness of those red leds.
Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
drivers/hid/hid-asus.c | 70 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 323dc0b7f3ff..21c4a60d224e 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -51,6 +51,8 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
#define FEATURE_KBD_LED_REPORT_ID1 0x5d
#define FEATURE_KBD_LED_REPORT_ID2 0x5e
+#define ROG_XGM_REPORT_SIZE 300
+
#define ROG_ALLY_REPORT_SIZE 64
#define ROG_ALLY_X_MIN_MCU 313
#define ROG_ALLY_MIN_MCU 319
@@ -118,6 +120,11 @@ struct asus_kbd_leds {
bool removed;
};
+struct asus_xgm_led {
+ struct led_classdev cdev;
+ struct hid_device *hdev;
+};
+
struct asus_touchpad_info {
int max_x;
int max_y;
@@ -143,6 +150,7 @@ struct asus_drvdata {
unsigned long battery_next_query;
struct work_struct fn_lock_sync_work;
bool fn_lock;
+ struct asus_xgm_led *xgm_led;
};
static int asus_report_battery(struct asus_drvdata *, u8 *, int);
@@ -941,6 +949,23 @@ static int asus_battery_probe(struct hid_device *hdev)
return ret;
}
+static int asus_xgm_led_set(struct led_classdev *led_cdev, enum led_brightness value)
+{
+ const u8 buf[ROG_XGM_REPORT_SIZE] = {
+ FEATURE_KBD_LED_REPORT_ID2, 0xC5, (value) ? 0x50 : 0x00
+ };
+ struct asus_xgm_led *xgm = container_of(led_cdev, struct asus_xgm_led, cdev);
+ int ret;
+
+ ret = asus_kbd_set_report(xgm->hdev, buf, ROG_XGM_REPORT_SIZE);
+ if (ret != ROG_XGM_REPORT_SIZE) {
+ hid_err(xgm->hdev, "Unable to set XG mobile led state: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
static int asus_input_configured(struct hid_device *hdev, struct hid_input *hi)
{
struct input_dev *input = hi->input;
@@ -1184,6 +1209,14 @@ static int __maybe_unused asus_resume(struct hid_device *hdev)
}
}
+ if (drvdata->xgm_led) {
+ ret = asus_xgm_led_set(&drvdata->xgm_led->cdev, drvdata->xgm_led->cdev.brightness);
+ if (ret) {
+ hid_err(hdev, "Asus failed to restore xgm brightness: %d\n", ret);
+ goto asus_resume_err;
+ }
+ }
+
asus_resume_err:
return ret;
}
@@ -1310,6 +1343,40 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
}
}
+ if (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID) &&
+ ((hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2022) ||
+ (hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2023))) {
+ drvdata->xgm_led = devm_kzalloc(&hdev->dev, sizeof(*drvdata->xgm_led), GFP_KERNEL);
+ if (drvdata->xgm_led == NULL) {
+ ret = -ENOMEM;
+ goto err_stop_hw;
+ }
+ drvdata->xgm_led->hdev = hdev;
+ drvdata->xgm_led->cdev.name = devm_kasprintf(&hdev->dev, GFP_KERNEL,
+ "asus:xgm-%s:led",
+ strlen(hdev->uniq) ?
+ hdev->uniq : dev_name(&hdev->dev));
+ drvdata->xgm_led->cdev.brightness = 1;
+ drvdata->xgm_led->cdev.max_brightness = 1;
+ drvdata->xgm_led->cdev.brightness_set_blocking = asus_xgm_led_set;
+
+ /*
+ * Sometimes after a reboot LEDs are ON, sometimes are OFF: set them to
+ * what the default brightness resets when doing a cold boot.
+ */
+ ret = asus_xgm_led_set(&drvdata->xgm_led->cdev, drvdata->xgm_led->cdev.brightness);
+ if (ret) {
+ hid_err(hdev, "Asus failed to set xgm led: %d\n", ret);
+ goto err_stop_hw;
+ }
+
+ ret = led_classdev_register(&hdev->dev, &drvdata->xgm_led->cdev);
+ if (ret) {
+ hid_err(hdev, "Asus failed to register xgm led: %d\n", ret);
+ goto err_stop_hw;
+ }
+ }
+
/* Laptops keyboard backlight is always at 0x5a */
if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
(asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID)) &&
@@ -1366,6 +1433,9 @@ static void asus_remove(struct hid_device *hdev)
if (drvdata->quirks & QUIRK_HID_FN_LOCK)
cancel_work_sync(&drvdata->fn_lock_sync_work);
+ if (drvdata->xgm_led)
+ led_classdev_unregister(&drvdata->xgm_led->cdev);
+
hid_hw_stop(hdev);
}
--
2.47.3
^ permalink raw reply related
* [PATCH v2 4/4] HID: asus: add i2c entry for FA808UM and other TUFs
From: Denis Benato @ 2026-06-12 14:23 UTC (permalink / raw)
To: linux-kernel
Cc: linux-input, Benjamin Tissoires, Jiri Kosina, Luke D . Jones,
Mateusz Schyboll, Denis Benato, Denis Benato, Antheas Kapenekakis
In-Reply-To: <20260612142326.1704858-1-denis.benato@linux.dev>
On newer TUF laptops the keyboard HID device uses the same PID/VID of a
USB device that was found in ROG laptops: add it to hid-asus as i2c too.
Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
drivers/hid/hid-asus.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 21c4a60d224e..b24222fdb319 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -1571,6 +1571,9 @@ static const struct hid_device_id asus_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2),
QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_HID_FN_LOCK },
+ { HID_I2C_DEVICE(USB_VENDOR_ID_ASUSTEK,
+ USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2),
+ QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_HID_FN_LOCK },
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
USB_DEVICE_ID_ASUSTEK_ROG_Z13_LIGHTBAR),
QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 4/4] HID: asus: add i2c entry for FA808UM and other TUFs
From: sashiko-bot @ 2026-06-12 14:37 UTC (permalink / raw)
To: Denis Benato; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260612142326.1704858-5-denis.benato@linux.dev>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Improper Workqueue Initialization / Memory Corruption via Re-initialization
- [High] Use-After-Free due to Race Condition in `asus_remove()`
- [High] Missing NULL check for `devm_kasprintf` allocation leading to Kernel Oops
--
commit ee67627a03893a0ccf0a7653ac62191a687b7821
Author: Denis Benato <denis.benato@linux.dev>
HID: asus: add i2c entry for FA808UM and other TUFs
On newer TUF laptops the keyboard HID device uses the same PID/VID of a
USB device that was found in ROG laptops: add it to hid-asus as i2c too.
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 0f78242b6a1db..7964fc96196e5 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -1565,6 +1565,9 @@ static const struct hid_device_id asus_devices[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2),
> QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_HID_FN_LOCK },
> + { HID_I2C_DEVICE(USB_VENDOR_ID_ASUSTEK,
> + USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2),
> + QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_HID_FN_LOCK },
[Severity: Critical]
This is a pre-existing issue, but since this patch enables QUIRK_HID_FN_LOCK
for a new device, could the fn_lock_sync_work initialization cause workqueue
corruption?
In asus_input_configured(), INIT_WORK(&drvdata->fn_lock_sync_work, ...) is
called per-input. For devices with multiple inputs, if hid_hw_start() enables
interrupts before all inputs are configured, an early KEY_FN_ESC event could
schedule the work before the next input is configured.
The next call to asus_input_configured() would then re-execute INIT_WORK() on
the already queued work item, clearing its list pointers and causing a panic.
Additionally, for devices with 0 inputs, it is never initialized, causing a
warning in cancel_work_sync().
[Severity: High]
This is a pre-existing issue, but is there a potential use-after-free during
device removal when QUIRK_HID_FN_LOCK is enabled?
In asus_remove(), cancel_work_sync(&drvdata->fn_lock_sync_work) is called
before hid_hw_stop(hdev). Since the hardware is still active, a late
KEY_FN_ESC event can trigger asus_event() and unconditionally call
schedule_work() after the work was supposedly canceled.
Once the driver is removed and drvdata is freed by devres, could the
workqueue execute asus_sync_fn_lock() and dereference the freed drvdata?
[Severity: High]
This is a pre-existing issue, but does the XGM LED name allocation need a
NULL check?
In asus_probe(), devm_kasprintf() is used to allocate the name for
drvdata->xgm_led->cdev.name:
drvdata->xgm_led->cdev.name = devm_kasprintf(&hdev->dev, GFP_KERNEL,
"asus:xgm-%s:led",
strlen(hdev->uniq) ?
hdev->uniq : dev_name(&hdev->dev));
drvdata->xgm_led->cdev.brightness = 1;
If devm_kasprintf() fails under memory pressure, it returns NULL. This NULL
pointer is then passed to led_classdev_register(), which passes it to
led_classdev_next_name() and eventually to strscpy() as the source string.
Since strscpy() does not check for a NULL source, this would cause an
immediate NULL pointer dereference.
> { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> USB_DEVICE_ID_ASUSTEK_ROG_Z13_LIGHTBAR),
> QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612142326.1704858-1-denis.benato@linux.dev?part=4
^ permalink raw reply
* Re: [PATCH v2 3/4] HID: asus: add support for xgm led
From: sashiko-bot @ 2026-06-12 14:37 UTC (permalink / raw)
To: Denis Benato; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260612142326.1704858-4-denis.benato@linux.dev>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] Missing NULL check for devm_kasprintf() return value causes a kernel panic on allocation failure.
- [High] Missing led_classdev_unregister() in the asus_probe() error path creates a structural Use-After-Free risk.
- [Low] Incorrect error propagation in asus_xgm_led_set() when asus_kbd_set_report() returns a short byte count or 0.
Pre-existing issues:
- [High] Missing cleanup of kbd_backlight->listener and fn_lock_sync_work on asus_probe() error path causes Use-After-Free.
--
commit a9179e65e5727586c134f2af39cf55f67620125b
Author: Denis Benato <denis.benato@linux.dev>
Subject: HID: asus: add support for xgm led
This patch adds support for controlling the brightness of the red leds behind
the fan on XG mobile stations. It introduces a cled interface via the
led_classdev to turn them on or off.
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 52d755659d951..0f78242b6a1db 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
[ ... ]
> @@ -941,6 +949,23 @@ static int asus_battery_probe(struct hid_device *hdev)
> return ret;
> }
>
> +static int asus_xgm_led_set(struct led_classdev *led_cdev, enum led_brightness value)
> +{
> + const u8 buf[ROG_XGM_REPORT_SIZE] = {
> + FEATURE_KBD_LED_REPORT_ID2, 0xC5, (value) ? 0x50 : 0x00
> + };
> + struct asus_xgm_led *xgm = container_of(led_cdev, struct asus_xgm_led, cdev);
> + int ret;
> +
> + ret = asus_kbd_set_report(xgm->hdev, buf, ROG_XGM_REPORT_SIZE);
> + if (ret != ROG_XGM_REPORT_SIZE) {
> + hid_err(xgm->hdev, "Unable to set XG mobile led state: %d\n", ret);
> + return ret;
[Severity: Low]
Could this return a positive value or 0 on failure?
asus_kbd_set_report() returns the number of bytes transferred on success or a
negative error code on failure. If a partial transfer occurs or if it returns
0, this check will evaluate to true and return the non-negative value. The
caller might silently treat a 0 return value as success, bypassing error
handling expectations.
> + }
> +
> + return 0;
> +}
> +
[ ... ]
> @@ -1304,6 +1337,40 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> }
> }
>
> + if (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID) &&
> + ((hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2022) ||
> + (hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2023))) {
> + drvdata->xgm_led = devm_kzalloc(&hdev->dev, sizeof(*drvdata->xgm_led), GFP_KERNEL);
> + if (drvdata->xgm_led == NULL) {
> + ret = -ENOMEM;
> + goto err_stop_hw;
> + }
> + drvdata->xgm_led->hdev = hdev;
> + drvdata->xgm_led->cdev.name = devm_kasprintf(&hdev->dev, GFP_KERNEL,
> + "asus:xgm-%s:led",
> + strlen(hdev->uniq) ?
> + hdev->uniq : dev_name(&hdev->dev));
[Severity: High]
Does this code need to check if devm_kasprintf() returns null?
Under memory pressure, if this allocation fails, passing the null cdev.name to
led_classdev_register() will lead to a null pointer dereference in the led
subsystem when it uses strscpy() to copy the device name.
> + drvdata->xgm_led->cdev.brightness = 1;
> + drvdata->xgm_led->cdev.max_brightness = 1;
> + drvdata->xgm_led->cdev.brightness_set_blocking = asus_xgm_led_set;
> +
> + /*
> + * Sometimes after a reboot LEDs are ON, sometimes are OFF: set them to
> + * what the default brightness resets when doing a cold boot.
> + */
> + ret = asus_xgm_led_set(&drvdata->xgm_led->cdev, drvdata->xgm_led->cdev.brightness);
> + if (ret) {
> + hid_err(hdev, "Asus failed to set xgm led: %d\n", ret);
> + goto err_stop_hw;
> + }
> +
> + ret = led_classdev_register(&hdev->dev, &drvdata->xgm_led->cdev);
> + if (ret) {
> + hid_err(hdev, "Asus failed to register xgm led: %d\n", ret);
> + goto err_stop_hw;
[Severity: High]
If asus_probe() fails later in the probe process and jumps to err_stop_hw,
does the error path miss unregistering the led device?
Because the xgm_led structure is allocated with devm_kzalloc(), it will be
automatically freed when the probe fails. If led_classdev_unregister() isn't
called on the err_stop_hw path, the led subsystem may retain active references
to the freed cdev, potentially causing a use-after-free when sysfs led
attributes are accessed.
[Severity: High]
This isn't a bug introduced by this patch, but looking at the error path for
asus_probe() when jumping to err_stop_hw:
err_stop_hw:
hid_hw_stop(hdev);
return ret;
It seems we miss cleaning up kbd_backlight->listener and fn_lock_sync_work
if the probe fails downstream. Once devres cleans up drvdata, the listener
remains in the global list in asus-wmi, which might lead to a use-after-free
if a WMI event triggers the listener and accesses the freed memory.
> + }
> + }
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612142326.1704858-1-denis.benato@linux.dev?part=3
^ permalink raw reply
* Re: [PATCH v2 2/4] HID: asus: prevent wrong pointer cast
From: sashiko-bot @ 2026-06-12 14:38 UTC (permalink / raw)
To: Denis Benato; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260612142326.1704858-3-denis.benato@linux.dev>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing cleanup in asus_probe error path leads to Use-After-Free.
- [High] Calling ACPI method evaluation from HID raw_event handler leads to sleeping in atomic context.
--
commit 3fe25fc3ce0bf42eb96551214cb9606ee3c5ff97
Author: Denis Benato <denis.benato@linux.dev>
HID: asus: prevent wrong pointer cast
The firmware version check for ROG ally devices assumes the parent device
is a USB device, therefore prevent possible out-of-bounds access by using
hid_is_usb() to mitigate possible out-of-bounds access.
Link: https://lore.kernel.org/all/20260612130125.AAAE71F000E9@smtp.kernel.org/
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -753,7 +753,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> return ret;
> }
>
> - if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> + if (hid_is_usb(hdev) && (drvdata->quirks & QUIRK_ROG_ALLY_XPAD)) {
> intf = to_usb_interface(hdev->dev.parent);
> udev = interface_to_usbdev(intf);
> validate_mcu_fw_version(hdev,
[Severity: High]
This isn't a bug introduced by this patch, but while looking at
asus_kbd_register_leds(), I noticed it registers a listener to a global list
and uses devm_kzalloc(). If a subsequent initialization step in asus_probe()
fails:
drivers/hid/hid-asus.c:asus_probe() {
...
ret = asus_start_multitouch(hdev);
if (ret)
goto err_stop_hw;
...
err_stop_hw:
hid_hw_stop(hdev);
return ret;
}
Can this lead to a use-after-free on the listener?
The driver returns without unregistering the listener, and the devres
subsystem will automatically free the memory, leaving a dangling pointer
in the global list.
[Severity: High]
This is a pre-existing issue, but I also noticed that asus_raw_event() can
synchronously trigger an ACPI method evaluation:
drivers/hid/hid-asus.c:asus_raw_event() {
...
int ret = asus_wmi_send_event(drvdata, ASUS_FAN_CTRL_KEY_CODE);
...
}
drivers/hid/hid-asus.c:asus_wmi_send_event() {
...
err = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DEVS,
ASUS_WMI_METHODID_NOTIF, code, &retval);
...
}
For USB HID devices, asus_raw_event() is invoked from the URB completion
handler in atomic context.
Since wmi_evaluate_method() acquires mutexes and may sleep, will this cause
the kernel to sleep in atomic context?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612142326.1704858-1-denis.benato@linux.dev?part=2
^ permalink raw reply
* Re: [PATCH v2 3/4] HID: asus: add support for xgm led
From: Antheas Kapenekakis @ 2026-06-12 14:39 UTC (permalink / raw)
To: Denis Benato
Cc: linux-kernel, linux-input, Benjamin Tissoires, Jiri Kosina,
Luke D . Jones, Mateusz Schyboll, Denis Benato
In-Reply-To: <20260612142326.1704858-4-denis.benato@linux.dev>
On Fri, 12 Jun 2026 at 16:23, Denis Benato <denis.benato@linux.dev> wrote:
>
> XG mobile stations have very bright leds behind the fan that can be
> turned either ON or OFF: add a cled interface to allow controlling the
> brightness of those red leds.
>
> Signed-off-by: Denis Benato <denis.benato@linux.dev>
> ---
> drivers/hid/hid-asus.c | 70 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 323dc0b7f3ff..21c4a60d224e 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -51,6 +51,8 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> #define FEATURE_KBD_LED_REPORT_ID1 0x5d
> #define FEATURE_KBD_LED_REPORT_ID2 0x5e
>
> +#define ROG_XGM_REPORT_SIZE 300
> +
> #define ROG_ALLY_REPORT_SIZE 64
> #define ROG_ALLY_X_MIN_MCU 313
> #define ROG_ALLY_MIN_MCU 319
> @@ -118,6 +120,11 @@ struct asus_kbd_leds {
> bool removed;
> };
>
> +struct asus_xgm_led {
> + struct led_classdev cdev;
> + struct hid_device *hdev;
> +};
> +
> struct asus_touchpad_info {
> int max_x;
> int max_y;
> @@ -143,6 +150,7 @@ struct asus_drvdata {
> unsigned long battery_next_query;
> struct work_struct fn_lock_sync_work;
> bool fn_lock;
> + struct asus_xgm_led *xgm_led;
> };
>
> static int asus_report_battery(struct asus_drvdata *, u8 *, int);
> @@ -941,6 +949,23 @@ static int asus_battery_probe(struct hid_device *hdev)
> return ret;
> }
>
> +static int asus_xgm_led_set(struct led_classdev *led_cdev, enum led_brightness value)
> +{
> + const u8 buf[ROG_XGM_REPORT_SIZE] = {
> + FEATURE_KBD_LED_REPORT_ID2, 0xC5, (value) ? 0x50 : 0x00
> + };
> + struct asus_xgm_led *xgm = container_of(led_cdev, struct asus_xgm_led, cdev);
> + int ret;
> +
> + ret = asus_kbd_set_report(xgm->hdev, buf, ROG_XGM_REPORT_SIZE);
> + if (ret != ROG_XGM_REPORT_SIZE) {
> + hid_err(xgm->hdev, "Unable to set XG mobile led state: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int asus_input_configured(struct hid_device *hdev, struct hid_input *hi)
> {
> struct input_dev *input = hi->input;
> @@ -1184,6 +1209,14 @@ static int __maybe_unused asus_resume(struct hid_device *hdev)
> }
> }
>
> + if (drvdata->xgm_led) {
> + ret = asus_xgm_led_set(&drvdata->xgm_led->cdev, drvdata->xgm_led->cdev.brightness);
> + if (ret) {
> + hid_err(hdev, "Asus failed to restore xgm brightness: %d\n", ret);
> + goto asus_resume_err;
> + }
> + }
> +
> asus_resume_err:
> return ret;
> }
> @@ -1310,6 +1343,40 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
> }
> }
>
> + if (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID) &&
> + ((hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2022) ||
> + (hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2023))) {
> + drvdata->xgm_led = devm_kzalloc(&hdev->dev, sizeof(*drvdata->xgm_led), GFP_KERNEL);
> + if (drvdata->xgm_led == NULL) {
> + ret = -ENOMEM;
> + goto err_stop_hw;
> + }
> + drvdata->xgm_led->hdev = hdev;
> + drvdata->xgm_led->cdev.name = devm_kasprintf(&hdev->dev, GFP_KERNEL,
> + "asus:xgm-%s:led",
> + strlen(hdev->uniq) ?
> + hdev->uniq : dev_name(&hdev->dev));
> + drvdata->xgm_led->cdev.brightness = 1;
> + drvdata->xgm_led->cdev.max_brightness = 1;
> + drvdata->xgm_led->cdev.brightness_set_blocking = asus_xgm_led_set;
> +
> + /*
> + * Sometimes after a reboot LEDs are ON, sometimes are OFF: set them to
> + * what the default brightness resets when doing a cold boot.
> + */
I think this is set by the driver, so you should reformat the comment
above, so you should trim the comment.
Perhaps, "The LED state is arbitrary on boot, therefore default to the
initial brightness set above". This way it does not become outdated if
cdev.brightness changes.
> + ret = asus_xgm_led_set(&drvdata->xgm_led->cdev, drvdata->xgm_led->cdev.brightness);
> + if (ret) {
> + hid_err(hdev, "Asus failed to set xgm led: %d\n", ret);
> + goto err_stop_hw;
> + }
You already do this in asus_input_configured so you do it twice?
Perhaps skip one if you end up keeping them? I think that it's better
to keep this block.
Or even better return an error in _get so that on boot it is
ambiguous? I assume the leds remain to the state they had prior to the
reboot? With this change, imagine a user that turned off the leds in
windows, permabooted into Linux, and now has the lights always turn on
during boot.
Moreover, can systemd restore this or is it out of scope for its led
handler? Perhaps it is an ambitious idea though, and better skipped.
> +
> + ret = led_classdev_register(&hdev->dev, &drvdata->xgm_led->cdev);
> + if (ret) {
> + hid_err(hdev, "Asus failed to register xgm led: %d\n", ret);
> + goto err_stop_hw;
> + }
> + }
> +
> /* Laptops keyboard backlight is always at 0x5a */
> if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
> (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID)) &&
> @@ -1366,6 +1433,9 @@ static void asus_remove(struct hid_device *hdev)
> if (drvdata->quirks & QUIRK_HID_FN_LOCK)
> cancel_work_sync(&drvdata->fn_lock_sync_work);
>
> + if (drvdata->xgm_led)
> + led_classdev_unregister(&drvdata->xgm_led->cdev);
> +
> hid_hw_stop(hdev);
> }
>
> --
> 2.47.3
>
>
^ permalink raw reply
* Re: [PATCH v2 1/4] HID: asus: mitigate possible use-after-free
From: Antheas Kapenekakis @ 2026-06-12 14:44 UTC (permalink / raw)
To: Denis Benato
Cc: linux-kernel, linux-input, Benjamin Tissoires, Jiri Kosina,
Luke D . Jones, Mateusz Schyboll, Denis Benato, sashiko-bot
In-Reply-To: <20260612142326.1704858-2-denis.benato@linux.dev>
On Fri, 12 Jun 2026 at 16:23, Denis Benato <denis.benato@linux.dev> wrote:
>
> The kbd_backlight pointer is not being set to NULL after being freed in
> asus_kbd_register_leds and other portions of the driver checks that field,
> therefore set the pointer to NULL after being freed.
>
> Link: https://lore.kernel.org/all/20260612130125.AAAE71F000E9@smtp.kernel.org/
>
> Suggested-by: sashiko-bot@kernel.org
Good catch. I verified devm_kfree does not mutate the pointer. I
recall this being there before from the comment.
Reviewed-by: Antheas Kapenekakis <lkml@antheas.dev>
> Signed-off-by: Denis Benato <denis.benato@linux.dev>
> ---
> drivers/hid/hid-asus.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index d34d74df3dc0..4d7110b892bd 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -777,6 +777,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> if (ret < 0) {
> /* No need to have this still around */
> devm_kfree(&hdev->dev, drvdata->kbd_backlight);
> + drvdata->kbd_backlight = NULL;
> }
>
> return ret;
> --
> 2.47.3
>
>
^ permalink raw reply
* Re: [PATCH v2 2/4] HID: asus: prevent wrong pointer cast
From: Antheas Kapenekakis @ 2026-06-12 14:48 UTC (permalink / raw)
To: Denis Benato
Cc: linux-kernel, linux-input, Benjamin Tissoires, Jiri Kosina,
Luke D . Jones, Mateusz Schyboll, Denis Benato, sashiko-bot
In-Reply-To: <20260612142326.1704858-3-denis.benato@linux.dev>
On Fri, 12 Jun 2026 at 16:23, Denis Benato <denis.benato@linux.dev> wrote:
>
> The firmware version check for ROG ally devices assumes the parent device
> is a USB device, therefore prevent possible out-of-bounds access by using
> hid_is_usb() to mitigate possible out-of-bounds access.
>
> Link: https://lore.kernel.org/all/20260612130125.AAAE71F000E9@smtp.kernel.org/
>
> Fixes: 56d1b33e644c ("HID: asus: simplify RGB init sequence")
Proper fixes is:
Fixes: 00e005c952f7 ("hid-asus: check ROG Ally MCU version and warn")
56d1b33e644c just moved the block.
> Suggested-by: sashiko-bot@kernel.org
> Signed-off-by: Denis Benato <denis.benato@linux.dev>
> ---
> drivers/hid/hid-asus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> index 4d7110b892bd..323dc0b7f3ff 100644
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> @@ -753,7 +753,7 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> return ret;
> }
>
> - if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
> + if (hid_is_usb(hdev) && (drvdata->quirks & QUIRK_ROG_ALLY_XPAD)) {
> intf = to_usb_interface(hdev->dev.parent);
> udev = interface_to_usbdev(intf);
> validate_mcu_fw_version(hdev,
> --
> 2.47.3
>
>
^ permalink raw reply
* [PATCH] HID: hidpp: fix potential UAF in hidpp_connect_event()
From: Jiri Kosina @ 2026-06-12 15:48 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-kernel, linux-input
From: Jiri Kosina <jkosina@suse.com>
If input_register_device() fails, we call input_free_device(), but keep
stale pointer to the old device in hidpp->input, which could potentially
lead to UAF. Fix that by resetting it to NULL before returning from
hidpp_connect_event().
Reported-by: zdi-disclosures@trendmicro.com
Signed-off-by: Jiri Kosina <jkosina@suse.com>
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 1990ba5b26ea..e0dfb7051966 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4295,6 +4295,7 @@ static void hidpp_connect_event(struct work_struct *work)
ret = input_register_device(input);
if (ret) {
input_free_device(input);
+ hidpp->input = NULL;
return;
}
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: [PATCH v2 3/4] HID: asus: add support for xgm led
From: Denis Benato @ 2026-06-12 15:56 UTC (permalink / raw)
To: Antheas Kapenekakis, Denis Benato
Cc: linux-kernel, linux-input, Benjamin Tissoires, Jiri Kosina,
Luke D . Jones, Mateusz Schyboll
In-Reply-To: <CAGwozwHCAC1AkAjo4BqyjdS+GQqDWaMgmmtgAi14VzBc9NM3gQ@mail.gmail.com>
On 6/12/26 16:39, Antheas Kapenekakis wrote:
> On Fri, 12 Jun 2026 at 16:23, Denis Benato <denis.benato@linux.dev> wrote:
>> XG mobile stations have very bright leds behind the fan that can be
>> turned either ON or OFF: add a cled interface to allow controlling the
>> brightness of those red leds.
>>
>> Signed-off-by: Denis Benato <denis.benato@linux.dev>
>> ---
>> drivers/hid/hid-asus.c | 70 ++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 70 insertions(+)
>>
>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>> index 323dc0b7f3ff..21c4a60d224e 100644
>> --- a/drivers/hid/hid-asus.c
>> +++ b/drivers/hid/hid-asus.c
>> @@ -51,6 +51,8 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
>> #define FEATURE_KBD_LED_REPORT_ID1 0x5d
>> #define FEATURE_KBD_LED_REPORT_ID2 0x5e
>>
>> +#define ROG_XGM_REPORT_SIZE 300
>> +
>> #define ROG_ALLY_REPORT_SIZE 64
>> #define ROG_ALLY_X_MIN_MCU 313
>> #define ROG_ALLY_MIN_MCU 319
>> @@ -118,6 +120,11 @@ struct asus_kbd_leds {
>> bool removed;
>> };
>>
>> +struct asus_xgm_led {
>> + struct led_classdev cdev;
>> + struct hid_device *hdev;
>> +};
>> +
>> struct asus_touchpad_info {
>> int max_x;
>> int max_y;
>> @@ -143,6 +150,7 @@ struct asus_drvdata {
>> unsigned long battery_next_query;
>> struct work_struct fn_lock_sync_work;
>> bool fn_lock;
>> + struct asus_xgm_led *xgm_led;
>> };
>>
>> static int asus_report_battery(struct asus_drvdata *, u8 *, int);
>> @@ -941,6 +949,23 @@ static int asus_battery_probe(struct hid_device *hdev)
>> return ret;
>> }
>>
>> +static int asus_xgm_led_set(struct led_classdev *led_cdev, enum led_brightness value)
>> +{
>> + const u8 buf[ROG_XGM_REPORT_SIZE] = {
>> + FEATURE_KBD_LED_REPORT_ID2, 0xC5, (value) ? 0x50 : 0x00
>> + };
>> + struct asus_xgm_led *xgm = container_of(led_cdev, struct asus_xgm_led, cdev);
>> + int ret;
>> +
>> + ret = asus_kbd_set_report(xgm->hdev, buf, ROG_XGM_REPORT_SIZE);
>> + if (ret != ROG_XGM_REPORT_SIZE) {
>> + hid_err(xgm->hdev, "Unable to set XG mobile led state: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static int asus_input_configured(struct hid_device *hdev, struct hid_input *hi)
>> {
>> struct input_dev *input = hi->input;
>> @@ -1184,6 +1209,14 @@ static int __maybe_unused asus_resume(struct hid_device *hdev)
>> }
>> }
>>
>> + if (drvdata->xgm_led) {
>> + ret = asus_xgm_led_set(&drvdata->xgm_led->cdev, drvdata->xgm_led->cdev.brightness);
>> + if (ret) {
>> + hid_err(hdev, "Asus failed to restore xgm brightness: %d\n", ret);
>> + goto asus_resume_err;
>> + }
>> + }
>> +
>> asus_resume_err:
>> return ret;
>> }
>> @@ -1310,6 +1343,40 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>> }
>> }
>>
>> + if (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID) &&
>> + ((hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2022) ||
>> + (hdev->product == USB_DEVICE_ID_ASUSTEK_XGM_2023))) {
>> + drvdata->xgm_led = devm_kzalloc(&hdev->dev, sizeof(*drvdata->xgm_led), GFP_KERNEL);
>> + if (drvdata->xgm_led == NULL) {
>> + ret = -ENOMEM;
>> + goto err_stop_hw;
>> + }
>> + drvdata->xgm_led->hdev = hdev;
>> + drvdata->xgm_led->cdev.name = devm_kasprintf(&hdev->dev, GFP_KERNEL,
>> + "asus:xgm-%s:led",
>> + strlen(hdev->uniq) ?
>> + hdev->uniq : dev_name(&hdev->dev));
>> + drvdata->xgm_led->cdev.brightness = 1;
>> + drvdata->xgm_led->cdev.max_brightness = 1;
>> + drvdata->xgm_led->cdev.brightness_set_blocking = asus_xgm_led_set;
>> +
>> + /*
>> + * Sometimes after a reboot LEDs are ON, sometimes are OFF: set them to
>> + * what the default brightness resets when doing a cold boot.
>> + */
> I think this is set by the driver, so you should reformat the comment
> above, so you should trim the comment.
>
> Perhaps, "The LED state is arbitrary on boot, therefore default to the
> initial brightness set above". This way it does not become outdated if
> cdev.brightness changes.
yeah better spelling. I agree.
>> + ret = asus_xgm_led_set(&drvdata->xgm_led->cdev, drvdata->xgm_led->cdev.brightness);
>> + if (ret) {
>> + hid_err(hdev, "Asus failed to set xgm led: %d\n", ret);
>> + goto err_stop_hw;
>> + }
> You already do this in asus_input_configured so you do it twice?
> Perhaps skip one if you end up keeping them? I think that it's better
> to keep this block.
In asus_input_configured? Will take a look in the next days. I tought
the other was in asus_resume since at resume they resets back...
> Or even better return an error in _get so that on boot it is
> ambiguous? I assume the leds remain to the state they had prior to the
> reboot? With this change, imagine a user that turned off the leds in
> windows, permabooted into Linux, and now has the lights always turn on
> during boot.
Cold boot sets them to ON, while rebooting keep them at what they were.
After exiting from sleep they are always ON, but this is on an ally,
I don't know if on an old rog flow it's the same.
> Moreover, can systemd restore this or is it out of scope for its led
> handler? Perhaps it is an ambitious idea though, and better skipped.
I don't see realistic for this to fail if it was successful at probe so it
shouldn't matter. As for systemd restoring them it would have to
be informed that they changed (but there is no read-back) so either
way something has to happen at resume, but doing this means no
additional software is necessary and user preference is being
respected regardless of anything else.
>> +
>> + ret = led_classdev_register(&hdev->dev, &drvdata->xgm_led->cdev);
>> + if (ret) {
>> + hid_err(hdev, "Asus failed to register xgm led: %d\n", ret);
>> + goto err_stop_hw;
>> + }
>> + }
>> +
>> /* Laptops keyboard backlight is always at 0x5a */
>> if (is_vendor && (drvdata->quirks & QUIRK_USE_KBD_BACKLIGHT) &&
>> (asus_has_report_id(hdev, FEATURE_KBD_REPORT_ID)) &&
>> @@ -1366,6 +1433,9 @@ static void asus_remove(struct hid_device *hdev)
>> if (drvdata->quirks & QUIRK_HID_FN_LOCK)
>> cancel_work_sync(&drvdata->fn_lock_sync_work);
>>
>> + if (drvdata->xgm_led)
>> + led_classdev_unregister(&drvdata->xgm_led->cdev);
>> +
>> hid_hw_stop(hdev);
>> }
>>
>> --
>> 2.47.3
>>
>>
Thanks,
Denis
^ permalink raw reply
* Re: [PATCH] HID: hidpp: fix potential UAF in hidpp_connect_event()
From: sashiko-bot @ 2026-06-12 16:04 UTC (permalink / raw)
To: Jiri Kosina; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <r7qq6043-p432-51o0-3s93-r9382q44n027@xreary.bet>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] TOCTOU race condition causing Use-After-Free during hidpp_connect_event error cleanup.
- [High] Use-After-Free due to dangling hidpp->input if hidinput_connect() fails during initial probe.
- [High] NULL pointer dereference in input_ff_upload if hidpp_ff_init fails midway.
--
commit 0f581c2f8ce1a26d47a4afafa4a00600b3d649dd
Author: Jiri Kosina <jikos@kernel.org>
HID: hidpp: fix potential UAF in hidpp_connect_event()
If input_register_device() fails, we call input_free_device(), but keep
stale pointer to the old device in hidpp->input, which could potentially
lead to UAF. Fix that by resetting it to NULL before returning from
hidpp_connect_event().
Reported-by: zdi-disclosures@trendmicro.com
Signed-off-by: Jiri Kosina <jkosina@suse.com>
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> index ccbf28869a968..2800c31e54e41 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -4296,6 +4296,7 @@ static void hidpp_connect_event(struct work_struct *work)
> ret = input_register_device(input);
> if (ret) {
> input_free_device(input);
> + hidpp->input = NULL;
[Severity: High]
This is a pre-existing issue, but does setting this pointer to NULL after
freeing the input device leave a race window?
Because hidpp_connect_event() runs asynchronously in a workqueue, incoming
HID reports can be processed concurrently by hidpp_raw_event() in
interrupt context.
Could an interrupt arrive right after input_free_device() but before the
pointer is cleared, causing hidpp_raw_event() to bypass the
"if (!hidpp->input)" check and dereference the freed memory?
Would it be safer to clear the pointer before calling input_free_device(),
or does this require further synchronization since hidpp_raw_event()
accesses the pointer without holding locks?
[Severity: High]
This is a pre-existing issue, but does a similar use-after-free exist
during the initial probe path?
In hidpp_input_configured(), hidpp->input is persistently set before the
HID core attempts to register the input device:
drivers/hid/hid-logitech-hidpp.c:hidpp_input_configured() {
...
hidpp_populate_input(hidpp, input);
...
}
If input_register_device() subsequently fails inside hidinput_connect(),
the input core destroys the input_dev object, but hidpp->input is never
cleared.
Since hid_connect() can still succeed if other interfaces connect
successfully, incoming HID reports routed to hidpp_raw_event()
would then dereference the dangling hidpp->input pointer.
Could this lead to a use-after-free?
[Severity: High]
This is a pre-existing issue, but is there a potential NULL pointer
dereference if hidpp_ff_init() fails midway?
In hidpp_ff_init(), input_ff_create() is called early, which allocates
dev->ff and enables the EV_FF bit. If a subsequent memory allocation fails:
drivers/hid/hid-logitech-hidpp.c:hidpp_ff_init() {
...
data = kmemdup(data, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
...
}
The function returns without calling input_ff_destroy(). Later,
hidpp_probe() explicitly ignores this error:
drivers/hid/hid-logitech-hidpp.c:hidpp_probe() {
...
if (ret) {
hid_warn(hidpp->hid_dev,
"Unable to initialize force feedback support, errno %d\n",
ret);
ret = 0;
}
...
}
This allows the broken device to be registered. If userspace then sends an
EVIOCSFF ioctl, the input core invokes input_ff_upload(), which
unconditionally calls the driver's ff->upload function.
Since ff->upload was never assigned due to the early failure, could
dereferencing this NULL pointer cause a crash?
> return;
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/r7qq6043-p432-51o0-3s93-r9382q44n027@xreary.bet?part=1
^ permalink raw reply
* Re: [PATCH v2 8/9] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Conor Dooley @ 2026-06-12 16:15 UTC (permalink / raw)
To: Jun Yan
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260612072237.1177304-9-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3266 bytes --]
On Fri, Jun 12, 2026 at 03:22:14PM +0800, Jun Yan wrote:
> CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
> and hardware reset support.
>
> Add the compatible string for CAP1114, add its datasheet URL,
> update the maximum of LED channel reg, and add constraint for
> linux,keycodes.
>
> Previously, the LED reg property had a default maximum of 7 for CAP1188.
> With the addition of CAP1114, the default maximum is now 11.
> An if-then constraint is added to limit the LED count for CAP1188.
>
> Update description for microchip,input-threshold: CAP1114 only provides
> eight threshold entries, which does not match its total channel count.
>
> CAP1114 does not support microchip,signal-guard and
> microchip,calib-sensitivity.
>
> Add CAP1114 to the unsupported enum list.
>
> Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> ---
> .../bindings/input/microchip,cap11xx.yaml | 32 ++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> index 778ec6d659a8..0e9a1a8a3f3e 100644
> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> @@ -12,6 +12,7 @@ description: |
>
> For more product information please see the links below:
> CAP1106: https://ww1.microchip.com/downloads/en/DeviceDoc/00001624B.pdf
> + CAP1114: https://ww1.microchip.com/downloads/en/DeviceDoc/00002444A.pdf
> CAP1126: https://ww1.microchip.com/downloads/en/DeviceDoc/00001623B.pdf
> CAP1188: https://ww1.microchip.com/downloads/en/DeviceDoc/00001620C.pdf
> CAP1203: https://ww1.microchip.com/downloads/en/DeviceDoc/00001572B.pdf
> @@ -26,6 +27,7 @@ properties:
> compatible:
> enum:
> - microchip,cap1106
> + - microchip,cap1114
> - microchip,cap1126
> - microchip,cap1188
> - microchip,cap1203
> @@ -122,6 +124,8 @@ properties:
> is required for a touch to be registered, making the touch sensor less
> sensitive.
> The number of entries must correspond to the number of channels.
> + CAP1114 is an exception where channels 8~14 reuse the eighth entry's
> + threshold, so counts differ.
>
> microchip,calib-sensitivity:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> @@ -149,7 +153,7 @@ patternProperties:
> reg:
> description: LED channel number
> minimum: 0
> - maximum: 7
> + maximum: 10
>
> label: true
>
> @@ -178,6 +182,18 @@ allOf:
> properties:
> reset-gpios: false
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - microchip,cap1114
> + then:
> + properties:
> + linux,keycodes:
> + minItems: 14
> + maxItems: 14
Sashiko complaint here is valid.
You need to increase the outer constraint to max 14, and only set the
min here.
Then you need to add an else that sets maxitems to 8.
pw-bot: changes-requested
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [dtor-input:test] BUILD SUCCESS 48ec650ebfa9c834c0bd31605f911e084a8e5bf2
From: kernel test robot @ 2026-06-12 18:20 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git test
branch HEAD: 48ec650ebfa9c834c0bd31605f911e084a8e5bf2 Input: rmi4 - update formatting in F12
elapsed time: 763m
configs tested: 195
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260612 gcc-13.4.0
arc randconfig-002-20260612 gcc-13.4.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm axm55xx_defconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260612 gcc-13.4.0
arm randconfig-002-20260612 gcc-13.4.0
arm randconfig-003-20260612 gcc-13.4.0
arm randconfig-004-20260612 gcc-13.4.0
arm spear13xx_defconfig gcc-16.1.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260612 gcc-13.4.0
arm64 randconfig-002-20260612 gcc-13.4.0
arm64 randconfig-003-20260612 gcc-13.4.0
arm64 randconfig-004-20260612 gcc-13.4.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260612 gcc-13.4.0
csky randconfig-002-20260612 gcc-13.4.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260612 clang-23
hexagon randconfig-002-20260612 clang-23
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260612 gcc-14
i386 buildonly-randconfig-002-20260612 gcc-14
i386 buildonly-randconfig-003-20260612 gcc-14
i386 buildonly-randconfig-004-20260612 gcc-14
i386 buildonly-randconfig-005-20260612 gcc-14
i386 buildonly-randconfig-006-20260612 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260612 clang-22
i386 randconfig-002-20260612 clang-22
i386 randconfig-003-20260612 clang-22
i386 randconfig-004-20260612 clang-22
i386 randconfig-005-20260612 clang-22
i386 randconfig-006-20260612 clang-22
i386 randconfig-007-20260612 clang-22
i386 randconfig-011-20260612 clang-22
i386 randconfig-012-20260612 clang-22
i386 randconfig-013-20260612 clang-22
i386 randconfig-014-20260612 clang-22
i386 randconfig-015-20260612 clang-22
i386 randconfig-016-20260612 clang-22
i386 randconfig-017-20260612 clang-22
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260612 clang-23
loongarch randconfig-002-20260612 clang-23
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001-20260612 clang-23
nios2 randconfig-002-20260612 clang-23
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-23
parisc defconfig gcc-16.1.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc mpc885_ads_defconfig clang-23
powerpc ppc64e_defconfig gcc-16.1.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-11.5.0
riscv randconfig-001-20260612 gcc-11.5.0
riscv randconfig-002 gcc-11.5.0
riscv randconfig-002-20260612 gcc-11.5.0
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-11.5.0
s390 randconfig-001-20260612 gcc-11.5.0
s390 randconfig-002 gcc-11.5.0
s390 randconfig-002-20260612 gcc-11.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-23
sh defconfig gcc-14
sh randconfig-001 gcc-11.5.0
sh randconfig-001-20260612 gcc-11.5.0
sh randconfig-002 gcc-11.5.0
sh randconfig-002-20260612 gcc-11.5.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260612 gcc-8.5.0
sparc randconfig-002-20260612 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260612 gcc-8.5.0
sparc64 randconfig-002-20260612 gcc-8.5.0
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260612 gcc-8.5.0
um randconfig-002-20260612 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 gcc-14
x86_64 buildonly-randconfig-001-20260612 gcc-14
x86_64 buildonly-randconfig-002 gcc-14
x86_64 buildonly-randconfig-002-20260612 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260612 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260612 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260612 gcc-14
x86_64 buildonly-randconfig-006 gcc-14
x86_64 buildonly-randconfig-006-20260612 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260612 clang-22
x86_64 randconfig-002-20260612 clang-22
x86_64 randconfig-003-20260612 clang-22
x86_64 randconfig-004-20260612 clang-22
x86_64 randconfig-005-20260612 clang-22
x86_64 randconfig-006-20260612 clang-22
x86_64 randconfig-011 clang-22
x86_64 randconfig-011-20260612 clang-22
x86_64 randconfig-012 clang-22
x86_64 randconfig-012-20260612 clang-22
x86_64 randconfig-013 clang-22
x86_64 randconfig-013-20260612 clang-22
x86_64 randconfig-014 clang-22
x86_64 randconfig-014-20260612 clang-22
x86_64 randconfig-015 clang-22
x86_64 randconfig-015-20260612 clang-22
x86_64 randconfig-016 clang-22
x86_64 randconfig-016-20260612 clang-22
x86_64 randconfig-071-20260612 gcc-14
x86_64 randconfig-072-20260612 gcc-14
x86_64 randconfig-073-20260612 gcc-14
x86_64 randconfig-074-20260612 gcc-14
x86_64 randconfig-075-20260612 gcc-14
x86_64 randconfig-076-20260612 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001-20260612 gcc-8.5.0
xtensa randconfig-002-20260612 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 040b099a58aad06e436cd3a46475fa983efd6c93
From: kernel test robot @ 2026-06-12 19:11 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: 040b099a58aad06e436cd3a46475fa983efd6c93 Input: rmi4 - update formatting in F12
elapsed time: 784m
configs tested: 211
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260612 gcc-13.4.0
arc randconfig-002-20260612 gcc-13.4.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm axm55xx_defconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260612 gcc-13.4.0
arm randconfig-002-20260612 gcc-13.4.0
arm randconfig-003-20260612 gcc-13.4.0
arm randconfig-004-20260612 gcc-13.4.0
arm spear13xx_defconfig gcc-16.1.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260612 gcc-13.4.0
arm64 randconfig-002-20260612 gcc-13.4.0
arm64 randconfig-003-20260612 gcc-13.4.0
arm64 randconfig-004-20260612 gcc-13.4.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260612 gcc-13.4.0
csky randconfig-002-20260612 gcc-13.4.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260612 clang-23
hexagon randconfig-001-20260612 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260612 clang-23
hexagon randconfig-002-20260612 gcc-11.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001 gcc-14
i386 buildonly-randconfig-001-20260612 gcc-14
i386 buildonly-randconfig-002 gcc-14
i386 buildonly-randconfig-002-20260612 gcc-14
i386 buildonly-randconfig-003 gcc-14
i386 buildonly-randconfig-003-20260612 gcc-14
i386 buildonly-randconfig-004 gcc-14
i386 buildonly-randconfig-004-20260612 gcc-14
i386 buildonly-randconfig-005 gcc-14
i386 buildonly-randconfig-005-20260612 gcc-14
i386 buildonly-randconfig-006 gcc-14
i386 buildonly-randconfig-006-20260612 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260612 clang-22
i386 randconfig-002-20260612 clang-22
i386 randconfig-003-20260612 clang-22
i386 randconfig-004-20260612 clang-22
i386 randconfig-005-20260612 clang-22
i386 randconfig-006-20260612 clang-22
i386 randconfig-007-20260612 clang-22
i386 randconfig-011-20260612 clang-22
i386 randconfig-012-20260612 clang-22
i386 randconfig-013-20260612 clang-22
i386 randconfig-014-20260612 clang-22
i386 randconfig-015-20260612 clang-22
i386 randconfig-016-20260612 clang-22
i386 randconfig-017-20260612 clang-22
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260612 clang-23
loongarch randconfig-001-20260612 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260612 clang-23
loongarch randconfig-002-20260612 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260612 clang-23
nios2 randconfig-001-20260612 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260612 clang-23
nios2 randconfig-002-20260612 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-23
parisc defconfig gcc-16.1.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc mpc885_ads_defconfig clang-23
powerpc ppc64e_defconfig gcc-16.1.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-11.5.0
riscv randconfig-001-20260612 gcc-11.5.0
riscv randconfig-002 gcc-11.5.0
riscv randconfig-002-20260612 gcc-11.5.0
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-11.5.0
s390 randconfig-001-20260612 gcc-11.5.0
s390 randconfig-002 gcc-11.5.0
s390 randconfig-002-20260612 gcc-11.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-23
sh defconfig gcc-14
sh randconfig-001 gcc-11.5.0
sh randconfig-001-20260612 gcc-11.5.0
sh randconfig-002 gcc-11.5.0
sh randconfig-002-20260612 gcc-11.5.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260612 gcc-8.5.0
sparc randconfig-002-20260612 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260612 gcc-8.5.0
sparc64 randconfig-002-20260612 gcc-8.5.0
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260612 gcc-8.5.0
um randconfig-002-20260612 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001 gcc-14
x86_64 buildonly-randconfig-001-20260612 gcc-14
x86_64 buildonly-randconfig-002 gcc-14
x86_64 buildonly-randconfig-002-20260612 gcc-14
x86_64 buildonly-randconfig-003 gcc-14
x86_64 buildonly-randconfig-003-20260612 gcc-14
x86_64 buildonly-randconfig-004 gcc-14
x86_64 buildonly-randconfig-004-20260612 gcc-14
x86_64 buildonly-randconfig-005 gcc-14
x86_64 buildonly-randconfig-005-20260612 gcc-14
x86_64 buildonly-randconfig-006 gcc-14
x86_64 buildonly-randconfig-006-20260612 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260612 clang-22
x86_64 randconfig-002-20260612 clang-22
x86_64 randconfig-003-20260612 clang-22
x86_64 randconfig-004-20260612 clang-22
x86_64 randconfig-005-20260612 clang-22
x86_64 randconfig-006-20260612 clang-22
x86_64 randconfig-011 clang-22
x86_64 randconfig-011-20260612 clang-22
x86_64 randconfig-012 clang-22
x86_64 randconfig-012-20260612 clang-22
x86_64 randconfig-013 clang-22
x86_64 randconfig-013-20260612 clang-22
x86_64 randconfig-014 clang-22
x86_64 randconfig-014-20260612 clang-22
x86_64 randconfig-015 clang-22
x86_64 randconfig-015-20260612 clang-22
x86_64 randconfig-016 clang-22
x86_64 randconfig-016-20260612 clang-22
x86_64 randconfig-071-20260612 gcc-14
x86_64 randconfig-072-20260612 gcc-14
x86_64 randconfig-073-20260612 gcc-14
x86_64 randconfig-074-20260612 gcc-14
x86_64 randconfig-075-20260612 gcc-14
x86_64 randconfig-076-20260612 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001-20260612 gcc-8.5.0
xtensa randconfig-002-20260612 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v6 0/7] Add support for MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-06-12 20:04 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Julien Massot,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Akari Tsuyukusa,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
The MediaTek MT6392 PMIC is usually found on devices powered by
the MT8516/MT8167 SoC and is yet another MT6323/MT6397 variant.
This series is mostly based around patches submitted a couple
years ago by Fabien Parent and not merged and from Val Packett's
submission from Jan 2025 that included extra cleanups, fixes, and a
new dtsi file similar to ones that exist for other PMICs. Some
comments weren't addressed and the series was ultimately not merged.
These patches only enable three functions: keys, pinctrl and RTC.
Regulators and speaker amp will follow later as I still need to further
improve those two, but getting the main PMIC in will make the series
easier to review.
I added a handful of device tree improvements to fix some dtbs_check
errors, added support for the pinctrl device and addressed the comments
from last year's reviews.
Please note that patch 0005 depends on patch 0004 as they both need the
registers.h file, but they belong to different driver areas. I'm not sure
if I'm supposed to squash them even if they belong to different driver
areas of if it's fine like this. Any advice is welcome.
The series has been tested on Xiaomi Mi Smart Clock X04G and on the
Lenovo Smart Clock 2.
Changes in v6:
- Dropped the regulators driver for the moment
- Explained the FCHR key name origin in the commit message
- Introduced the MFD_CELL_* macro in the sub-devices definitions.
A separate, independent commit introduced MFD_CELL_* to all the
subdevices in the mt6397-core.c file for consistency
- Replaced of_device_get_match_data with device_get_match_data
- Removed the mfd_match_data enum in favor of the preexisting
chip_id enum
- Adjusted the error message if the device is unsupported
Changes in v5 [5]:
- Double checked regulator driver with data sheet and Android sources.
The data sheet I have misses a lot of register descriptions, but
Android sources have been helpful to fill the gaps
- Reintroduced the required attribute for the regulator compatible
in the bindings
- Fixed the missing reference to the MT6392 schema
- Fixed casts/unused vars reported by kernel test robot
- Removed Reviewed-by tags from the regulator patches as they have been
modified in this version
Changes in v4 [4]:
- Dropped usage of the regulator compatible
- Fixed commit messages text to properly reference the target subsystem
- Added supply rails to the regulator
- Reworked the regulator schema and PMIC dtsi. Now all supplies are
documented and the schema no longer includes voltage information
- Removed redundant ldo- / buck- prefixes
- Renamed the pinfunc header to mediatek,mt6392-pinfunc.h
- Modified the MFD driver to use a simple identifier in the of_match
data properties
Changes in v3 [3]:
- Added pinctrl device
- Changed mt6397-rtc fallback to mt6323-rtc
- Added schema for regulators
- Fixed checkpatch issues
Changes in v2 [2]:
- Replaced explicit compatibles with fallbacks
Initial version: [1]
[1] https://lore.kernel.org/linux-mediatek/cover.1771865014.git.l.scorcia@gmail.com/
[2] https://lore.kernel.org/linux-mediatek/20260306120521.163654-1-l.scorcia@gmail.com/
[3] https://lore.kernel.org/linux-mediatek/20260317184507.523060-1-l.scorcia@gmail.com/
[4] https://lore.kernel.org/linux-mediatek/20260330083429.359819-1-l.scorcia@gmail.com/
[5] https://lore.kernel.org/linux-mediatek/20260420213529.1645560-1-l.scorcia@gmail.com/
Fabien Parent (3):
dt-bindings: mfd: mt6397: Add MT6392 PMIC
dt-bindings: input: mtk-pmic-keys: Add MT6392 PMIC keys
mfd: mt6397: Add support for MT6392 PMIC
Luca Leonardo Scorcia (2):
mfd: mt6397: Use MFD_CELL_* to describe sub-devices
pinctrl: mediatek: mt6397: Add MediaTek MT6392
Val Packett (2):
input: keyboard: mtk-pmic-keys: Add MT6392 support
arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
.../bindings/input/mediatek,pmic-keys.yaml | 1 +
.../bindings/mfd/mediatek,mt6397.yaml | 8 +
arch/arm64/boot/dts/mediatek/mt6392.dtsi | 41 ++
drivers/input/keyboard/mtk-pmic-keys.c | 17 +
drivers/mfd/mt6397-core.c | 294 +++++------
drivers/mfd/mt6397-irq.c | 8 +
drivers/pinctrl/mediatek/pinctrl-mt6397.c | 37 +-
drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h | 64 +++
include/linux/mfd/mt6392/core.h | 43 ++
include/linux/mfd/mt6392/registers.h | 488 ++++++++++++++++++
include/linux/mfd/mt6397/core.h | 1 +
11 files changed, 840 insertions(+), 162 deletions(-)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt6392.h
create mode 100644 include/linux/mfd/mt6392/core.h
create mode 100644 include/linux/mfd/mt6392/registers.h
--
2.43.0
^ 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