* Re: [PATCH] HID: Input: Add battery list cleanup in hidinput_disconnect()
From: sashiko-bot @ 2026-06-02 2:03 UTC (permalink / raw)
To: Rafael Passos; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260602015029.2838058-1-rafael@rcpassos.me>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch introduces a Use-After-Free (UAF) and a soft-lockup race condition by manually unlinking `devm`-managed battery structures from `hid->batteries` during `hidinput_disconnect()`.
--
commit f0760b781af9f4b5e629ebfa0c88970cbaaea8fe
Author: Rafael Passos <rafael@rcpassos.me>
HID: Input: Add battery list cleanup in hidinput_disconnect()
The batteries list (hdev->batteries) is not cleaned up during
hidinput_disconnect(), but struct hid_battery entries are allocated
with devm_kzalloc. When a driver is unbound, devm frees those entries
while their list_head nodes remain dangling in hdev->batteries.
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index d73cfa2e73d33..95815e140fdf2 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -2408,6 +2408,15 @@ EXPORT_SYMBOL_GPL(hidinput_connect);
> void hidinput_disconnect(struct hid_device *hid)
> {
> struct hid_input *hidinput, *next;
> +#ifdef CONFIG_HID_BATTERY_STRENGTH
> + {
> + struct hid_battery *bat, *tmp;
> +
> + list_for_each_entry_safe(bat, tmp, &hid->batteries, list) {
> + list_del_init(&bat->list);
[Severity: High]
Does this introduce a use-after-free and a race condition?
If a driver releases its devres group before calling hid_hw_stop(), the
battery structures allocated with devm_kzalloc() will be freed early. For
example, wacom_mode_change_work() in drivers/hid/wacom_sys.c acts like
this:
wacom_mode_change_work()
wacom_release_resources(wacom1);
hid_hw_stop(wacom1->hdev);
Since wacom_release_resources() releases the devres group, the battery
memory is freed before hid_hw_stop() calls hidinput_disconnect(). When we
reach this loop, we will iterate over and modify already-freed memory.
Additionally, hid_hw_stop() can be called asynchronously without holding
hdev->driver_input_lock. Modifying hid->batteries here can race with
concurrent readers like hidinput_update_battery(), which iterates over
the list, potentially causing a crash or infinite loop.
Could the cleanup be handled by adding a custom action during battery setup
via devm_add_action_or_reset(), so it is guaranteed to happen exactly when
the devm resource is freed?
> + }
> + }
> +#endif
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260602015029.2838058-1-rafael@rcpassos.me?part=1
^ permalink raw reply
* [PATCH v2] HID: Input: Add battery list cleanup with devm action
From: Rafael Passos @ 2026-06-02 3:05 UTC (permalink / raw)
To: linux-input, lcasmz54, bentiss
Cc: hadess, jikos, linux-kernel, linux-pm, sre, kernel, Rafael Passos
The batteries list (hdev->batteries) is not cleaned up during
hidinput_disconnect(), but struct hid_battery entries are allocated
with devm_kzalloc.
When a driver is unbound (e.g. during devicereprobe), devm frees those
entries while their list_head nodesremain dangling in hdev->batteries,
which persists across rebinds.
Fixes: 4a58ae85c3f9 ("HID: input: Add support for multiple batteries per device")
Signed-off-by: Rafael Passos <rafael@rcpassos.me>
---
Hi, I hope there is time to land this in this cycle.
Tell me if I should make any changes.
I built and tested it againts the mainline.
I dont have devices with multiple batteries to test.
Bug report link:
https://lore.kernel.org/all/20260602011949.2825852-1-rafael@rcpassos.me/
I received a sashiko review, and looked at wacom drivers for inspiration.
Changes in v2:
- removed list deletion from hidinput_disconnect
- new hidinput_cleanup_battery method
- register the cleanup call using devm action
in hidinput_setup_battery
If my searching was corect, this shoul be called when devres releases its group
The commit message changed, because it referenced the
hidinput_disconnect method.
Original patch: https://lore.kernel.org/linux-input/20260602020352.4256D1F00893@smtp.kernel.org/T/#t
The sashiko review: https://sashiko.dev/#/patchset/20260602015029.2838058-1-rafael@rcpassos.me?part=1
drivers/hid/hid-input.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index d73cfa2e73d3..c7b8c4ff7a33 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -519,6 +519,13 @@ static struct hid_battery *hidinput_find_battery(struct hid_device *dev,
return NULL;
}
+static void hidinput_cleanup_battery(void *res)
+{
+ struct hid_battery *bat = res;
+
+ list_del(&bat->list);
+}
+
static int hidinput_setup_battery(struct hid_device *dev, unsigned report_type,
struct hid_field *field, bool is_percentage)
{
@@ -610,6 +617,12 @@ static int hidinput_setup_battery(struct hid_device *dev, unsigned report_type,
power_supply_powers(bat->ps, &dev->dev);
list_add_tail(&bat->list, &dev->batteries);
+
+ error = devm_add_action_or_reset(&dev->dev,
+ hidinput_cleanup_battery, bat);
+ if (error)
+ return error;
+
return 0;
err_free_name:
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] HID: Input: Add battery list cleanup with devm action
From: Lucas Zampieri @ 2026-06-02 3:44 UTC (permalink / raw)
To: Rafael Passos
Cc: linux-input, Benjamin Tissoires, Jiri Kosina, Sebastian Reichel,
Bastien Nocera, linux-kernel, linux-pm, kernel
In-Reply-To: <20260602030519.3097058-1-rafael@rcpassos.me>
Hi Rafael,
Thanks for catching this and the quick fix. Turns out this is the
hidinput_cleanup_battery() hunk we dropped in the devm conversion
(patch 1/3), figuring devm would handle the cleanup. It frees the
hid_battery structs fine, but never unlinks them from hdev->batteries,
which outlives the devm scope, so the list dangles into freed memory on
the next probe. My bad.
Acked-by: Lucas Zampieri <lcasmz54@gmail.com>
^ permalink raw reply
* [PATCH] Input: xilinx_ps2 - replace in_be32/out_be32 with ioread32be/iowrite32be
From: Rosen Penev @ 2026-06-02 3:59 UTC (permalink / raw)
To: linux-input
Cc: Dmitry Torokhov, chleroy, Michal Simek, open list,
moderated list:ARM/ZYNQ ARCHITECTURE
Mechanical conversion of the ppc4xx-specific accessors to the generic
portable helpers.
Allows enabling COMPILE_TEST for extra compile coverage.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/input/serio/Kconfig | 2 +-
drivers/input/serio/xilinx_ps2.c | 24 ++++++++++++------------
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 5f15a6462056..60d886631c42 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -190,7 +190,7 @@ config SERIO_RAW
config SERIO_XILINX_XPS_PS2
tristate "Xilinx XPS PS/2 Controller Support"
- depends on PPC || MICROBLAZE
+ depends on PPC || MICROBLAZE || COMPILE_TEST
help
This driver supports XPS PS/2 IP from the Xilinx EDK on
PowerPC platform.
diff --git a/drivers/input/serio/xilinx_ps2.c b/drivers/input/serio/xilinx_ps2.c
index 411d55ca1a66..7eb96375b515 100644
--- a/drivers/input/serio/xilinx_ps2.c
+++ b/drivers/input/serio/xilinx_ps2.c
@@ -89,9 +89,9 @@ static int xps2_recv(struct xps2data *drvdata, u8 *byte)
int status = -1;
/* If there is data available in the PS/2 receiver, read it */
- sr = in_be32(drvdata->base_address + XPS2_STATUS_OFFSET);
+ sr = ioread32be(drvdata->base_address + XPS2_STATUS_OFFSET);
if (sr & XPS2_STATUS_RX_FULL) {
- *byte = in_be32(drvdata->base_address + XPS2_RX_DATA_OFFSET);
+ *byte = ioread32be(drvdata->base_address + XPS2_RX_DATA_OFFSET);
status = 0;
}
@@ -109,8 +109,8 @@ static irqreturn_t xps2_interrupt(int irq, void *dev_id)
int status;
/* Get the PS/2 interrupts and clear them */
- intr_sr = in_be32(drvdata->base_address + XPS2_IPISR_OFFSET);
- out_be32(drvdata->base_address + XPS2_IPISR_OFFSET, intr_sr);
+ intr_sr = ioread32be(drvdata->base_address + XPS2_IPISR_OFFSET);
+ iowrite32be(intr_sr, drvdata->base_address + XPS2_IPISR_OFFSET);
/* Check which interrupt is active */
if (intr_sr & XPS2_IPIXR_RX_OVF)
@@ -160,11 +160,11 @@ static int sxps2_write(struct serio *pserio, unsigned char c)
guard(spinlock_irqsave)(&drvdata->lock);
/* If the PS/2 transmitter is empty send a byte of data */
- sr = in_be32(drvdata->base_address + XPS2_STATUS_OFFSET);
+ sr = ioread32be(drvdata->base_address + XPS2_STATUS_OFFSET);
if (sr & XPS2_STATUS_TX_FULL)
return -EAGAIN;
- out_be32(drvdata->base_address + XPS2_TX_DATA_OFFSET, c);
+ iowrite32be(c, drvdata->base_address + XPS2_TX_DATA_OFFSET);
return 0;
}
@@ -189,8 +189,8 @@ static int sxps2_open(struct serio *pserio)
}
/* start reception by enabling the interrupts */
- out_be32(drvdata->base_address + XPS2_GIER_OFFSET, XPS2_GIER_GIE_MASK);
- out_be32(drvdata->base_address + XPS2_IPIER_OFFSET, XPS2_IPIXR_RX_ALL);
+ iowrite32be(XPS2_GIER_GIE_MASK, drvdata->base_address + XPS2_GIER_OFFSET);
+ iowrite32be(XPS2_IPIXR_RX_ALL, drvdata->base_address + XPS2_IPIER_OFFSET);
(void)xps2_recv(drvdata, &c);
return 0; /* success */
@@ -207,8 +207,8 @@ static void sxps2_close(struct serio *pserio)
struct xps2data *drvdata = pserio->port_data;
/* Disable the PS2 interrupts */
- out_be32(drvdata->base_address + XPS2_GIER_OFFSET, 0x00);
- out_be32(drvdata->base_address + XPS2_IPIER_OFFSET, 0x00);
+ iowrite32be(0x00, drvdata->base_address + XPS2_GIER_OFFSET);
+ iowrite32be(0x00, drvdata->base_address + XPS2_IPIER_OFFSET);
free_irq(drvdata->irq, drvdata);
}
@@ -278,13 +278,13 @@ static int xps2_of_probe(struct platform_device *ofdev)
}
/* Disable all the interrupts, just in case */
- out_be32(drvdata->base_address + XPS2_IPIER_OFFSET, 0);
+ iowrite32be(0, drvdata->base_address + XPS2_IPIER_OFFSET);
/*
* Reset the PS2 device and abort any current transaction,
* to make sure we have the PS2 in a good state.
*/
- out_be32(drvdata->base_address + XPS2_SRST_OFFSET, XPS2_SRST_RESET);
+ iowrite32be(XPS2_SRST_RESET, drvdata->base_address + XPS2_SRST_OFFSET);
dev_info(dev, "Xilinx PS2 at 0x%08llX mapped to 0x%p, irq=%d\n",
(unsigned long long)phys_addr, drvdata->base_address,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] Input: xilinx_ps2 - replace in_be32/out_be32 with ioread32be/iowrite32be
From: sashiko-bot @ 2026-06-02 4:10 UTC (permalink / raw)
To: Rosen Penev; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <20260602035907.623599-1-rosenp@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Adding COMPILE_TEST exposes the driver to architectures without HAS_IOMEM, leading to build failures.
--
commit fa18055bb5a7f7464dd14a35a0c7198e7099cd71
Author: Rosen Penev <rosenp@gmail.com>
Input: xilinx_ps2 - replace in_be32/out_be32 with ioread32be/iowrite32be
This commit mechanically converts ppc4xx-specific accessors to generic portable
helpers. It also enables COMPILE_TEST for extra compile coverage.
> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
> index 5f15a6462056b..60d886631c429 100644
> --- a/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -190,7 +190,7 @@ config SERIO_RAW
>
> config SERIO_XILINX_XPS_PS2
> tristate "Xilinx XPS PS/2 Controller Support"
> - depends on PPC || MICROBLAZE
> + depends on PPC || MICROBLAZE || COMPILE_TEST
[Severity: Low]
Does adding COMPILE_TEST here expose this driver to architectures without
HAS_IOMEM?
Since the driver relies heavily on memory-mapped I/O functions like ioremap(),
ioread32be(), and iowrite32be(), allowing it to build on architectures that do
not support MMIO (such as ARCH=um) could result in build or linker errors.
Would it be safer to add a dependency on HAS_IOMEM?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260602035907.623599-1-rosenp@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH] Input: synaptics - add quirk for Daffodil DC253D touchpad
From: dmitrytorokhov @ 2026-06-02 4:56 UTC (permalink / raw)
To: Ashwin Gundarapu; +Cc: linux-input, linux-kernel, ubuntu-kernel, hasan6l
In-Reply-To: <19e5047ead1.ce62bdb39017.6022546617731203250@zohomail.in>
Hi Ashwin,
On Fri, May 22, 2026 at 08:52:30PM +0530, Ashwin Gundarapu wrote:
> From ee16efae3c4371d37467c49c0cae6af808e1b625 Mon Sep 17 00:00:00 2001
> From: Ashwin Gundarapu <linuxuser509@zohomail.in>
> Date: Fri, 22 May 2026 20:48:25 +0530
> Subject: [PATCH] Input: synaptics - add quirk for Daffodil DC253D touchpad
>
> On the Daffodil DC253D laptop, the touchpad is incorrectly detected as
> a clickpad, causing the right button to be missing. Add a DMI quirk
> to clear the CLICKPAD bit for this device.
I wonder if the device can work on SMbus/RMI4 mode and if it behaves
better in RMI configuration?
>
> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153983
> Signed-off-by: Ashwin Gundarapu <linuxuser509@zohomail.in>
> ---
> drivers/input/mouse/synaptics.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index 26071128f43a..4ca85fb4ab70 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -534,9 +534,16 @@ static int synaptics_invert_y(int y)
> * Apply quirk(s) if the hardware matches
> */
> static void synaptics_apply_quirks(struct psmouse *psmouse,
> - struct synaptics_device_info *info)
> + struct synaptics_device_info *info)
> {
> - int i;
> + int i;
> +
> + /* Daffodil DC253D has a physical right button */
> + if (dmi_match(DMI_SYS_VENDOR, "Daffodil Computers Ltd.") &&
> + dmi_match(DMI_PRODUCT_NAME, "DC253D")) {
> + info->ext_cap_0c &= ~BIT(20); /* Clear CLICKPAD bit */
> + psmouse_info(psmouse, "Force right button on Daffodil DC253D\n");
> + }
The patch is whitespace-damaged.
>
> for (i = 0; min_max_pnpid_table[i].pnp_ids; i++) {
> if (!psmouse_matches_pnp_id(psmouse,
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: xilinx_ps2 - replace in_be32/out_be32 with ioread32be/iowrite32be
From: Michal Simek @ 2026-06-02 6:23 UTC (permalink / raw)
To: Rosen Penev, linux-input
Cc: Dmitry Torokhov, chleroy, open list,
moderated list:ARM/ZYNQ ARCHITECTURE
In-Reply-To: <20260602035907.623599-1-rosenp@gmail.com>
On 6/2/26 05:59, Rosen Penev wrote:
> Mechanical conversion of the ppc4xx-specific accessors to the generic
> portable helpers.
>
> Allows enabling COMPILE_TEST for extra compile coverage.
>
> Assisted-by: opencode:big-pickle
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/input/serio/Kconfig | 2 +-
> drivers/input/serio/xilinx_ps2.c | 24 ++++++++++++------------
I don't think that anybody is really using this driver and would be better to
just remove it.
If not, no issue with that changes.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH] HID: usbhid: switch HIDBP devices to boot protocol
From: Greg KH @ 2026-06-02 6:41 UTC (permalink / raw)
To: Xu Rao; +Cc: jikos, bentiss, linux-usb, linux-input, linux-kernel
In-Reply-To: <A49C63267F00CDA8+20260602014835.2624940-1-raoxu@uniontech.com>
On Tue, Jun 02, 2026 at 09:48:35AM +0800, Xu Rao wrote:
> usbkbd and usbmouse are HID Boot Protocol drivers. They do not
> parse report descriptors before decoding interrupt reports; instead,
> they interpret input data as the fixed boot keyboard and boot mouse
> formats.
>
> The HID specification defines SET_PROTOCOL as the class request
> to select report or boot protocol. Boot subclass devices may power
> up or return from reset in report protocol, and hosts are expected
> to select the protocol they intend to use.
>
> Do not depend on firmware or a previous driver to leave the
> interface in boot protocol. Send SET_PROTOCOL(BOOT) during probe
> before the interrupt URB can be opened.
>
> Keep failures non-fatal. Some devices may reject the request while
> still sending boot-compatible reports. For those devices, the
> existing driver behavior is preferable.
Do you really use these drivers for devices? If so, why?
And shouldn't the failure be fatal? If not, why even attempt to send
it?
How was this tested? On what devices?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] HID: usbhid: switch HIDBP devices to boot protocol
From: Xu Rao @ 2026-06-02 7:26 UTC (permalink / raw)
To: gregkh; +Cc: bentiss, jikos, linux-input, linux-kernel, linux-usb, raoxu
In-Reply-To: <2026060216-freezable-donated-99e5@gregkh>
Hi Greg,
> > Do not depend on firmware or a previous driver to leave the
> > interface in boot protocol. Send SET_PROTOCOL(BOOT) during probe
> > before the interrupt URB can be opened.
> >
> > Keep failures non-fatal. Some devices may reject the request while
> > still sending boot-compatible reports. For those devices, the
> > existing driver behavior is preferable.
>
> Do you really use these drivers for devices? If so, why?
>
> And shouldn't the failure be fatal? If not, why even attempt to send
> it?
After checking the actual device path again, you are right: the devices
I had in mind use the normal usbhid/hid-generic path, not usbkbd or
usbmouse.
This patch came from reading the simple HID Boot Protocol drivers and
noticing that they decode fixed boot reports without explicitly selecting
boot protocol first. So this was a code-inspection cleanup rather than a
fix for a device that I can show is bound to these drivers.
Given that I do not have a real user of usbkbd/usbmouse to justify the
change and test coverage properly, please ignore/drop this patch.
Sorry for the noise, and thanks for pointing this out.
thanks,
Xu Rao
^ permalink raw reply
* Re: [PATCH v14 1/2] HID: cp2112: Add fwnode support
From: Benjamin Tissoires @ 2026-06-02 7:55 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Danny Kaehn, dmitry.torokhov, linux-input
In-Reply-To: <20260520170229.CEFA31F000E9@smtp.kernel.org>
On May 20 2026, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Premature release of firmware node references results in use-after-free vulnerabilities when assigning the I2C adapter and GPIO chip firmware nodes.
> --
>
> commit 3dfaf368e855835bf23009205c4b93a2a070aae1
> Author: Danny Kaehn <danny.kaehn@plexus.com>
>
> HID: cp2112: Add fwnode support
>
> This commit adds firmware node support to describe the CP2112's I2C and
> GPIO interfaces. It differentiates between ACPI and DeviceTree bindings,
> mapping the child nodes to the respective adapter and gpio_chip devices.
>
> > diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> > index 803b883ae8750..e960fc988058f 100644
> > --- a/drivers/hid/hid-cp2112.c
> > +++ b/drivers/hid/hid-cp2112.c
> [ ... ]
> > @@ -1226,6 +1241,28 @@ static int cp2112_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > return ret;
> > }
> >
> > + cp2112_fwnode = dev_fwnode(&hdev->dev);
> > + if (is_acpi_device_node(cp2112_fwnode)) {
> > + fwnode_for_each_child_node(cp2112_fwnode, child) {
> > + ret = acpi_get_local_address(ACPI_HANDLE_FWNODE(child), &addr);
> > + if (ret)
> > + continue;
> > +
> > + switch (addr) {
> > + case CP2112_I2C_ADR:
> > + device_set_node(&dev->adap.dev, child);
> > + break;
> > + case CP2112_GPIO_ADR:
> > + dev->gc.fwnode = child;
> > + break;
> > + }
>
> [Severity: High]
> Does this code leave dangling pointers in the device structures?
>
> The fwnode_for_each_child_node() macro automatically drops the reference to
> the child node when advancing to the next node or exiting the loop.
>
> Because device_set_node() and direct pointer assignments do not increment
> the reference count, the nodes assigned here could be prematurely freed
> resulting in a use-after-free.
Sashiko is overly cautious here. ACPI handles are not refcounted, so we
are fine.
That being said, we could unify the OF and ACPI behaviour by calling the
noops fwnode_handle_get(child) for ACPI as well and clean them up in
cp2112_remove(). This would also shut up the next warning from Sashiko
below.
>
> > + }
> > + } else if (is_of_node(cp2112_fwnode)) {
> > + child = fwnode_get_named_child_node(cp2112_fwnode, "i2c");
> > + device_set_node(&dev->adap.dev, child);
> > + fwnode_handle_put(child);
>
> [Severity: High]
> Are we releasing the firmware node prematurely here?
>
> fwnode_get_named_child_node() returns a node with an incremented reference
> count. However, since device_set_node() does not take its own reference on
> the child node, dropping the reference immediately after could leave
> dev->adap.dev with a dangling pointer if the node is later removed.
OF children are tied to the lifespan of the OF device, so we are fine,
but technically incorrect, as mentioned by Sashiko.
If you regroup the 2 behaviours and clean them in cp2112_remove(), this
would be cleaner IMO.
Cheers,
Benjamin
>
> > + }
> > +
> > ret = hid_parse(hdev);
> > if (ret) {
> > hid_err(hdev, "parse failed\n");
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260520-cp2112-dt-v14-0-b1b4b6734b6f@plexus.com?part=1
>
^ permalink raw reply
* Re: [PATCH v14 2/2] HID: cp2112: Configure I2C bus speed from firmware
From: Benjamin Tissoires @ 2026-06-02 7:59 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Danny Kaehn, dmitry.torokhov, linux-input
In-Reply-To: <20260520174401.BDE571F00893@smtp.kernel.org>
On May 20 2026, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
>
> New issues:
> - [Medium] The driver silently overwrites custom hardware I2C clock speeds with a 100kHz default for devices without firmware nodes.
>
> Pre-existing issues:
> - [High] Firmware nodes are attached to device structures without holding a reference, leading to a dangling pointer and use-after-free.
> - [High] The delayed work `gpio_poll_worker` is not canceled in the probe error path, leading to a use-after-free if the probe fails.
> --
>
> commit 07ff467e4d8df706a7a27476591cd82570fb8287
> Author: Danny Kaehn <danny.kaehn@plexus.com>
>
> HID: cp2112: Configure I2C bus speed from firmware
>
> Now that the I2C adapter on the CP2112 can have an associated firmware
> node, set the bus speed based on firmware configuration.
>
> > diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
> > index e960fc988058f..04379db93571b 100644
> > --- a/drivers/hid/hid-cp2112.c
> > +++ b/drivers/hid/hid-cp2112.c
> [ ... ]
> > @@ -1308,6 +1309,9 @@ static int cp2112_probe(struct hid_device *hdev, const struct hid_device_id *id)
> > goto err_power_normal;
> > }
> >
> > + i2c_parse_fw_timings(&dev->adap.dev, &timings, true);
> > +
>
> [Severity: High]
> This isn't a bug introduced by this patch, but does this new call dereference
> a dangling pointer?
Cleaning up the refcounting in the previous patch would solve this
(false positive, admitedly).
>
> Earlier in cp2112_probe(), the reference to the child firmware node is
> dropped either explicitly via fwnode_handle_put(child) in the OF path, or
> implicitly when the fwnode_for_each_child_node loop iterates or completes
> in the ACPI path:
>
> } else if (is_of_node(cp2112_fwnode)) {
> child = fwnode_get_named_child_node(cp2112_fwnode, "i2c");
> device_set_node(&dev->adap.dev, child);
> fwnode_handle_put(child);
> }
>
> device_set_node(&dev->adap.dev, child) assigns the pointer without taking
> its own reference, leaving dev->adap.dev.fwnode as a dangling pointer.
>
> This newly added i2c_parse_fw_timings() call dereferences this released
> fwnode via device_property_read_u32().
>
> Could this lead to a use-after-free?
>
> > + config.clock_speed = cpu_to_be32(timings.bus_freq_hz);
>
> [Severity: Medium]
> Since use_defaults is set to true, does this overwrite custom hardware I2C
> clock speeds with a 100kHz default for devices without firmware nodes?
>
> Before this patch, it looks like cp2112_probe() read the current SMBus
> configuration from the device, only modified retry_time, and wrote it back.
> This preserved the device's original configured clock speed (which might be
> set to 400kHz in the EEPROM).
>
> By calling i2c_parse_fw_timings() with an uninitialized local timings
> struct and use_defaults = true, timings.bus_freq_hz will be
> unconditionally set to 100kHz if the device lacks a firmware property.
>
> Is it intended to silently downgrade the speed and override user-configured
> EEPROM settings?
I think we should fix this:
i2c_parse_fw_timings(&dev->adap.dev, &timings, false);
if (timings.bus_freq_hz)
config.clock_speed = cpu_to_be32(timings.bus_freq_hz);
>
> [Severity: High]
> This is a pre-existing issue, but is there a missing cancellation of the
> delayed work in the probe error path?
This one would be nice to fix in a follow up patch.
>
> If sysfs_create_group() fails during probe, the code jumps to the
> err_gpiochip_remove label, which calls gpiochip_remove(&dev->gc) and
> returns:
>
> ret = sysfs_create_group(&hdev->dev.kobj, &cp2112_attr_group);
> if (ret < 0) {
> ...
> goto err_gpiochip_remove;
> }
> ...
> err_gpiochip_remove:
> gpiochip_remove(&dev->gc);
> err_free_i2c:
>
> Because gpiochip_add_data() was already called, an IRQ consumer could have
> concurrently requested a GPIO line, triggering cp2112_gpio_irq_startup()
> and queuing dev->gpio_poll_worker.
>
> Unlike cp2112_remove(), the error path lacks a call to
> cancel_delayed_work_sync(&dev->gpio_poll_worker).
>
> Could this mean the queued work will execute on freed memory?
>
> > config.retry_time = cpu_to_be16(1);
> >
> > ret = cp2112_hid_output(hdev, (u8 *)&config, sizeof(config),
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260520-cp2112-dt-v14-0-b1b4b6734b6f@plexus.com?part=2
>
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] Input: xilinx_ps2 - replace in_be32/out_be32 with ioread32be/iowrite32be
From: Rosen Penev @ 2026-06-02 8:27 UTC (permalink / raw)
To: Michal Simek
Cc: linux-input, Dmitry Torokhov, chleroy, open list,
moderated list:ARM/ZYNQ ARCHITECTURE
In-Reply-To: <79ccbd62-9aa3-41a6-a8db-1737672a8aab@amd.com>
On Mon, Jun 1, 2026 at 11:23 PM Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 6/2/26 05:59, Rosen Penev wrote:
> > Mechanical conversion of the ppc4xx-specific accessors to the generic
> > portable helpers.
> >
> > Allows enabling COMPILE_TEST for extra compile coverage.
> >
> > Assisted-by: opencode:big-pickle
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> > drivers/input/serio/Kconfig | 2 +-
> > drivers/input/serio/xilinx_ps2.c | 24 ++++++++++++------------
>
> I don't think that anybody is really using this driver and would be better to
> just remove it.
> If not, no issue with that changes.
I have no problem with removing.
>
> Thanks,
> Michal
^ permalink raw reply
* Re: [PATCH v2] HID: Input: Add battery list cleanup with devm action
From: Benjamin Tissoires @ 2026-06-02 8:30 UTC (permalink / raw)
To: linux-input, lcasmz54, Rafael Passos
Cc: hadess, jikos, linux-kernel, linux-pm, sre, kernel
In-Reply-To: <20260602030519.3097058-1-rafael@rcpassos.me>
On Tue, 02 Jun 2026 00:05:19 -0300, Rafael Passos wrote:
> The batteries list (hdev->batteries) is not cleaned up during
> hidinput_disconnect(), but struct hid_battery entries are allocated
> with devm_kzalloc.
> When a driver is unbound (e.g. during devicereprobe), devm frees those
> entries while their list_head nodesremain dangling in hdev->batteries,
> which persists across rebinds.
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-7.1/upstream-fixes), thanks!
[1/1] HID: Input: Add battery list cleanup with devm action
https://git.kernel.org/hid/hid/c/426e5846eba7
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH] Input: xilinx_ps2 - replace in_be32/out_be32 with ioread32be/iowrite32be
From: Michal Simek @ 2026-06-02 8:34 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-input, Dmitry Torokhov, chleroy, open list,
moderated list:ARM/ZYNQ ARCHITECTURE
In-Reply-To: <CAKxU2N-M+vDeDKtYa6=M-4kazOUrGTrwJfHoF6Z+od1OZ-VBpw@mail.gmail.com>
On 6/2/26 10:27, Rosen Penev wrote:
> On Mon, Jun 1, 2026 at 11:23 PM Michal Simek <michal.simek@amd.com> wrote:
>>
>>
>>
>> On 6/2/26 05:59, Rosen Penev wrote:
>>> Mechanical conversion of the ppc4xx-specific accessors to the generic
>>> portable helpers.
>>>
>>> Allows enabling COMPILE_TEST for extra compile coverage.
>>>
>>> Assisted-by: opencode:big-pickle
>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>> ---
>>> drivers/input/serio/Kconfig | 2 +-
>>> drivers/input/serio/xilinx_ps2.c | 24 ++++++++++++------------
>>
>> I don't think that anybody is really using this driver and would be better to
>> just remove it.
>> If not, no issue with that changes.
> I have no problem with removing.
Can you please send a patch for it?
Thanks,
Michal
^ permalink raw reply
* RE: [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume
From: Xu, Even @ 2026-06-02 8:47 UTC (permalink / raw)
To: d3z, Sun, Xinpeng, jikos@kernel.org, bentiss@kernel.org
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
abhishektamboli9@gmail.com, sakari.ailus@linux.intel.com
In-Reply-To: <20260601213047.115271-1-d3z.the.dev@gmail.com>
Hi, Danny,
Nice to meet you!
Thank you very much for your testing and description detail.
According to current situation you described on Surface Pro 10, there are two issues we need to identify separately:
1. Touch IC was powered off
According to your description, Touch IC power off can be confirmed.
In this case, only reset_tic() call is needed for touch IC recovery.
2. THC was power gated
THC power gated is another story, generally speaking, if device doesn't go into PM_SUSPEND_MEM, THC shouldn't be power gated. If so, other API calls to recovery THC state maybe unnecessary.
We need to identify this case.
So can you help do a test: just only add reset_tic(), to check if touch device can recovery during suspend/resume.
Then we can identify if THC was power gated.
Thanks!
Best Regards,
Even Xu
> -----Original Message-----
> From: d3z <d3z.the.dev@gmail.com>
> Sent: Tuesday, June 2, 2026 5:31 AM
> To: Xu, Even <even.xu@intel.com>; Sun, Xinpeng <xinpeng.sun@intel.com>;
> jikos@kernel.org; bentiss@kernel.org
> Cc: Danny D . <d3z.the.dev@gmail.com>; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; abhishektamboli9@gmail.com;
> sakari.ailus@linux.intel.com
> Subject: Re: [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system
> resume
>
> From: Danny D. <d3z.the.dev@gmail.com>
>
> Hi Even,
>
> Thanks for the quick reply and for sharing your patch.
>
> First, the missing piece from your mail: my name is Danny D.
> (d3z.the.dev@gmail.com) - please use it for any Signed-off-by/Reported-
> by/Tested-by.
>
> One note on the starting assumption, though: in its current configuration this
> Surface Pro 10 doesn't go to S3 at all. /sys/power/mem_sleep only offers s2idle:
>
> $ cat /sys/power/mem_sleep
> [s2idle]
>
> There's no "deep" entry to select here, so every suspend goes through s2idle and
> never reaches PM_SUSPEND_MEM. The touch IC still loses power across that
> s2idle suspend - the same as over hibernation - which is what gives the "recv
> failed: -11" on resume.
>
> That's the catch with the attached patch: it gates the THC reconfigure on
>
> if (last_suspend_state == PM_SUSPEND_MEM)
>
> i.e. S3 only. On this machine that branch never runs, so it wouldn't bring the
> touchscreen back here. Happy to apply it and confirm on the device, but from the
> code path alone it can't help while we're s2idle-only.
>
> What I did instead was key off whether the device actually kept power rather
> than the suspend type: run the full reset only when the device isn't a wake source
> (device_may_wakeup() == false), mirroring quickspi_restore().
> A wake-enabled device stays on the light path so wake-on-touch is preserved;
> one that lost power goes through reset_tic() re-enumeration. That fires on both
> s2idle and S3, which is what makes it work on the SP10.
>
> I've tested this on the Surface Pro 10 across many s2idle suspend/resume cycles -
> touch and pen both keep working - and just posted a v2 that adds the
> device_may_wakeup() gate.
>
> Could we converge on the wakeup-based condition? I'm glad to test any revision
> of your patch on the hardware, and equally glad for you to carry the fix with my
> Signed-off-by/Tested-by once it handles the s2idle case.
>
> Thanks,
> Danny
^ permalink raw reply
* Re: [PATCH] Input: xilinx_ps2 - replace in_be32/out_be32 with ioread32be/iowrite32be
From: Rosen Penev @ 2026-06-02 8:51 UTC (permalink / raw)
To: Michal Simek
Cc: linux-input, Dmitry Torokhov, chleroy, open list,
moderated list:ARM/ZYNQ ARCHITECTURE
In-Reply-To: <b9e06f81-2b18-4cc3-8974-6df9063b02cf@amd.com>
On Tue, Jun 2, 2026 at 1:34 AM Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 6/2/26 10:27, Rosen Penev wrote:
> > On Mon, Jun 1, 2026 at 11:23 PM Michal Simek <michal.simek@amd.com> wrote:
> >>
> >>
> >>
> >> On 6/2/26 05:59, Rosen Penev wrote:
> >>> Mechanical conversion of the ppc4xx-specific accessors to the generic
> >>> portable helpers.
> >>>
> >>> Allows enabling COMPILE_TEST for extra compile coverage.
> >>>
> >>> Assisted-by: opencode:big-pickle
> >>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> >>> ---
> >>> drivers/input/serio/Kconfig | 2 +-
> >>> drivers/input/serio/xilinx_ps2.c | 24 ++++++++++++------------
> >>
> >> I don't think that anybody is really using this driver and would be better to
> >> just remove it.
> >> If not, no issue with that changes.
> > I have no problem with removing.
>
> Can you please send a patch for it?
Out of curiosity, I made a deep research AI prompt. Last known user it
gave me was from 2012. Github code search however gave me a user from
5 or 6 years ago.
https://github.com/danielkasza/9444/blob/master/firmware/xilinx-fpga/genesys2.dts
Maybe someone knows more.
>
> Thanks,
> Michal
^ permalink raw reply
* [PATCH] Input: axp20x-pek - add support for AXP313A variant
From: steven @ 2026-06-02 9:55 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Chen-Yu Tsai, linux-input, linux-kernel, Steven Feng
From: Steven Feng <steven@joint-cloud.com>
Add power button support for the AXP313A PMIC. The AXP313A uses
the same register layout and timing parameters as the AXP20X,
so we can reuse the existing axp20x_info structure.
Signed-off-by: Steven Feng <steven@joint-cloud.com>
---
drivers/input/misc/axp20x-pek.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
index 24f9e9d893de..d4e2fc9a937f 100644
--- a/drivers/input/misc/axp20x-pek.c
+++ b/drivers/input/misc/axp20x-pek.c
@@ -393,6 +393,10 @@ static const struct platform_device_id axp_pek_id_match[] = {
.name = "axp221-pek",
.driver_data = (kernel_ulong_t)&axp221_info,
},
+ {
+ .name = "axp313a-pek",
+ .driver_data = (kernel_ulong_t)&axp20x_info,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(platform, axp_pek_id_match);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] Input: axp20x-pek - add support for AXP313A variant
From: sashiko-bot @ 2026-06-02 10:10 UTC (permalink / raw)
To: steven; +Cc: dmitry.torokhov, linux-input
In-Reply-To: <tencent_5F1FF80489E702360F352F889570656BF608@qq.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] Sysfs attributes 'startup' and 'shutdown' are unconditionally broken for the newly added AXP313A device due to out-of-bounds regmap access.
Pre-existing issues:
- [High] Unconditional manipulation of uninitialized IRQ 0 during system suspend and resume when input device registration is bypassed.
--
commit 689d64caa4b9f21a0926e40a611d5111bfe37d22
Author: Steven Feng <steven@joint-cloud.com>
Input: axp20x-pek - add support for AXP313A variant
This commit adds power button support for the AXP313A PMIC. It reuses the
existing axp20x_info structure, noting that the AXP313A shares the same
register layout and timing parameters as the AXP20X.
> diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
> index 24f9e9d893de3..d4e2fc9a937ff 100644
> --- a/drivers/input/misc/axp20x-pek.c
> +++ b/drivers/input/misc/axp20x-pek.c
> @@ -393,6 +393,10 @@ static const struct platform_device_id axp_pek_id_match[] = {
> .name = "axp221-pek",
> .driver_data = (kernel_ulong_t)&axp221_info,
> },
> + {
> + .name = "axp313a-pek",
> + .driver_data = (kernel_ulong_t)&axp20x_info,
[Severity: Medium]
Will reusing axp20x_info for the AXP313A break the sysfs attributes?
The axp20x_info struct exposes the startup and shutdown sysfs attributes.
When these are accessed, the driver reads or updates AXP20X_PEK_KEY (0x36):
drivers/input/misc/axp20x-pek.c:axp20x_show_attr() {
...
ret = regmap_read(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY, &val);
...
}
However, the AXP313A regmap configuration restricts max_register to 0x21
(AXP313A_IRQ_STATE). Won't the regmap core reject accesses to 0x36 with
-EINVAL, making these sysfs attributes non-functional for this device?
> + },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(platform, axp_pek_id_match);
[Severity: High]
This is a pre-existing issue, but could the suspend and resume handlers crash
the system if input device registration is skipped?
In axp20x_pek_suspend() and axp20x_pek_resume(), the driver unconditionally
calls disable_irq() and enable_irq():
drivers/input/misc/axp20x-pek.c:axp20x_pek_suspend() {
...
if (device_may_wakeup(dev)) {
...
} else {
disable_irq(axp20x_pek->irq_dbf);
disable_irq(axp20x_pek->irq_dbr);
}
...
}
If axp20x_pek_should_register_input() returns false (for instance, on x86
systems where ACPI handles the power button), the IRQs are never initialized
and remain 0.
Does calling disable_irq(0) disable the system timer interrupt on x86,
potentially causing a system hang or panic during the suspend cycle?
--
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_5F1FF80489E702360F352F889570656BF608@qq.com?part=1
^ permalink raw reply
* [REGRESSION] RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
From: Tj @ 2026-06-02 10:24 UTC (permalink / raw)
To: regressions; +Cc: linux-input, linux-kernel, linux-bluetooth
Hitting this repeatedly with v7.1-rc6. Do not have time right now to
bisect it (and there are two other regressions at the same time).
Symptom is unable to use the Bluetooth keyboard.
It *seems* to be related to the Bluetooth keyboard - trying to shutdown
hangs for 6 minutes whilst systemd tries to kill bluetooth.service but fails
and then fails to power-off (see end of log extracts).
I'm not sure why I see 'samsung_probe' in the call trace since neither the Bluetooth host
adapter nor the keyboard are Samsung but maybe some change related to
that is causing this.
Jun 02 09:25:54 sunny kernel: BUG: unable to handle page fault for address: ffffffffffffffe4
Jun 02 09:25:54 sunny kernel: #PF: supervisor read access in kernel mode
Jun 02 09:25:54 sunny kernel: #PF: error_code(0x0000) - not-present page
Jun 02 09:25:54 sunny kernel: Oops: Oops: 0000 [#1] SMP NOPTI
Jun 02 09:25:54 sunny kernel: CPU: 11 UID: 0 PID: 4009 Comm: (udev-worker) Tainted: G W OE 7.1.0-rc6+debian+tj #446 PREEMPT(lazy)
Jun 02 09:25:54 sunny kernel: Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Jun 02 09:25:54 sunny kernel: Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 6254 01/05/2026
Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
Jun 02 09:25:54 sunny kernel: Call Trace:
Jun 02 09:25:54 sunny kernel: <TASK>
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? dev_set_name+0x5c/0x80
Jun 02 09:25:54 sunny kernel: hidinput_connect+0x935/0x5fb0 [hid]
Jun 02 09:25:54 sunny kernel: hid_connect+0x3d5/0x6a0 [hid]
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? __wake_up_common+0x78/0xa0
Jun 02 09:25:54 sunny kernel: hid_hw_start+0x40/0x70 [hid]
Jun 02 09:25:54 sunny kernel: samsung_probe+0x31/0x70 [hid_samsung]
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: hid_device_probe+0x18d/0x220 [hid]
Jun 02 09:25:54 sunny kernel: ? __pfx___device_attach_driver+0x10/0x10
Jun 02 09:25:54 sunny kernel: really_probe+0xde/0x380
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: __driver_probe_device+0x84/0x150
Jun 02 09:25:54 sunny kernel: driver_probe_device+0x1f/0xa0
Jun 02 09:25:54 sunny kernel: __device_attach_driver+0x89/0x130
Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
Jun 02 09:25:54 sunny kernel: __device_attach+0xaf/0x1c0
Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_reprobe_drivers+0x10/0x10 [hid]
Jun 02 09:25:54 sunny kernel: device_reprobe+0x4e/0x90
Jun 02 09:25:54 sunny kernel: ? __hid_bus_reprobe_drivers+0x3c/0x60 [hid]
Jun 02 09:25:54 sunny kernel: bus_for_each_dev+0x8e/0xe0
Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_driver_added+0x10/0x10 [hid]
Jun 02 09:25:54 sunny kernel: __hid_bus_driver_added+0x2f/0x40 [hid]
Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
Jun 02 09:25:54 sunny kernel: __hid_register_driver+0x74/0x80 [hid]
Jun 02 09:25:54 sunny kernel: ? __pfx_samsung_driver_init+0x10/0x10 [hid_samsung]
Jun 02 09:25:54 sunny kernel: do_one_initcall+0x5c/0x320
Jun 02 09:25:54 sunny kernel: do_init_module+0x60/0x250
Jun 02 09:25:54 sunny kernel: init_module_from_file+0xd6/0x130
Jun 02 09:25:54 sunny kernel: idempotent_init_module+0x114/0x310
Jun 02 09:25:54 sunny kernel: __x64_sys_finit_module+0x71/0xe0
Jun 02 09:25:54 sunny kernel: do_syscall_64+0xea/0x640
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? do_fault+0x341/0x530
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? __handle_mm_fault+0x977/0xf80
Jun 02 09:25:54 sunny kernel: ? __memcg_slab_free_hook+0x16d/0x1c0
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? count_memcg_events+0xe5/0x1b0
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? __seccomp_filter+0x42/0x5d0
Jun 02 09:25:54 sunny kernel: ? handle_mm_fault+0x1e2/0x2e0
Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
Jun 02 09:25:54 sunny kernel: ? do_syscall_64+0x9f/0x640
Jun 02 09:25:54 sunny kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
Jun 02 09:25:54 sunny kernel: RIP: 0033:0x7f6ee111a7b9
Jun 02 09:25:54 sunny kernel: Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48>
Jun 02 09:25:54 sunny kernel: RSP: 002b:00007ffe6dd96398 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffda RBX: 0000556830869b90 RCX: 00007f6ee111a7b9
Jun 02 09:25:54 sunny kernel: RDX: 0000000000000004 RSI: 00007f6ee16ed44d RDI: 0000000000000012
Jun 02 09:25:54 sunny kernel: RBP: 0000000000000004 R08: 0000000000000000 R09: 0000556830667bd0
Jun 02 09:25:54 sunny kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6ee16ed44d
Jun 02 09:25:54 sunny kernel: R13: 0000000000020000 R14: 00005568307db670 R15: 0000000000000000
Jun 02 09:25:54 sunny kernel: </TASK>
Jun 02 09:25:54 sunny kernel: Modules linked in: hid_samsung(+) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput rpcsec_gss_krb5 nfsv4 dns_resolver nfs netfs rdma_ucm ib_uverbs rdma_cm i>
Jun 02 09:25:54 sunny kernel: uvcvideo wmi_bmof watchdog snd_timer igb rfkill uas mii pcspkr mxm_wmi videobuf2_vmalloc snd ccp k10temp uvc i2c_piix4 dca videobuf2_memops soundcore videobuf2_v4>
Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4
Jun 02 09:25:54 sunny kernel: ---[ end trace 0000000000000000 ]---
Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
Jun 02 09:25:54 sunny systemd-udevd[1703]: 0005:04E8:7021.0006: Worker [4009] terminated by signal 9 (KILL).
Jun 02 09:29:16 sunny rpc.idmapd[3093]: exiting on signal 15
Jun 02 09:30:45 sunny systemd[1]: bluetooth.service: State 'stop-sigterm' timed out. Killing.
Jun 02 09:32:15 sunny systemd[1]: bluetooth.service: Processes still around after SIGKILL. Ignoring.
Jun 02 09:33:45 sunny systemd[1]: bluetooth.service: State 'final-sigterm' timed out. Killing.
Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Processes still around after final SIGKILL. Entering failed mode.
Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Failed with result 'timeout'.
^ permalink raw reply
* Re: [REGRESSION] RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
From: Thorsten Leemhuis @ 2026-06-02 10:54 UTC (permalink / raw)
To: Tj, regressions; +Cc: linux-input, linux-kernel, linux-bluetooth, Rafael Passos
In-Reply-To: <ah6vRH9J9LSvnKWW@mail.iam.tj>
On 6/2/26 12:24, Tj wrote:
> Hitting this repeatedly with v7.1-rc6. Do not have time right now to
> bisect it (and there are two other regressions at the same time).
Again, not my area of expertise, but this looks somewhat similar (but
also somewhat different!) to this recent regression report from Rafael:
https://lore.kernel.org/all/20260602011949.2825852-1-rafael@rcpassos.me/
Rafael (CCed) sent a fix for it already applied:
HID: Input: Add battery list cleanup with devm action
https://lore.kernel.org/all/20260602030519.3097058-1-rafael@rcpassos.me/
Might be worth trying.
Ciao, Thorsten
> Symptom is unable to use the Bluetooth keyboard.
>
> It *seems* to be related to the Bluetooth keyboard - trying to shutdown
> hangs for 6 minutes whilst systemd tries to kill bluetooth.service but fails
> and then fails to power-off (see end of log extracts).
>
> I'm not sure why I see 'samsung_probe' in the call trace since neither the Bluetooth host
> adapter nor the keyboard are Samsung but maybe some change related to
> that is causing this.
>
> Jun 02 09:25:54 sunny kernel: BUG: unable to handle page fault for address: ffffffffffffffe4
> Jun 02 09:25:54 sunny kernel: #PF: supervisor read access in kernel mode
> Jun 02 09:25:54 sunny kernel: #PF: error_code(0x0000) - not-present page
> Jun 02 09:25:54 sunny kernel: Oops: Oops: 0000 [#1] SMP NOPTI
> Jun 02 09:25:54 sunny kernel: CPU: 11 UID: 0 PID: 4009 Comm: (udev-worker) Tainted: G W OE 7.1.0-rc6+debian+tj #446 PREEMPT(lazy)
> Jun 02 09:25:54 sunny kernel: Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
> Jun 02 09:25:54 sunny kernel: Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 6254 01/05/2026
> Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
> Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
> Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
> Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
> Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
> Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
> Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
> Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
> Jun 02 09:25:54 sunny kernel: Call Trace:
> Jun 02 09:25:54 sunny kernel: <TASK>
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? dev_set_name+0x5c/0x80
> Jun 02 09:25:54 sunny kernel: hidinput_connect+0x935/0x5fb0 [hid]
> Jun 02 09:25:54 sunny kernel: hid_connect+0x3d5/0x6a0 [hid]
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? __wake_up_common+0x78/0xa0
> Jun 02 09:25:54 sunny kernel: hid_hw_start+0x40/0x70 [hid]
> Jun 02 09:25:54 sunny kernel: samsung_probe+0x31/0x70 [hid_samsung]
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: hid_device_probe+0x18d/0x220 [hid]
> Jun 02 09:25:54 sunny kernel: ? __pfx___device_attach_driver+0x10/0x10
> Jun 02 09:25:54 sunny kernel: really_probe+0xde/0x380
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: __driver_probe_device+0x84/0x150
> Jun 02 09:25:54 sunny kernel: driver_probe_device+0x1f/0xa0
> Jun 02 09:25:54 sunny kernel: __device_attach_driver+0x89/0x130
> Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
> Jun 02 09:25:54 sunny kernel: __device_attach+0xaf/0x1c0
> Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_reprobe_drivers+0x10/0x10 [hid]
> Jun 02 09:25:54 sunny kernel: device_reprobe+0x4e/0x90
> Jun 02 09:25:54 sunny kernel: ? __hid_bus_reprobe_drivers+0x3c/0x60 [hid]
> Jun 02 09:25:54 sunny kernel: bus_for_each_dev+0x8e/0xe0
> Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_driver_added+0x10/0x10 [hid]
> Jun 02 09:25:54 sunny kernel: __hid_bus_driver_added+0x2f/0x40 [hid]
> Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
> Jun 02 09:25:54 sunny kernel: __hid_register_driver+0x74/0x80 [hid]
> Jun 02 09:25:54 sunny kernel: ? __pfx_samsung_driver_init+0x10/0x10 [hid_samsung]
> Jun 02 09:25:54 sunny kernel: do_one_initcall+0x5c/0x320
> Jun 02 09:25:54 sunny kernel: do_init_module+0x60/0x250
> Jun 02 09:25:54 sunny kernel: init_module_from_file+0xd6/0x130
> Jun 02 09:25:54 sunny kernel: idempotent_init_module+0x114/0x310
> Jun 02 09:25:54 sunny kernel: __x64_sys_finit_module+0x71/0xe0
> Jun 02 09:25:54 sunny kernel: do_syscall_64+0xea/0x640
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? do_fault+0x341/0x530
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? __handle_mm_fault+0x977/0xf80
> Jun 02 09:25:54 sunny kernel: ? __memcg_slab_free_hook+0x16d/0x1c0
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? count_memcg_events+0xe5/0x1b0
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? __seccomp_filter+0x42/0x5d0
> Jun 02 09:25:54 sunny kernel: ? handle_mm_fault+0x1e2/0x2e0
> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
> Jun 02 09:25:54 sunny kernel: ? do_syscall_64+0x9f/0x640
> Jun 02 09:25:54 sunny kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Jun 02 09:25:54 sunny kernel: RIP: 0033:0x7f6ee111a7b9
> Jun 02 09:25:54 sunny kernel: Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48>
> Jun 02 09:25:54 sunny kernel: RSP: 002b:00007ffe6dd96398 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffda RBX: 0000556830869b90 RCX: 00007f6ee111a7b9
> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000004 RSI: 00007f6ee16ed44d RDI: 0000000000000012
> Jun 02 09:25:54 sunny kernel: RBP: 0000000000000004 R08: 0000000000000000 R09: 0000556830667bd0
> Jun 02 09:25:54 sunny kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6ee16ed44d
> Jun 02 09:25:54 sunny kernel: R13: 0000000000020000 R14: 00005568307db670 R15: 0000000000000000
> Jun 02 09:25:54 sunny kernel: </TASK>
> Jun 02 09:25:54 sunny kernel: Modules linked in: hid_samsung(+) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput rpcsec_gss_krb5 nfsv4 dns_resolver nfs netfs rdma_ucm ib_uverbs rdma_cm i>
> Jun 02 09:25:54 sunny kernel: uvcvideo wmi_bmof watchdog snd_timer igb rfkill uas mii pcspkr mxm_wmi videobuf2_vmalloc snd ccp k10temp uvc i2c_piix4 dca videobuf2_memops soundcore videobuf2_v4>
> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4
> Jun 02 09:25:54 sunny kernel: ---[ end trace 0000000000000000 ]---
> Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
> Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
> Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
> Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
> Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
> Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
> Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
> Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
> Jun 02 09:25:54 sunny systemd-udevd[1703]: 0005:04E8:7021.0006: Worker [4009] terminated by signal 9 (KILL).
>
> Jun 02 09:29:16 sunny rpc.idmapd[3093]: exiting on signal 15
> Jun 02 09:30:45 sunny systemd[1]: bluetooth.service: State 'stop-sigterm' timed out. Killing.
> Jun 02 09:32:15 sunny systemd[1]: bluetooth.service: Processes still around after SIGKILL. Ignoring.
> Jun 02 09:33:45 sunny systemd[1]: bluetooth.service: State 'final-sigterm' timed out. Killing.
> Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Processes still around after final SIGKILL. Entering failed mode.
> Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Failed with result 'timeout'.
>
>
^ permalink raw reply
* Re: [REGRESSION] RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
From: Tj @ 2026-06-02 11:07 UTC (permalink / raw)
To: Thorsten Leemhuis, regressions
Cc: linux-input, linux-kernel, linux-bluetooth, Rafael Passos
In-Reply-To: <b84a408c-b12c-40e5-b44b-62aa072cb285@leemhuis.info>
Thanks once again! That does look likely. Added this and the amdgpu
patch and doing a build now. Will report back for both if any progress,
On 02/06/2026 10:54, Thorsten Leemhuis wrote:
> On 6/2/26 12:24, Tj wrote:
>> Hitting this repeatedly with v7.1-rc6. Do not have time right now to
>> bisect it (and there are two other regressions at the same time).
> Again, not my area of expertise, but this looks somewhat similar (but
> also somewhat different!) to this recent regression report from Rafael:
> https://lore.kernel.org/all/20260602011949.2825852-1-rafael@rcpassos.me/
>
> Rafael (CCed) sent a fix for it already applied:
> HID: Input: Add battery list cleanup with devm action
> https://lore.kernel.org/all/20260602030519.3097058-1-rafael@rcpassos.me/
>
> Might be worth trying.
>
> Ciao, Thorsten
>
>> Symptom is unable to use the Bluetooth keyboard.
>>
>> It *seems* to be related to the Bluetooth keyboard - trying to shutdown
>> hangs for 6 minutes whilst systemd tries to kill bluetooth.service but fails
>> and then fails to power-off (see end of log extracts).
>>
>> I'm not sure why I see 'samsung_probe' in the call trace since neither the Bluetooth host
>> adapter nor the keyboard are Samsung but maybe some change related to
>> that is causing this.
>>
>> Jun 02 09:25:54 sunny kernel: BUG: unable to handle page fault for address: ffffffffffffffe4
>> Jun 02 09:25:54 sunny kernel: #PF: supervisor read access in kernel mode
>> Jun 02 09:25:54 sunny kernel: #PF: error_code(0x0000) - not-present page
>> Jun 02 09:25:54 sunny kernel: Oops: Oops: 0000 [#1] SMP NOPTI
>> Jun 02 09:25:54 sunny kernel: CPU: 11 UID: 0 PID: 4009 Comm: (udev-worker) Tainted: G W OE 7.1.0-rc6+debian+tj #446 PREEMPT(lazy)
>> Jun 02 09:25:54 sunny kernel: Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
>> Jun 02 09:25:54 sunny kernel: Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 6254 01/05/2026
>> Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
>> Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
>> Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
>> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
>> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
>> Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
>> Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
>> Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
>> Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
>> Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
>> Jun 02 09:25:54 sunny kernel: Call Trace:
>> Jun 02 09:25:54 sunny kernel: <TASK>
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? dev_set_name+0x5c/0x80
>> Jun 02 09:25:54 sunny kernel: hidinput_connect+0x935/0x5fb0 [hid]
>> Jun 02 09:25:54 sunny kernel: hid_connect+0x3d5/0x6a0 [hid]
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? __wake_up_common+0x78/0xa0
>> Jun 02 09:25:54 sunny kernel: hid_hw_start+0x40/0x70 [hid]
>> Jun 02 09:25:54 sunny kernel: samsung_probe+0x31/0x70 [hid_samsung]
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: hid_device_probe+0x18d/0x220 [hid]
>> Jun 02 09:25:54 sunny kernel: ? __pfx___device_attach_driver+0x10/0x10
>> Jun 02 09:25:54 sunny kernel: really_probe+0xde/0x380
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: __driver_probe_device+0x84/0x150
>> Jun 02 09:25:54 sunny kernel: driver_probe_device+0x1f/0xa0
>> Jun 02 09:25:54 sunny kernel: __device_attach_driver+0x89/0x130
>> Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
>> Jun 02 09:25:54 sunny kernel: __device_attach+0xaf/0x1c0
>> Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_reprobe_drivers+0x10/0x10 [hid]
>> Jun 02 09:25:54 sunny kernel: device_reprobe+0x4e/0x90
>> Jun 02 09:25:54 sunny kernel: ? __hid_bus_reprobe_drivers+0x3c/0x60 [hid]
>> Jun 02 09:25:54 sunny kernel: bus_for_each_dev+0x8e/0xe0
>> Jun 02 09:25:54 sunny kernel: ? __pfx___hid_bus_driver_added+0x10/0x10 [hid]
>> Jun 02 09:25:54 sunny kernel: __hid_bus_driver_added+0x2f/0x40 [hid]
>> Jun 02 09:25:54 sunny kernel: bus_for_each_drv+0x97/0xf0
>> Jun 02 09:25:54 sunny kernel: __hid_register_driver+0x74/0x80 [hid]
>> Jun 02 09:25:54 sunny kernel: ? __pfx_samsung_driver_init+0x10/0x10 [hid_samsung]
>> Jun 02 09:25:54 sunny kernel: do_one_initcall+0x5c/0x320
>> Jun 02 09:25:54 sunny kernel: do_init_module+0x60/0x250
>> Jun 02 09:25:54 sunny kernel: init_module_from_file+0xd6/0x130
>> Jun 02 09:25:54 sunny kernel: idempotent_init_module+0x114/0x310
>> Jun 02 09:25:54 sunny kernel: __x64_sys_finit_module+0x71/0xe0
>> Jun 02 09:25:54 sunny kernel: do_syscall_64+0xea/0x640
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? do_fault+0x341/0x530
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? __handle_mm_fault+0x977/0xf80
>> Jun 02 09:25:54 sunny kernel: ? __memcg_slab_free_hook+0x16d/0x1c0
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? count_memcg_events+0xe5/0x1b0
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? __seccomp_filter+0x42/0x5d0
>> Jun 02 09:25:54 sunny kernel: ? handle_mm_fault+0x1e2/0x2e0
>> Jun 02 09:25:54 sunny kernel: ? srso_return_thunk+0x5/0x5f
>> Jun 02 09:25:54 sunny kernel: ? do_syscall_64+0x9f/0x640
>> Jun 02 09:25:54 sunny kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>
>> Jun 02 09:25:54 sunny kernel: RIP: 0033:0x7f6ee111a7b9
>> Jun 02 09:25:54 sunny kernel: Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48>
>> Jun 02 09:25:54 sunny kernel: RSP: 002b:00007ffe6dd96398 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
>> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffda RBX: 0000556830869b90 RCX: 00007f6ee111a7b9
>> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000004 RSI: 00007f6ee16ed44d RDI: 0000000000000012
>> Jun 02 09:25:54 sunny kernel: RBP: 0000000000000004 R08: 0000000000000000 R09: 0000556830667bd0
>> Jun 02 09:25:54 sunny kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6ee16ed44d
>> Jun 02 09:25:54 sunny kernel: R13: 0000000000020000 R14: 00005568307db670 R15: 0000000000000000
>> Jun 02 09:25:54 sunny kernel: </TASK>
>> Jun 02 09:25:54 sunny kernel: Modules linked in: hid_samsung(+) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput rpcsec_gss_krb5 nfsv4 dns_resolver nfs netfs rdma_ucm ib_uverbs rdma_cm i>
>> Jun 02 09:25:54 sunny kernel: uvcvideo wmi_bmof watchdog snd_timer igb rfkill uas mii pcspkr mxm_wmi videobuf2_vmalloc snd ccp k10temp uvc i2c_piix4 dca videobuf2_memops soundcore videobuf2_v4>
>> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4
>> Jun 02 09:25:54 sunny kernel: ---[ end trace 0000000000000000 ]---
>> Jun 02 09:25:54 sunny kernel: RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
>> Jun 02 09:25:54 sunny kernel: Code: 48 ab 48 8b 42 68 48 8b 95 18 1c 00 00 8b 48 30 48 39 d3 74 45 48 8d 42 c8 eb 0f 66 90 48 8b 50 38 48 8d 42 c8 48 39 d3 74 30 <3b> 48 1c 75 ee 48 85 c0 74 26>
>> Jun 02 09:25:54 sunny kernel: RSP: 0018:ffffceacce2c7628 EFLAGS: 00010286
>> Jun 02 09:25:54 sunny kernel: RAX: ffffffffffffffc8 RBX: ffff8b4856a83c18 RCX: 0000000000000003
>> Jun 02 09:25:54 sunny kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffceacce2c7680
>> Jun 02 09:25:54 sunny kernel: RBP: ffff8b4856a82000 R08: ffffceacce2c7730 R09: ffffceacce2c772c
>> Jun 02 09:25:54 sunny kernel: R10: ffff8b488f290488 R11: ffff8b478bec9000 R12: ffffceacce2c7650
>> Jun 02 09:25:54 sunny kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff8b47e6307b00
>> Jun 02 09:25:54 sunny kernel: FS: 00007f6ee16439c0(0000) GS:ffff8b4ed8fd0000(0000) knlGS:0000000000000000
>> Jun 02 09:25:54 sunny kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> Jun 02 09:25:54 sunny kernel: CR2: ffffffffffffffe4 CR3: 000000010b1c1000 CR4: 0000000000350ef0
>> Jun 02 09:25:54 sunny systemd-udevd[1703]: 0005:04E8:7021.0006: Worker [4009] terminated by signal 9 (KILL).
>>
>> Jun 02 09:29:16 sunny rpc.idmapd[3093]: exiting on signal 15
>> Jun 02 09:30:45 sunny systemd[1]: bluetooth.service: State 'stop-sigterm' timed out. Killing.
>> Jun 02 09:32:15 sunny systemd[1]: bluetooth.service: Processes still around after SIGKILL. Ignoring.
>> Jun 02 09:33:45 sunny systemd[1]: bluetooth.service: State 'final-sigterm' timed out. Killing.
>> Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Processes still around after final SIGKILL. Entering failed mode.
>> Jun 02 09:35:15 sunny systemd[1]: bluetooth.service: Failed with result 'timeout'.
>>
>>
^ permalink raw reply
* Re: [REGRESSION] RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
From: Tj @ 2026-06-02 11:25 UTC (permalink / raw)
To: Thorsten Leemhuis, regressions
Cc: linux-input, linux-kernel, linux-bluetooth, Rafael Passos
In-Reply-To: <b84a408c-b12c-40e5-b44b-62aa072cb285@leemhuis.info>
v7.1-rc6 + "HID: Input: Add battery list cleanup with devm action"
confirmed fixes the hidinput/bluetooth issues. Thank-you.
On 02/06/2026 10:54, Thorsten Leemhuis wrote:
> On 6/2/26 12:24, Tj wrote:
>> Hitting this repeatedly with v7.1-rc6. Do not have time right now to
>> bisect it (and there are two other regressions at the same time).
> Again, not my area of expertise, but this looks somewhat similar (but
> also somewhat different!) to this recent regression report from Rafael:
> https://lore.kernel.org/all/20260602011949.2825852-1-rafael@rcpassos.me/
>
> Rafael (CCed) sent a fix for it already applied:
> HID: Input: Add battery list cleanup with devm action
> https://lore.kernel.org/all/20260602030519.3097058-1-rafael@rcpassos.me/
^ permalink raw reply
* Re: [REGRESSION] RIP: 0010:hidinput_setup_battery.isra.0+0x6d/0x370 [hid]
From: Rafael Passos @ 2026-06-02 12:39 UTC (permalink / raw)
To: regressions; +Cc: linux-input, linux-kernel, linux-bluetooth, Rafael Passos
In-Reply-To: <b84a408c-b12c-40e5-b44b-62aa072cb285@leemhuis.info>
I'm really happy it helped!
Cheers!
Rafael Passos,
Software Engineer
São Paulo, Brasil
^ permalink raw reply
* Re: [PATCH 00/11] HID: storing pointers in 'hid_device_id::driver_data'
From: Pawel Zalewski @ 2026-06-02 13:57 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Ping Cheng, Jason Gerecke, linux-kernel, linux-input,
Christian A. Ehrhardt, Christian A. Ehrhardt
In-Reply-To: <ahhjTbG0Ye-mP9WY@beelink>
> Agree, we need both.
Great, I will implement this in v2.
> I'd drop patches 1-4. I don't see the point of just rewriting the list
> of hid_device_id if we ensure we have just one type.
These patches really just enforce the use of a named initializer for
the `driver_data` field
in the lists and do not change the actual compiled binary. So, the
change applied is purely
cosmetic, and the modules touched there don't use `driver_data` as a
pointer anyway.
I do think that making the code more readable has merit (if it comes
with no risk).
> I need to have a closer look at 5-8 TBH.
Thanks.
^ permalink raw reply
* Re: [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume
From: d3z @ 2026-06-02 15:13 UTC (permalink / raw)
To: even.xu, xinpeng.sun, jikos, bentiss
Cc: Danny D ., linux-input, linux-kernel, abhishektamboli9,
sakari.ailus
In-Reply-To: <IA1PR11MB60985A7B3D9EA4583C2DDBF7F4122@IA1PR11MB6098.namprd11.prod.outlook.com>
From: Danny D. <d3z.the.dev@gmail.com>
Hi Even,
Good way to split it - "touch IC off" vs "THC power-gated" - so I ran the
reset_tic()-only test you asked for.
I added just reset_tic() to a pristine quickspi_resume(), with none of the
THC reconfig (no thc_spi_*_config, no thc_ltr_*). On the Surface Pro 10,
after an s2idle suspend/resume, the touchscreen does NOT come back - so
reset_tic() alone isn't enough here.
The interesting bit is why. The one new line on resume is:
intel_quickspi 0000:00:10.0: THC interrupt already unquiesce
That's reset_tic() -> thc_interrupt_quiesce(dev, false) finding
DEVINT_QUIESCE_EN already clear - even though quickspi_suspend() set it in
suspend. thc_regmap is REGCACHE_NONE, so that's the real register, not a
cached value. So the THC port-control state we wrote in suspend is gone
after resume.
That's your second case: the THC itself loses its register context across
s2idle, without ever hitting PM_SUSPEND_MEM. reset_tic()'s SPI exchange
then runs against a THC whose I/O address and read/write config are wiped,
so the reset never completes. Reprogramming those first (like
quickspi_restore(), and like v2 on the no-wake path) is what brings touch
and pen back.
So on the SP10 both are needed - reset the touch IC AND reconfigure the
THC - the full reconfigure looks necessary here.
One note on the log: there's no fresh "Wait RESET_RESPONSE timeout" line
this cycle, but that path is dev_err_once() and the box had ~12h uptime, so
an earlier cycle likely already consumed it.
Thanks,
Danny
^ 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