* 答复: [External Mail]Re: [PATCH] HID: hid-input: only ignore 0 battery events for digitizers
From: 卢国宏 @ 2025-10-15 7:48 UTC (permalink / raw)
To: Dmitry Torokhov, Jiri Kosina
Cc: Benjamin Tissoires, kenalba@google.com,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
李鹏, 卢国宏
In-Reply-To: <nsz6llo4nsg4zuiogmewuccl76nzjjijgkjzqeazzs33lj4phc@k5rskuabbsz2>
[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]
Hi Jiri,
The last time I verified Dmitry's patch, it was based on the latest Linux code. The patch at that time is attached as "Patch reporting HID device zero battery.jpg". As I understand it, you can submit Dmitry's V2 patch directly to the kernel without retesting.
Thanks.
--
guohong
________________________________________
发件人: Dmitry Torokhov <dmitry.torokhov@gmail.com>
发送时间: 2025年10月15日 12:31:10
收件人: Jiri Kosina
抄送: Benjamin Tissoires; 卢国宏; kenalba@google.com; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
主题: [External Mail]Re: [PATCH] HID: hid-input: only ignore 0 battery events for digitizers
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给misec@xiaomi.com进行反馈
Hi Jiri,
On Tue, Oct 14, 2025 at 12:25:25PM +0200, Jiri Kosina wrote:
>
> Hi Dmitry,
>
> thanks for the fix. It doesn't apply cleanly on a reasonably recent tree
> though, as since e94536e1d1818b09 we're already propagating usage to
> hidinput_update_battery(), and we're issuing explicit call to
> power_supply_changed() as well.
>
> Could you please refresh on a more recent codebase and resubmit? I could
> do that myself, but I guess you also have a way to test the patch with
> your use-case ... ?
Sorry about that, I made the patch on top of my tree which lags behind.
I just sent a v2 rebased on top of linux-next.
I actually do not have the hardware to test, we have to rely on 卢国宏
to do it for us.
Thanks.
--
Dmitry
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
[-- Attachment #2: Patch reporting HID device zero battery.jpg --]
[-- Type: image/jpeg, Size: 482355 bytes --]
^ permalink raw reply
* Re: [PATCH] HID: hid-input: only ignore 0 battery events for digitizers
From: Dmitry Torokhov @ 2025-10-15 4:31 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, 卢国宏, kenalba,
linux-input, linux-kernel
In-Reply-To: <r20q42n6-n65r-3151-s194-10222o3o6s6s@xreary.bet>
Hi Jiri,
On Tue, Oct 14, 2025 at 12:25:25PM +0200, Jiri Kosina wrote:
>
> Hi Dmitry,
>
> thanks for the fix. It doesn't apply cleanly on a reasonably recent tree
> though, as since e94536e1d1818b09 we're already propagating usage to
> hidinput_update_battery(), and we're issuing explicit call to
> power_supply_changed() as well.
>
> Could you please refresh on a more recent codebase and resubmit? I could
> do that myself, but I guess you also have a way to test the patch with
> your use-case ... ?
Sorry about that, I made the patch on top of my tree which lags behind.
I just sent a v2 rebased on top of linux-next.
I actually do not have the hardware to test, we have to rely on 卢国宏
to do it for us.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v2] HID: hid-input: only ignore 0 battery events for digitizers
From: Dmitry Torokhov @ 2025-10-15 4:28 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: 卢国宏, kenalba, linux-input, linux-kernel
Commit 581c4484769e ("HID: input: map digitizer battery usage") added
handling of battery events for digitizers (typically for batteries
presented in stylii). Digitizers typically report correct battery levels
only when stylus is actively touching the surface, and in other cases
they may report battery level of 0. To avoid confusing consumers of the
battery information the code was added to filer out reports with 0
battery levels.
However there exist other kinds of devices that may legitimately report
0 battery levels. Fix this by filtering out 0-level reports only for
digitizer usages, and continue reporting them for other kinds of devices
(Smart Batteries, etc).
Reported-by: 卢国宏 <luguohong@xiaomi.com>
Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
v2: rebased on top of linux-next, dropped Tested-by: tag
drivers/hid/hid-input.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 5d7532d79d21..e56e7de53279 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -635,7 +635,10 @@ static void hidinput_update_battery(struct hid_device *dev, unsigned int usage,
return;
}
- if (value == 0 || value < dev->battery_min || value > dev->battery_max)
+ if ((usage & HID_USAGE_PAGE) == HID_UP_DIGITIZER && value == 0)
+ return;
+
+ if (value < dev->battery_min || value > dev->battery_max)
return;
capacity = hidinput_scale_battery_capacity(dev, value);
--
2.51.0.858.gf9c4a03a3a-goog
--
Dmitry
^ permalink raw reply related
* RE: [PATCH] HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blocking
From: Zhang, Lixu @ 2025-10-15 1:15 UTC (permalink / raw)
To: srinivas pandruvada, Jiri Kosina
Cc: linux-input@vger.kernel.org, benjamin.tissoires@redhat.com,
Wang, Selina
In-Reply-To: <3396dd7eecd24a95d63f3ae6655c3efa553028cf.camel@linux.intel.com>
>-----Original Message-----
>From: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
>Sent: Wednesday, October 15, 2025 12:27 AM
>To: Jiri Kosina <jikos@kernel.org>; Zhang, Lixu <lixu.zhang@intel.com>
>Cc: linux-input@vger.kernel.org; benjamin.tissoires@redhat.com; Wang, Selina
><selina.wang@intel.com>
>Subject: Re: [PATCH] HID: intel-ish-hid: Use dedicated unbound workqueues to
>prevent resume blocking
>
>On Tue, 2025-10-14 at 15:19 +0200, Jiri Kosina wrote:
>> On Fri, 10 Oct 2025, Zhang Lixu wrote:
>>
>> > During suspend/resume tests with S2IDLE, some ISH functional
>> > failures were observed because of delay in executing ISH resume
>> > handler. Here
>> > schedule_work() is used from resume handler to do actual work.
>> > schedule_work() uses system_wq, which is a per CPU work queue.
>> > Although
>> > the queuing is not bound to a CPU, but it prefers local CPU of the
>> > caller, unless prohibited.
>> >
>> > Users of this work queue are not supposed to queue long running
>> > work.
>> > But in practice, there are scenarios where long running work items
>> > are queued on other unbound workqueues, occupying the CPU. As a
>> > result, the ISH resume handler may not get a chance to execute in a
>> > timely manner.
>> >
>> > In one scenario, one of the ish_resume_handler() executions was
>> > delayed nearly 1 second because another work item on an unbound
>> > workqueue occupied the same CPU. This delay causes ISH functionality
>> > failures.
>> >
>> > A similar issue was previously observed where the ISH HID driver
>> > timed out while getting the HID descriptor during S4 resume in the
>> > recovery kernel, likely caused by the same workqueue contention
>> > problem.
>> >
>> > Create dedicated unbound workqueues for all ISH operations to allow
>> > work items to execute on any available CPU, eliminating CPU-specific
>> > bottlenecks and improving resume reliability under varying system
>> > loads. Also ISH has three different components, a bus driver which
>> > implements ISH protocols, a PCI interface layer and HID interface.
>> > Use one dedicated work queue for all of them.
>> >
>> > Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
>>
>> How serious / widespread / easy to trigger is the issue? My reading of
>> this is that it should be merged still in this cycle (i.e. for 6.18),
>> but I'd like to have that confirmed.
>
>I don't think we notice this issue in our regular cyclic tests of 100s of cycles. So
>I think this can wait. Lixu, what do you think?
I personally prefer to have this patch merged before the patch series [PATCH 0/6] HID: intel-ish-hid: Various power management, since a merge conflict exists between this patch and that patch series. If this patch is merged first, it would be more convenient for others to backport this patch to other kernel versions.
BTW, in this case, the patch series [PATCH 0/6] HID: intel-ish-hid: Various power management would need to be rebased. Do I need to send a v2 patch series for the rebase?
Thanks,
Lixu
>
>Thanks,
>Srinivas
>
>
>>
>> Thanks,
^ permalink raw reply
* RE: [PATCH] Hid: Intel-thc-hid: Intel-quickspi: switch first interrupt from level to edge detection
From: Xu, Even @ 2025-10-15 0:26 UTC (permalink / raw)
To: Jiri Kosina
Cc: bentiss@kernel.org, srinivas.pandruvada@linux.intel.com,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Zhang, Rui1
In-Reply-To: <13o2s0so-nq3r-5909-4n2n-o97q2s35025n@xreary.bet>
Thanks Jiri!
Best Regards,
Even Xu
> -----Original Message-----
> From: Jiri Kosina <jikos@kernel.org>
> Sent: Tuesday, October 14, 2025 5:29 PM
> To: Xu, Even <even.xu@intel.com>
> Cc: bentiss@kernel.org; srinivas.pandruvada@linux.intel.com; linux-
> input@vger.kernel.org; linux-kernel@vger.kernel.org; Zhang, Rui1
> <rui1.zhang@intel.com>
> Subject: Re: [PATCH] Hid: Intel-thc-hid: Intel-quickspi: switch first interrupt from
> level to edge detection
>
> On Fri, 19 Sep 2025, Even Xu wrote:
>
> > The original implementation used level detection for the first
> > interrupt after device reset to avoid potential interrupt line noise
> > and missed interrupts during the initialization phase. However, this
> > approach introduced unintended side effects when tested with certain
> > touch panels,
> > including:
> > - Delayed hardware interrupt response
> > - Multiple spurious interrupt triggers
> >
> > Switching back to edge detection for the first interrupt resolves
> > these issues while maintaining reliable interrupt handling.
> >
> > Extensive testing across multiple platforms with touch panels from
> > various vendors confirms this change introduces no regressions.
> >
> > Fixes: 9d8d51735a3a ("HID: intel-thc-hid: intel-quickspi: Add HIDSPI
> > protocol implementation")
> > Tested-by: Rui Zhang <rui1.zhang@intel.com>
> > Signed-off-by: Even Xu <even.xu@intel.com>
>
> Applied to hid.git#for-6.18/upstream-fixes, thanks.
>
> --
> Jiri Kosina
> SUSE Labs
^ permalink raw reply
* Re: [PATCH 18/32] media: i2c: ov9282: Use %pe format specifier
From: Bryan O'Donoghue @ 2025-10-14 21:10 UTC (permalink / raw)
To: Ricardo Ribalda, Linus Walleij, Dmitry Torokhov,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Krzysztof Hałasa, Tomi Valkeinen, Leon Luo, Kieran Bingham,
Jacopo Mondi, Kieran Bingham, Laurent Pinchart,
Niklas Söderlund, Julien Massot, Jacopo Mondi, Daniel Scally,
Dave Stevenson, Benjamin Mugnier, Sylvain Petinot, Yong Zhi,
Bingbu Cao, Tianshu Qiu, Tiffany Lin, Andrew-CT Chen, Yunfei Dong,
Matthias Brugger, AngeloGioacchino Del Regno, Rui Miguel Silva,
Laurent Pinchart, Martin Kepplinger, Purism Kernel Team,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Dafna Hirschfeld, Heiko Stuebner, Sylwester Nawrocki,
Krzysztof Kozlowski, Alim Akhtar, Yemike Abhilash Chandra,
Greg Kroah-Hartman
Cc: linux-input, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, imx, linux-renesas-soc, linux-rockchip,
linux-samsung-soc, linux-staging
In-Reply-To: <20251013-ptr_err-v1-18-2c5efbd82952@chromium.org>
On 13/10/2025 15:14, Ricardo Ribalda wrote:
> The %pe format specifier is designed to print error pointers. It prints
> a symbolic error name (eg. -EINVAL) and it makes the code simpler by
> omitting PTR_ERR().
>
> This patch fixes this cocci report:
> ./i2c/ov9282.c:1133:3-10: WARNING: Consider using %pe to print PTR_ERR()
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/media/i2c/ov9282.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/i2c/ov9282.c b/drivers/media/i2c/ov9282.c
> index a9f6176e9729d500a40004de92c35b9abf89b08c..3e24d88f603c1432865b4d880670e4b67f1b5cec 100644
> --- a/drivers/media/i2c/ov9282.c
> +++ b/drivers/media/i2c/ov9282.c
> @@ -1129,8 +1129,8 @@ static int ov9282_parse_hw_config(struct ov9282 *ov9282)
> ov9282->reset_gpio = devm_gpiod_get_optional(ov9282->dev, "reset",
> GPIOD_OUT_LOW);
> if (IS_ERR(ov9282->reset_gpio)) {
> - dev_err(ov9282->dev, "failed to get reset gpio %ld",
> - PTR_ERR(ov9282->reset_gpio));
> + dev_err(ov9282->dev, "failed to get reset gpio %pe",
> + ov9282->reset_gpio);
> return PTR_ERR(ov9282->reset_gpio);
> }
>
>
> --
> 2.51.0.760.g7b8bcc2412-goog
>
>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
^ permalink raw reply
* Re: [PATCH 16/32] media: i2c: ov5675: Use %pe format specifier
From: Bryan O'Donoghue @ 2025-10-14 21:10 UTC (permalink / raw)
To: Ricardo Ribalda, Linus Walleij, Dmitry Torokhov,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Krzysztof Hałasa, Tomi Valkeinen, Leon Luo, Kieran Bingham,
Jacopo Mondi, Kieran Bingham, Laurent Pinchart,
Niklas Söderlund, Julien Massot, Jacopo Mondi, Daniel Scally,
Dave Stevenson, Benjamin Mugnier, Sylvain Petinot, Yong Zhi,
Bingbu Cao, Tianshu Qiu, Tiffany Lin, Andrew-CT Chen, Yunfei Dong,
Matthias Brugger, AngeloGioacchino Del Regno, Rui Miguel Silva,
Laurent Pinchart, Martin Kepplinger, Purism Kernel Team,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Dafna Hirschfeld, Heiko Stuebner, Sylwester Nawrocki,
Krzysztof Kozlowski, Alim Akhtar, Yemike Abhilash Chandra,
Greg Kroah-Hartman
Cc: linux-input, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, imx, linux-renesas-soc, linux-rockchip,
linux-samsung-soc, linux-staging
In-Reply-To: <20251013-ptr_err-v1-16-2c5efbd82952@chromium.org>
On 13/10/2025 15:14, Ricardo Ribalda wrote:
> The %pe format specifier is designed to print error pointers. It prints
> a symbolic error name (eg. -EINVAL) and it makes the code simpler by
> omitting PTR_ERR().
>
> This patch fixes this cocci report:
> ./i2c/ov5675.c:1188:9-16: WARNING: Consider using %pe to print PTR_ERR()
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/media/i2c/ov5675.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5675.c b/drivers/media/i2c/ov5675.c
> index 30e27d39ee445c2603b8fecf7a1107969eb97df3..ea26df328189eef449ce121c0f62a4ef02631830 100644
> --- a/drivers/media/i2c/ov5675.c
> +++ b/drivers/media/i2c/ov5675.c
> @@ -1184,8 +1184,8 @@ static int ov5675_get_hwcfg(struct ov5675 *ov5675)
> ov5675->xvclk = devm_v4l2_sensor_clk_get(dev, NULL);
> if (IS_ERR(ov5675->xvclk))
> return dev_err_probe(dev, PTR_ERR(ov5675->xvclk),
> - "failed to get xvclk: %ld\n",
> - PTR_ERR(ov5675->xvclk));
> + "failed to get xvclk: %pe\n",
> + ov5675->xvclk);
>
> xvclk_rate = clk_get_rate(ov5675->xvclk);
> if (xvclk_rate != OV5675_XVCLK_19_2) {
>
> --
> 2.51.0.760.g7b8bcc2412-goog
>
>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
^ permalink raw reply
* Re: [PATCH 11/32] media: i2c: imx412: Use %pe format specifier
From: Bryan O'Donoghue @ 2025-10-14 21:09 UTC (permalink / raw)
To: Ricardo Ribalda, Linus Walleij, Dmitry Torokhov,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Krzysztof Hałasa, Tomi Valkeinen, Leon Luo, Kieran Bingham,
Jacopo Mondi, Kieran Bingham, Laurent Pinchart,
Niklas Söderlund, Julien Massot, Jacopo Mondi, Daniel Scally,
Dave Stevenson, Benjamin Mugnier, Sylvain Petinot, Yong Zhi,
Bingbu Cao, Tianshu Qiu, Tiffany Lin, Andrew-CT Chen, Yunfei Dong,
Matthias Brugger, AngeloGioacchino Del Regno, Rui Miguel Silva,
Laurent Pinchart, Martin Kepplinger, Purism Kernel Team,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Dafna Hirschfeld, Heiko Stuebner, Sylwester Nawrocki,
Krzysztof Kozlowski, Alim Akhtar, Yemike Abhilash Chandra,
Greg Kroah-Hartman
Cc: linux-input, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, imx, linux-renesas-soc, linux-rockchip,
linux-samsung-soc, linux-staging
In-Reply-To: <20251013-ptr_err-v1-11-2c5efbd82952@chromium.org>
On 13/10/2025 15:14, Ricardo Ribalda wrote:
> The %pe format specifier is designed to print error pointers. It prints
> a symbolic error name (eg. -EINVAL) and it makes the code simpler by
> omitting PTR_ERR().
>
> This patch fixes this cocci report:
> ./i2c/imx412.c:931:3-10: WARNING: Consider using %pe to print PTR_ERR()
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/media/i2c/imx412.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/i2c/imx412.c b/drivers/media/i2c/imx412.c
> index 7bbd639a9ddfa7fa76d3a4594be1e1c4d002c98a..b3826f80354703b17b416dc233854da3f5736e38 100644
> --- a/drivers/media/i2c/imx412.c
> +++ b/drivers/media/i2c/imx412.c
> @@ -927,8 +927,8 @@ static int imx412_parse_hw_config(struct imx412 *imx412)
> imx412->reset_gpio = devm_gpiod_get_optional(imx412->dev, "reset",
> GPIOD_OUT_LOW);
> if (IS_ERR(imx412->reset_gpio)) {
> - dev_err(imx412->dev, "failed to get reset gpio %ld\n",
> - PTR_ERR(imx412->reset_gpio));
> + dev_err(imx412->dev, "failed to get reset gpio %pe\n",
> + imx412->reset_gpio);
> return PTR_ERR(imx412->reset_gpio);
> }
>
>
> --
> 2.51.0.760.g7b8bcc2412-goog
>
>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
^ permalink raw reply
* [PATCH 1/1] dt-bindings: mfd: dlg,da9063: Allow wakeup-source property
From: Frank Li @ 2025-10-14 18:45 UTC (permalink / raw)
To: Support Opensource, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Biju Das,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
Allow wakeup-source property to fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-emcon-avari.dtb: onkey (dlg,da9063-onkey): 'wakeup-source' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
index 1480d95421e18..29ff8fc0d02ec 100644
--- a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
+++ b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
@@ -32,6 +32,8 @@ properties:
the OnKey driver will remove support for the KEY_POWER key press
when triggered using a long press of the OnKey.
+ wakeup-source: true
+
required:
- compatible
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] HID: Kconfig: Fix build error from CONFIG_HID_HAPTIC
From: Jonathan Denose @ 2025-10-14 16:54 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Thorsten Leemhuis, Randy Dunlap, Lucas GISSOT,
linux-input, linux-kernel
In-Reply-To: <r8116qrr-5n80-01s8-92o0-88n8q14007s9@xreary.bet>
On Tue, Oct 14, 2025 at 5:09 AM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Mon, 13 Oct 2025, Jonathan Denose wrote:
>
> > Temporarily change CONFIG_HID_HAPTIC to be bool instead of tristate, until
> > we implement a permanent solution.
> >
> > ---
> > Recently the CONFIG_HID_HAPTIC Kconfig option was reported as causing
> > the following build errors:
> >
> > MODPOST Module.symvers
> > ERROR: modpost: "hid_haptic_init" [drivers/hid/hid-multitouch.ko] undefined!
> > ERROR: modpost: "hid_haptic_pressure_increase" [drivers/hid/hid-multitouch.ko] undefined!
> > ERROR: modpost: "hid_haptic_check_pressure_unit" [drivers/hid/hid-multitouch.ko] undefined!
> > ERROR: modpost: "hid_haptic_input_configured" [drivers/hid/hid-multitouch.ko] undefined!
> > ERROR: modpost: "hid_haptic_input_mapping" [drivers/hid/hid-multitouch.ko] undefined!
> > ERROR: modpost: "hid_haptic_feature_mapping" [drivers/hid/hid-multitouch.ko] undefined!
> > ERROR: modpost: "hid_haptic_pressure_reset" [drivers/hid/hid-multitouch.ko] undefined!
> > make[3]: *** [/home/thl/var/linux.dev/scripts/Makefile.modpost:147: Module.symvers] Error 1
> >
> > when the kernel is compiled with the following configuration:
> >
> > CONFIG_HID=y
> > CONFIG_HID_MULTITOUCH=m
> > CONFIG_HID_HAPTIC=m
> >
> > To resolve this, temporarily change the CONFIG_HID_HAPTIC option to be
> > bool, until we arrive at a permanent solution to enable CONFIG_HID_HAPTIC
> > to be tristate.
> >
> > For a more detailed discussion, see [1].
> >
> > [1]: https://lore.kernel.org/linux-input/auypydfkhx2eg7vp764way4batdilzc35inqda3exwzs3tk3ff@oagat6g46zto/
> >
> > Signed-off-by: Jonathan Denose <jdenose@google.com>
>
> I've moved this whole block above the --- line and applied.
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
Ok, I understand now. Thank you all for the feedback and fixing/applying.
--
Jonathan
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blocking
From: srinivas pandruvada @ 2025-10-14 16:26 UTC (permalink / raw)
To: Jiri Kosina, Zhang Lixu; +Cc: linux-input, benjamin.tissoires, selina.wang
In-Reply-To: <0r41p984-7qq4-4qp9-s175-1o8q6o7999o8@xreary.bet>
On Tue, 2025-10-14 at 15:19 +0200, Jiri Kosina wrote:
> On Fri, 10 Oct 2025, Zhang Lixu wrote:
>
> > During suspend/resume tests with S2IDLE, some ISH functional
> > failures were
> > observed because of delay in executing ISH resume handler. Here
> > schedule_work() is used from resume handler to do actual work.
> > schedule_work() uses system_wq, which is a per CPU work queue.
> > Although
> > the queuing is not bound to a CPU, but it prefers local CPU of the
> > caller,
> > unless prohibited.
> >
> > Users of this work queue are not supposed to queue long running
> > work.
> > But in practice, there are scenarios where long running work items
> > are
> > queued on other unbound workqueues, occupying the CPU. As a result,
> > the
> > ISH resume handler may not get a chance to execute in a timely
> > manner.
> >
> > In one scenario, one of the ish_resume_handler() executions was
> > delayed
> > nearly 1 second because another work item on an unbound workqueue
> > occupied
> > the same CPU. This delay causes ISH functionality failures.
> >
> > A similar issue was previously observed where the ISH HID driver
> > timed out
> > while getting the HID descriptor during S4 resume in the recovery
> > kernel,
> > likely caused by the same workqueue contention problem.
> >
> > Create dedicated unbound workqueues for all ISH operations to allow
> > work
> > items to execute on any available CPU, eliminating CPU-specific
> > bottlenecks
> > and improving resume reliability under varying system loads. Also
> > ISH has
> > three different components, a bus driver which implements ISH
> > protocols, a
> > PCI interface layer and HID interface. Use one dedicated work queue
> > for all
> > of them.
> >
> > Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
>
> How serious / widespread / easy to trigger is the issue? My reading
> of
> this is that it should be merged still in this cycle (i.e. for 6.18),
> but
> I'd like to have that confirmed.
I don't think we notice this issue in our regular cyclic tests of 100s
of cycles. So I think this can wait. Lixu, what do you think?
Thanks,
Srinivas
>
> Thanks,
^ permalink raw reply
* Re: [syzbot] [input?] [usb?] KASAN: slab-out-of-bounds Read in mcp2221_raw_event (2)
From: syzbot @ 2025-10-14 15:20 UTC (permalink / raw)
To: bentiss, jikos, linux-input, linux-kernel, linux-usb,
syzkaller-bugs
In-Reply-To: <68ec7960.a70a0220.b3ac9.0017.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 3a8660878839 Linux 6.18-rc1
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12a705e2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=f3e7b5a3627a90dd
dashboard link: https://syzkaller.appspot.com/bug?extid=1018672fe70298606e5f
compiler: gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=132ebb34580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=140fe52f980000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/e767e8931970/disk-3a866087.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/4cb12bdcfcea/vmlinux-3a866087.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b08acfae954d/bzImage-3a866087.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1018672fe70298606e5f@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in mcp2221_raw_event+0x1070/0x10a0 drivers/hid/hid-mcp2221.c:948
Read of size 1 at addr ffff8880721cbfff by task kworker/0:7/6094
CPU: 0 UID: 0 PID: 6094 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025
Workqueue: usb_hub_wq hub_event
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xcd/0x630 mm/kasan/report.c:482
kasan_report+0xe0/0x110 mm/kasan/report.c:595
mcp2221_raw_event+0x1070/0x10a0 drivers/hid/hid-mcp2221.c:948
__hid_input_report.constprop.0+0x314/0x450 drivers/hid/hid-core.c:2139
hid_irq_in+0x35e/0x870 drivers/hid/usbhid/hid-core.c:286
__usb_hcd_giveback_urb+0x38b/0x610 drivers/usb/core/hcd.c:1661
usb_hcd_giveback_urb+0x39b/0x450 drivers/usb/core/hcd.c:1745
dummy_timer+0x1809/0x3a00 drivers/usb/gadget/udc/dummy_hcd.c:1995
__run_hrtimer kernel/time/hrtimer.c:1777 [inline]
__hrtimer_run_queues+0x202/0xad0 kernel/time/hrtimer.c:1841
hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1858
handle_softirqs+0x219/0x8e0 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x109/0x170 kernel/softirq.c:723
irq_exit_rcu+0x9/0x30 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]
sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1052
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:kasan_check_range+0x12/0x1b0 mm/kasan/generic.c:199
Code: 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 40 d6 48 85 f6 0f 84 64 01 00 00 48 89 f8 41 54 <44> 0f b6 c2 48 01 f0 55 53 0f 82 d7 00 00 00 eb 0f cc cc cc 48 b8
RSP: 0018:ffffc900037b6b60 EFLAGS: 00000202
RAX: ffff888077da86b0 RBX: ffff888077da8668 RCX: ffffffff819803ae
RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffff888077da86b0
RBP: ffff888077da86b0 R08: 0000000000000002 R09: 0000000000000000
R10: ffff888077da866f R11: 0000000000000000 R12: ffffffff8c6df2a0
R13: ffffffff9ae57620 R14: 0000000000000000 R15: ffff888026709978
instrument_atomic_write include/linux/instrumented.h:82 [inline]
atomic_set include/linux/atomic/atomic-instrumented.h:67 [inline]
osq_lock_init include/linux/osq_lock.h:25 [inline]
__mutex_init+0xae/0x120 kernel/locking/mutex.c:53
i2c_register_adapter+0x15d/0x1370 drivers/i2c/i2c-core-base.c:1544
i2c_add_adapter drivers/i2c/i2c-core-base.c:1673 [inline]
i2c_add_adapter+0x10a/0x1b0 drivers/i2c/i2c-core-base.c:1653
devm_i2c_add_adapter+0x1b/0x90 drivers/i2c/i2c-core-base.c:1845
mcp2221_probe+0x5f1/0xc50 drivers/hid/hid-mcp2221.c:1289
__hid_device_probe drivers/hid/hid-core.c:2775 [inline]
hid_device_probe+0x5ba/0x8d0 drivers/hid/hid-core.c:2812
call_driver_probe drivers/base/dd.c:581 [inline]
really_probe+0x241/0xa90 drivers/base/dd.c:659
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:801
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:831
__device_attach_driver+0x1df/0x310 drivers/base/dd.c:959
bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:462
__device_attach+0x1e4/0x4b0 drivers/base/dd.c:1031
bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:537
device_add+0x1148/0x1aa0 drivers/base/core.c:3689
hid_add_device+0x31b/0x5c0 drivers/hid/hid-core.c:2951
usbhid_probe+0xd38/0x13f0 drivers/hid/usbhid/hid-core.c:1435
usb_probe_interface+0x303/0xa40 drivers/usb/core/driver.c:396
call_driver_probe drivers/base/dd.c:581 [inline]
really_probe+0x241/0xa90 drivers/base/dd.c:659
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:801
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:831
__device_attach_driver+0x1df/0x310 drivers/base/dd.c:959
bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:462
__device_attach+0x1e4/0x4b0 drivers/base/dd.c:1031
bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:537
device_add+0x1148/0x1aa0 drivers/base/core.c:3689
usb_set_configuration+0x1187/0x1e20 drivers/usb/core/message.c:2210
usb_generic_driver_probe+0xb1/0x110 drivers/usb/core/generic.c:250
usb_probe_device+0xef/0x3e0 drivers/usb/core/driver.c:291
call_driver_probe drivers/base/dd.c:581 [inline]
really_probe+0x241/0xa90 drivers/base/dd.c:659
__driver_probe_device+0x1de/0x440 drivers/base/dd.c:801
driver_probe_device+0x4c/0x1b0 drivers/base/dd.c:831
__device_attach_driver+0x1df/0x310 drivers/base/dd.c:959
bus_for_each_drv+0x159/0x1e0 drivers/base/bus.c:462
__device_attach+0x1e4/0x4b0 drivers/base/dd.c:1031
bus_probe_device+0x17f/0x1c0 drivers/base/bus.c:537
device_add+0x1148/0x1aa0 drivers/base/core.c:3689
usb_new_device+0xd07/0x1a60 drivers/usb/core/hub.c:2694
hub_port_connect drivers/usb/core/hub.c:5566 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5706 [inline]
port_event drivers/usb/core/hub.c:5870 [inline]
hub_event+0x2f34/0x4fe0 drivers/usb/core/hub.c:5952
process_one_work+0x9cf/0x1b70 kernel/workqueue.c:3263
process_scheduled_works kernel/workqueue.c:3346 [inline]
worker_thread+0x6c8/0xf10 kernel/workqueue.c:3427
kthread+0x3c5/0x780 kernel/kthread.c:463
ret_from_fork+0x675/0x7d0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Allocated by task 5918:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:56
kasan_save_track+0x14/0x30 mm/kasan/common.c:77
poison_kmalloc_redzone mm/kasan/common.c:400 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:417
kmalloc_noprof include/linux/slab.h:957 [inline]
kzalloc_noprof include/linux/slab.h:1094 [inline]
ipv6_add_addr+0x4e3/0x1fe0 net/ipv6/addrconf.c:1120
add_addr+0xde/0x350 net/ipv6/addrconf.c:3201
add_v4_addrs+0x642/0x980 net/ipv6/addrconf.c:3263
addrconf_gre_config net/ipv6/addrconf.c:3545 [inline]
addrconf_init_auto_addrs+0x51a/0x810 net/ipv6/addrconf.c:3559
addrconf_notify+0xe93/0x19e0 net/ipv6/addrconf.c:3740
notifier_call_chain+0xbc/0x410 kernel/notifier.c:85
call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:2229
call_netdevice_notifiers_extack net/core/dev.c:2267 [inline]
call_netdevice_notifiers net/core/dev.c:2281 [inline]
__dev_notify_flags+0x12c/0x2e0 net/core/dev.c:9676
netif_change_flags+0x108/0x160 net/core/dev.c:9705
do_setlink.constprop.0+0xb53/0x4380 net/core/rtnetlink.c:3151
rtnl_changelink net/core/rtnetlink.c:3769 [inline]
__rtnl_newlink net/core/rtnetlink.c:3928 [inline]
rtnl_newlink+0x1446/0x2000 net/core/rtnetlink.c:4065
rtnetlink_rcv_msg+0x95e/0xe90 net/core/rtnetlink.c:6954
netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552
netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346
netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
__sys_sendto+0x4a3/0x520 net/socket.c:2244
__do_sys_sendto net/socket.c:2251 [inline]
__se_sys_sendto net/socket.c:2247 [inline]
__x64_sys_sendto+0xe0/0x1c0 net/socket.c:2247
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff8880721cbc00
which belongs to the cache kmalloc-cg-512 of size 512
The buggy address is located 583 bytes to the right of
allocated 440-byte region [ffff8880721cbc00, ffff8880721cbdb8)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x721c8
head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88813ff30140 ffffea0001e68c00 dead000000000002
raw: 0000000000000000 0000000000100010 00000000f5000000 0000000000000000
head: 00fff00000000040 ffff88813ff30140 ffffea0001e68c00 dead000000000002
head: 0000000000000000 0000000000100010 00000000f5000000 0000000000000000
head: 00fff00000000002 ffffea0001c87201 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 2, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5796, tgid 5796 (sshd-session), ts 52056965840, free_ts 15121629475
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x1c0/0x230 mm/page_alloc.c:1850
prep_new_page mm/page_alloc.c:1858 [inline]
get_page_from_freelist+0x10a3/0x3a30 mm/page_alloc.c:3884
__alloc_frozen_pages_noprof+0x25f/0x2470 mm/page_alloc.c:5183
alloc_pages_mpol+0x1fb/0x550 mm/mempolicy.c:2416
alloc_slab_page mm/slub.c:3039 [inline]
allocate_slab mm/slub.c:3212 [inline]
new_slab+0x24a/0x360 mm/slub.c:3266
___slab_alloc+0xdc4/0x1ae0 mm/slub.c:4636
__slab_alloc.constprop.0+0x63/0x110 mm/slub.c:4755
__slab_alloc_node mm/slub.c:4831 [inline]
slab_alloc_node mm/slub.c:5253 [inline]
__do_kmalloc_node mm/slub.c:5626 [inline]
__kmalloc_node_track_caller_noprof+0x4db/0x8a0 mm/slub.c:5736
kmalloc_reserve+0xef/0x2c0 net/core/skbuff.c:601
__alloc_skb+0x166/0x380 net/core/skbuff.c:670
alloc_skb include/linux/skbuff.h:1383 [inline]
alloc_skb_with_frags+0xe0/0x860 net/core/skbuff.c:6671
sock_alloc_send_pskb+0x7f9/0x980 net/core/sock.c:2965
unix_stream_sendmsg+0x39f/0x1340 net/unix/af_unix.c:2455
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
sock_write_iter+0x566/0x610 net/socket.c:1195
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x7d3/0x11d0 fs/read_write.c:686
ksys_write+0x1f8/0x250 fs/read_write.c:738
page last free pid 1 tgid 1 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1394 [inline]
__free_frozen_pages+0x7df/0x1160 mm/page_alloc.c:2906
__free_pages mm/page_alloc.c:5302 [inline]
free_contig_range+0x183/0x4b0 mm/page_alloc.c:7146
destroy_args+0xb69/0x12e0 mm/debug_vm_pgtable.c:958
debug_vm_pgtable+0x1a32/0x3640 mm/debug_vm_pgtable.c:1345
do_one_initcall+0x123/0x6e0 init/main.c:1283
do_initcall_level init/main.c:1345 [inline]
do_initcalls init/main.c:1361 [inline]
do_basic_setup init/main.c:1380 [inline]
kernel_init_freeable+0x5c8/0x920 init/main.c:1593
kernel_init+0x1c/0x2b0 init/main.c:1483
ret_from_fork+0x675/0x7d0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Memory state around the buggy address:
ffff8880721cbe80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880721cbf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8880721cbf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8880721cc000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8880721cc080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
----------------
Code disassembly (best guess):
0: 00 00 add %al,(%rax)
2: 00 00 add %al,(%rax)
4: 0f 1f 40 00 nopl 0x0(%rax)
8: 90 nop
9: 90 nop
a: 90 nop
b: 90 nop
c: 90 nop
d: 90 nop
e: 90 nop
f: 90 nop
10: 90 nop
11: 90 nop
12: 90 nop
13: 90 nop
14: 90 nop
15: 90 nop
16: 90 nop
17: 90 nop
18: 0f 1f 40 d6 nopl -0x2a(%rax)
1c: 48 85 f6 test %rsi,%rsi
1f: 0f 84 64 01 00 00 je 0x189
25: 48 89 f8 mov %rdi,%rax
28: 41 54 push %r12
* 2a: 44 0f b6 c2 movzbl %dl,%r8d <-- trapping instruction
2e: 48 01 f0 add %rsi,%rax
31: 55 push %rbp
32: 53 push %rbx
33: 0f 82 d7 00 00 00 jb 0x110
39: eb 0f jmp 0x4a
3b: cc int3
3c: cc int3
3d: cc int3
3e: 48 rex.W
3f: b8 .byte 0xb8
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blocking
From: Jiri Kosina @ 2025-10-14 13:19 UTC (permalink / raw)
To: Zhang Lixu
Cc: linux-input, srinivas.pandruvada, benjamin.tissoires, selina.wang
In-Reply-To: <20251010055254.532925-1-lixu.zhang@intel.com>
On Fri, 10 Oct 2025, Zhang Lixu wrote:
> During suspend/resume tests with S2IDLE, some ISH functional failures were
> observed because of delay in executing ISH resume handler. Here
> schedule_work() is used from resume handler to do actual work.
> schedule_work() uses system_wq, which is a per CPU work queue. Although
> the queuing is not bound to a CPU, but it prefers local CPU of the caller,
> unless prohibited.
>
> Users of this work queue are not supposed to queue long running work.
> But in practice, there are scenarios where long running work items are
> queued on other unbound workqueues, occupying the CPU. As a result, the
> ISH resume handler may not get a chance to execute in a timely manner.
>
> In one scenario, one of the ish_resume_handler() executions was delayed
> nearly 1 second because another work item on an unbound workqueue occupied
> the same CPU. This delay causes ISH functionality failures.
>
> A similar issue was previously observed where the ISH HID driver timed out
> while getting the HID descriptor during S4 resume in the recovery kernel,
> likely caused by the same workqueue contention problem.
>
> Create dedicated unbound workqueues for all ISH operations to allow work
> items to execute on any available CPU, eliminating CPU-specific bottlenecks
> and improving resume reliability under varying system loads. Also ISH has
> three different components, a bus driver which implements ISH protocols, a
> PCI interface layer and HID interface. Use one dedicated work queue for all
> of them.
>
> Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
How serious / widespread / easy to trigger is the issue? My reading of
this is that it should be merged still in this cycle (i.e. for 6.18), but
I'd like to have that confirmed.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] drivers/hid: Implement a battery status polling mechanism for selected input devices.
From: Jiri Kosina @ 2025-10-14 12:26 UTC (permalink / raw)
To: huangzaiyang; +Cc: bentiss, linux-input, linux-kernel
In-Reply-To: <20250624130836.5743-1-huangzaiyang@oppo.com>
On Tue, 24 Jun 2025, huangzaiyang wrote:
> Reading battery capacity and status could fail and end up with timeout
> after 5s for some input devices, for example:8BitDo SN30 Pro+ gamepad.
> Implement a battery status polling mechanism for selected input devices,
> set HID_BATTERY_QUIRK_AVOID_QUERY and HID_BATTERY_QUIRK_POLLING_QUERY
> for 8BitDo SN30 Pro+ gamepad.
> to Avoid UI freezing when reading battery capacity/status.
Thanks for the patch (and sorry for the delay, it fell in between cracks
unfortunately). Minor nits:
> Signed-off-by: huangzaiyang <huangzaiyang@oppo.com>
> ---
> drivers/hid/hid-input.c | 63 +++++++++++++++++++++++++++++++++++++++++
> include/linux/hid.h | 2 ++
> 2 files changed, 65 insertions(+)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 9d80635a91eb..b113f5c49d03 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -341,6 +341,7 @@ static enum power_supply_property hidinput_battery_props[] = {
> #define HID_BATTERY_QUIRK_FEATURE (1 << 1) /* ask for feature report */
> #define HID_BATTERY_QUIRK_IGNORE (1 << 2) /* completely ignore the battery */
> #define HID_BATTERY_QUIRK_AVOID_QUERY (1 << 3) /* do not query the battery */
> +#define HID_BATTERY_QUIRK_POLLING_QUERY (1 << 4) /* polling query the battery */
>
> static const struct hid_device_id hid_battery_quirks[] = {
> { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE,
> @@ -390,6 +391,16 @@ static const struct hid_device_id hid_battery_quirks[] = {
> * set HID_BATTERY_QUIRK_IGNORE for all Elan I2C-HID devices.
> */
> { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, HID_ANY_ID), HID_BATTERY_QUIRK_IGNORE },
> + /*
> + * Reading battery capacity and status could fail and end up
> + * with timeout after 5s for some input devices, for example:
> + * 8BitDo SN30 Pro+ gamepad.
> + * set HID_BATTERY_QUIRK_AVOID_QUERY and HID_BATTERY_QUIRK_POLLING_QUERY
> + * for 8BitDo SN30 Pro+ gamepad.
> + * to Avoid UI freezing when reading battery capacity/status
> + */
We are usually not putting such verbose comments here. Describing the
quirk when defining it is sufficient, and enumerating which devices need
the quirk in the comment feels superfluous.
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS),
> + HID_BATTERY_QUIRK_AVOID_QUERY | HID_BATTERY_QUIRK_POLLING_QUERY },
> {}
> };
>
> @@ -497,6 +508,33 @@ static int hidinput_get_battery_property(struct power_supply *psy,
> return ret;
> }
>
> +/*
> + * hid input device battery polling handler
> + */
> +static void hidinput_battery_polling_handler(struct work_struct *work)
> +{
> + int value;
> + struct hid_device *dev = container_of(work, struct hid_device, battery_delayed_work.work);
> +
> + dev->battery_status = HID_BATTERY_QUERIED;
> + dev->battery_avoid_query = true;
> + value = hidinput_query_battery_capacity(dev);
> + if (value < 0) {
> + dev->battery_status = HID_BATTERY_UNKNOWN;
> + hid_err(dev, "cannot get battery capacity from device!\n");
> + } else {
> + dev->battery_capacity = value;
> + dev->battery_avoid_query = false;
> + dev->battery_status = HID_BATTERY_REPORTED;
> + hid_err(dev, "get battery capacity from device:%d!\n", value);
> + }
> +
> + /*keep polling period same to battery_ratelimit_time*/
This comment doesn't adhere to standard kernel commeting style, please add
spaces at the beginning and the end.
Could you please resubmit with these small things fixed?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 24/32] media: mediatek: vcodec: Use %pe format specifier
From: AngeloGioacchino Del Regno @ 2025-10-14 11:29 UTC (permalink / raw)
To: Ricardo Ribalda, Linus Walleij, Dmitry Torokhov,
Mauro Carvalho Chehab, Hans Verkuil, Sakari Ailus,
Krzysztof Hałasa, Tomi Valkeinen, Leon Luo, Kieran Bingham,
Jacopo Mondi, Kieran Bingham, Laurent Pinchart,
Niklas Söderlund, Julien Massot, Jacopo Mondi, Daniel Scally,
Dave Stevenson, Benjamin Mugnier, Sylvain Petinot, Yong Zhi,
Bingbu Cao, Tianshu Qiu, Tiffany Lin, Andrew-CT Chen, Yunfei Dong,
Matthias Brugger, Rui Miguel Silva, Laurent Pinchart,
Martin Kepplinger, Purism Kernel Team, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dafna Hirschfeld,
Heiko Stuebner, Sylwester Nawrocki, Krzysztof Kozlowski,
Alim Akhtar, Yemike Abhilash Chandra, Greg Kroah-Hartman
Cc: linux-input, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, imx, linux-renesas-soc, linux-rockchip,
linux-samsung-soc, linux-staging
In-Reply-To: <20251013-ptr_err-v1-24-2c5efbd82952@chromium.org>
Il 13/10/25 16:15, Ricardo Ribalda ha scritto:
> The %pe format specifier is designed to print error pointers. It prints
> a symbolic error name (eg. -EINVAL) and it makes the code simpler by
> omitting PTR_ERR().
>
> This patch fixes this cocci report:
> ./platform/mediatek/vcodec/common/mtk_vcodec_dbgfs.c:187:3-10: WARNING: Consider using %pe to print PTR_ERR()
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH] HID: multitouch: add IGNORE_DUPLICATES quirk for ELAN1206 (04f3:30f1)
From: Jiri Kosina @ 2025-10-14 11:01 UTC (permalink / raw)
To: Matt Roberts; +Cc: linux-input, bentiss, linux-kernel
In-Reply-To: <CALy8NDYVkOnRbzrO37BhX0cf4MHDwxv1LbV=JW3QOCg1+-kOqQ@mail.gmail.com>
On Sun, 5 Oct 2025, Matt Roberts wrote:
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 2879e65cf..ed318c80e 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -2150,6 +2150,10 @@ static const struct hid_device_id mt_devices[] = {
> HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
> USB_VENDOR_ID_ELAN, 0x32ae) },
>
> + /* ELAN1206 touchpad: duplicate tracking IDs cause hold/click storms */
> + { .driver_data = MT_QUIRK_IGNORE_DUPLICATES,
> + HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH, 0x04f3, 0x30f1) },
Is there a reason not to use USB_VENDOR_ID_ELAN here, instead of
open-coding 0x04f3?
Also, the patch has been whitespace-corrupted, so it can't be applied.
Could you please look into fixing that, and resubmit?
Thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH][next] HID: hid-debug: Fix spelling mistake "Rechargable" -> "Rechargeable"
From: Jiri Kosina @ 2025-10-14 10:56 UTC (permalink / raw)
To: Colin Ian King
Cc: Benjamin Tissoires, linux-input, kernel-janitors, linux-kernel
In-Reply-To: <20250928210118.242631-1-colin.i.king@gmail.com>
On Sun, 28 Sep 2025, Colin Ian King wrote:
> There is a spelling mistake in HID description. Fix it.
>
> Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: hid-input: only ignore 0 battery events for digitizers
From: Jiri Kosina @ 2025-10-14 10:25 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Benjamin Tissoires, 卢国宏, kenalba,
linux-input, linux-kernel
In-Reply-To: <of5qjeij72wduee3zyf26drfcwhpsl4sjs3v6tfjv3tgl3xsol@sss7zcyawwaz>
On Thu, 9 Oct 2025, Dmitry Torokhov wrote:
> Commit 581c4484769e ("HID: input: map digitizer battery usage") added
> handling of battery events for digitizers (typically for batteries
> presented in styli). Digitizers typically report correct battery levels
> only when stylus is actively touching the surface, and in other cases
> they may report battery level of 0. To avoid confusing consumers of the
> battery information the code was added to filer out reports with 0
> battery levels.
>
> However there exist other kinds of devices that may legitimately report
> 0 battery levels. Fix this by filtering out 0-level reports only for
> digitizer usages, and continue reporting them for other kinds of devices
> (Smart Batteries, etc).
>
> Reported-by: 卢国宏 <luguohong@xiaomi.com>
> Tested-by: 卢国宏 <luguohong@xiaomi.com>
> Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/hid/hid-input.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index ff1784b5c2a4..ba3f6655af9e 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -595,14 +595,18 @@ static void hidinput_cleanup_battery(struct hid_device *dev)
> dev->battery = NULL;
> }
>
> -static void hidinput_update_battery(struct hid_device *dev, int value)
> +static void hidinput_update_battery(struct hid_device *dev,
> + unsigned int usage, int value)
> {
> int capacity;
>
> if (!dev->battery)
> return;
>
> - if (value == 0 || value < dev->battery_min || value > dev->battery_max)
> + if ((usage & HID_USAGE_PAGE) == HID_UP_DIGITIZER && value == 0)
> + return;
> +
> + if (value < dev->battery_min || value > dev->battery_max)
> return;
>
> capacity = hidinput_scale_battery_capacity(dev, value);
> @@ -1518,7 +1522,7 @@ void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, struct
> bool handled = hidinput_set_battery_charge_status(hid, usage->hid, value);
>
> if (!handled)
> - hidinput_update_battery(hid, value);
> + hidinput_update_battery(hid, usage->hid, value);
>
> return;
Hi Dmitry,
thanks for the fix. It doesn't apply cleanly on a reasonably recent tree
though, as since e94536e1d1818b09 we're already propagating usage to
hidinput_update_battery(), and we're issuing explicit call to
power_supply_changed() as well.
Could you please refresh on a more recent codebase and resubmit? I could
do that myself, but I guess you also have a way to test the patch with
your use-case ... ?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: Kconfig: Fix build error from CONFIG_HID_HAPTIC
From: Jiri Kosina @ 2025-10-14 10:09 UTC (permalink / raw)
To: Jonathan Denose
Cc: Benjamin Tissoires, Thorsten Leemhuis, Randy Dunlap, Lucas GISSOT,
linux-input, linux-kernel
In-Reply-To: <20251013-hid-haptic-kconfig-fix-v1-1-b1ad90732625@google.com>
On Mon, 13 Oct 2025, Jonathan Denose wrote:
> Temporarily change CONFIG_HID_HAPTIC to be bool instead of tristate, until
> we implement a permanent solution.
>
> ---
> Recently the CONFIG_HID_HAPTIC Kconfig option was reported as causing
> the following build errors:
>
> MODPOST Module.symvers
> ERROR: modpost: "hid_haptic_init" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_pressure_increase" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_check_pressure_unit" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_input_configured" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_input_mapping" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_feature_mapping" [drivers/hid/hid-multitouch.ko] undefined!
> ERROR: modpost: "hid_haptic_pressure_reset" [drivers/hid/hid-multitouch.ko] undefined!
> make[3]: *** [/home/thl/var/linux.dev/scripts/Makefile.modpost:147: Module.symvers] Error 1
>
> when the kernel is compiled with the following configuration:
>
> CONFIG_HID=y
> CONFIG_HID_MULTITOUCH=m
> CONFIG_HID_HAPTIC=m
>
> To resolve this, temporarily change the CONFIG_HID_HAPTIC option to be
> bool, until we arrive at a permanent solution to enable CONFIG_HID_HAPTIC
> to be tristate.
>
> For a more detailed discussion, see [1].
>
> [1]: https://lore.kernel.org/linux-input/auypydfkhx2eg7vp764way4batdilzc35inqda3exwzs3tk3ff@oagat6g46zto/
>
> Signed-off-by: Jonathan Denose <jdenose@google.com>
I've moved this whole block above the --- line and applied.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: uclogic: Add support for the XP-PEN Artist 24 Pro
From: Jiri Kosina @ 2025-10-14 10:02 UTC (permalink / raw)
To: Joshua Goins; +Cc: linux-input, Benjamin Tissoires, linux-kernel
In-Reply-To: <20250922213207.9224-1-josh@redstrate.com>
On Mon, 22 Sep 2025, Joshua Goins wrote:
> The tablet is similar to the 22R Pro, but with a few annoying
> differences. Its descriptors are bigger because of the tablet's split
> coordinate system, I guess it's just that large. Thankfully, this is
> easy enough to support as all we have to do is shift bytes around.
>
> To help code re-use, I changed the signature of
> uclogic_params_init_ugee_xppen_pro to accept a pen descriptor so we
> didn't create yet-another initialization function.
>
> I have been testing this locally for a month or so and it works great,
> and also corroborated this with a few other testers. Since this touches
> my 22R Pro code, I have tested and checked that it didn't regress that
> device.
Applied to hid.git#for-6.19/uclogic, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/3] HID: core: Add printk_ratelimited variants to hid_warn() etc
From: Jiri Kosina @ 2025-10-14 9:59 UTC (permalink / raw)
To: Vicki Pfau; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <20251007010533.3777922-1-vi@endrift.com>
Applied all three to hid.git#for-6.18/upstream-fixes, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Do not assume FAP in hidpp_send_message_sync()
From: Jiri Kosina @ 2025-10-14 9:55 UTC (permalink / raw)
To: Mavroudis Chatzilazaridis
Cc: stuart.a.hayhurst, linux-input, bentiss, hadess, lains
In-Reply-To: <20251002193025.2066319-1-mavchatz@protonmail.com>
On Thu, 2 Oct 2025, Mavroudis Chatzilazaridis wrote:
> Currently, hidpp_send_message_sync() retries sending the message when the
> device returns a busy error code, specifically HIDPP20_ERROR_BUSY, which
> has a different meaning under RAP. This ends up being a problem because
> this function is used for both FAP and RAP messages.
>
> This issue is not noticeable on older receivers with unreachable devices
> since they return HIDPP_ERROR_RESOURCE_ERROR (0x09), which is not equal to
> HIDPP20_ERROR_BUSY (0x08).
>
> However, newer receivers return HIDPP_ERROR_UNKNOWN_DEVICE (0x08) which
> happens to equal to HIDPP20_ERROR_BUSY, causing unnecessary retries when
> the device is not actually busy.
>
> This is resolved by checking if the error response is FAP or RAP and
> picking the respective ERROR_BUSY code.
>
> Fixes: 60165ab774cb ("HID: logitech-hidpp: rework one more time the retries attempts")
> Signed-off-by: Mavroudis Chatzilazaridis <mavchatz@protonmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Silence protocol errors on newer lightspeed receivers
From: Jiri Kosina @ 2025-10-14 9:53 UTC (permalink / raw)
To: Mavroudis Chatzilazaridis
Cc: stuart.a.hayhurst, linux-input, bentiss, hadess, lains
In-Reply-To: <20251002192324.1991349-1-mavchatz@protonmail.com>
On Thu, 2 Oct 2025, Mavroudis Chatzilazaridis wrote:
> When logitech-hidpp tries to communicate with an unreachable device paired
> to a 046d:c547 lightspeed receiver, the following message is printed to the
> console:
>
> hidpp_root_get_protocol_version: received protocol error 0x08
>
> This occurs because this receiver returns 0x08 (HIDPP_ERROR_UNKNOWN_DEVICE)
> when a device is unreachable, compared to 0x09 (HIDPP_ERROR_RESOURCE_ERROR)
> that the older receivers return.
>
> This patch silences this harmless error by treating
> HIDPP_ERROR_UNKNOWN_DEVICE the same as HIDPP_ERROR_RESOURCE_ERROR
> in hidpp_root_get_protocol_version().
>
> There are other checks for HIDPP_ERROR_RESOURCE_ERROR found in
> battery-related functions, however this receiver does not trigger them when
> the device is disconnected.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v5] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Jiri Kosina @ 2025-10-14 9:52 UTC (permalink / raw)
To: Mavroudis Chatzilazaridis
Cc: stuart.a.hayhurst, linux-input, benjamin.tissoires, hadess, lains
In-Reply-To: <20250927234834.2635483-1-mavchatz@protonmail.com>
On Sat, 27 Sep 2025, Mavroudis Chatzilazaridis wrote:
> This lightspeed receiver uses 13 byte mouse reports without an ID.
> There are 5 additional vendor defined bytes appended to the report.
> The workaround for such cases has been adjusted to handle these larger
> reports.
>
> The keyboard reports have a distinct layout with differing minimums and
> maximums. Additionally, the LED reports now require a report ID of 1.
>
> New keyboard and mouse descriptors have been added to reflect these
> changes.
>
> The devices attached to this receiver now report the status of their
> battery in wireless mode, libratbag communicates with them and they can
> be configured with Piper.
>
> Fixes: 9d1bd9346241 ("HID: logitech-dj: Add support for a new lightspeed receiver iteration")
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218172
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218094
> Co-developed-by: Filipe Laíns <lains@riseup.net>
> Signed-off-by: Filipe Laíns <lains@riseup.net>
> Signed-off-by: Mavroudis Chatzilazaridis <mavchatz@protonmail.com>
Applied to hid.git#for-6.19/logitech, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: hid-lg-g15: Add hw_brightness_changed support for the G510 keyboard
From: Jiri Kosina @ 2025-10-14 9:50 UTC (permalink / raw)
To: Hans de Goede; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <20251001211941.4415-1-hansg@kernel.org>
On Wed, 1 Oct 2025, Hans de Goede wrote:
> Add hw_brightness_changed support for the G510 keyboard, so that e.g.
> GNOME will show an OSD notification when toggling the backlight on/off
> with the button the keyboard.
>
> Note that it is not possible to turn the backlight back on by writing
> /sys/class/leds/.../brightness it can only be turned on by pressing
> the button on the keyboard. To reflect this /sys/class/leds/.../brightness
> will always report the last brightness value independent of the on/off
> toggle built into the keyboard.
>
> Signed-off-by: Hans de Goede <hansg@kernel.org>
Applied on top of hid.git#for-6.19/logitech, thanks.
--
Jiri Kosina
SUSE Labs
^ 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