* [PATCH] usbhid: tolerate intermittent errors
@ 2026-02-08 17:10 Liam Mitchell
2026-02-09 10:06 ` Oliver Neukum
0 siblings, 1 reply; 4+ messages in thread
From: Liam Mitchell @ 2026-02-08 17:10 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Alan Stern, linux-usb, linux-input, linux-kernel, Liam Mitchell
Modifies the usbhid error handling logic to better handle intermittent
errors like EPROTO, which should only need resubmission of URBs and not
full device reset.
Reduces initial retry delay from 13ms to 1ms. The faster the URB is
resubmitted, the lower the chance that user events will be missed.
Increases retry delay multiplier from 2 to 5, reaching max delay in a
similar number of retries.
Adds another check to the reset block, only resetting if retry_delay has
reached max, effectively only allowing reset after 4 errors.
---
The usbhid driver will reset a device after only two errors 1-1.5s apart.
The first error will be handled with a retry after 13ms.
Handling of the second error depends on the time since the first:
* <1000ms: retry after 26ms
* >1000ms & <1500ms: reset USB device, taking maybe hundreds of ms
* >1500ms: retry after 13ms
It doesn't take into account the type, count or timing of errors.
EPROTO errors can occur randomly, sometimes frequently and are often not
fixed by a device reset.
Retry delays or device resets only raise the chance that input events will
be missed and that users see symptoms like missed or sticky keyboard keys.
See following thread for more details:
https://lore.kernel.org/linux-input/CAOQ1CL6Q+4GNy=kgisLzs0UBXFT3b02PG8t-0rPuW-Wf6NhQ6g@mail.gmail.com/
The following patch is a minimal change to better tolerate intermittent errors.
Using existing variables, we reduce initial retry delays and only reset in
the 1000-1500ms window if 4+ errors have occurred.
This should reduce issues for users with intermittent errors and retain
the intended retry-backoff-reset for erroring devices that need a reset.
More comprehensive error handling could involve counting errors, time between
errors and/or switching on error type but would be more invasive.
Signed-off-by: Liam Mitchell <mitchell.liam@gmail.com>
---
drivers/hid/usbhid/hid-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index aac0051a2cf6..b6e956ca781b 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -160,12 +160,12 @@ static void hid_io_error(struct hid_device *hid)
/* When an error occurs, retry at increasing intervals */
if (usbhid->retry_delay == 0) {
- usbhid->retry_delay = 13; /* Then 26, 52, 104, 104, ... */
+ usbhid->retry_delay = 1; /* Then 5, 25, 125, 125, ... */
usbhid->stop_retry = jiffies + msecs_to_jiffies(1000);
} else if (usbhid->retry_delay < 100)
- usbhid->retry_delay *= 2;
+ usbhid->retry_delay *= 5;
- if (time_after(jiffies, usbhid->stop_retry)) {
+ if (time_after(jiffies, usbhid->stop_retry) && usbhid->retry_delay >= 100) {
/* Retries failed, so do a port reset unless we lack bandwidth*/
if (!test_bit(HID_NO_BANDWIDTH, &usbhid->iofl)
---
base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
change-id: 20260208-usbhid-eproto-152c7abcb185
Best regards,
--
Liam Mitchell <mitchell.liam@gmail.com>
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] usbhid: tolerate intermittent errors
2026-02-08 17:10 [PATCH] usbhid: tolerate intermittent errors Liam Mitchell
@ 2026-02-09 10:06 ` Oliver Neukum
2026-02-09 10:49 ` Liam Mitchell
2026-02-09 14:47 ` Alan Stern
0 siblings, 2 replies; 4+ messages in thread
From: Oliver Neukum @ 2026-02-09 10:06 UTC (permalink / raw)
To: Liam Mitchell, Jiri Kosina, Benjamin Tissoires
Cc: Alan Stern, linux-usb, linux-input, linux-kernel
On 08.02.26 18:10, Liam Mitchell wrote:
> Modifies the usbhid error handling logic to better handle intermittent
> errors like EPROTO, which should only need resubmission of URBs and not
> full device reset.
>
> Reduces initial retry delay from 13ms to 1ms. The faster the URB is
> resubmitted, the lower the chance that user events will be missed.
Hi,
in this case I have to ask the obvious question: Why wait at all?
It would seem to me that if you have spurious or intermittent errors
the right time to retry is immediately.
Regards
Oliver
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] usbhid: tolerate intermittent errors
2026-02-09 10:06 ` Oliver Neukum
@ 2026-02-09 10:49 ` Liam Mitchell
2026-02-09 14:47 ` Alan Stern
1 sibling, 0 replies; 4+ messages in thread
From: Liam Mitchell @ 2026-02-09 10:49 UTC (permalink / raw)
To: Oliver Neukum
Cc: Jiri Kosina, Benjamin Tissoires, Alan Stern, linux-usb,
linux-input, linux-kernel
On Mon, 9 Feb 2026 at 11:06, Oliver Neukum <oneukum@suse.com> wrote:
> On 08.02.26 18:10, Liam Mitchell wrote:
> > Modifies the usbhid error handling logic to better handle intermittent
> > errors like EPROTO, which should only need resubmission of URBs and not
> > full device reset.
> >
> > Reduces initial retry delay from 13ms to 1ms. The faster the URB is
> > resubmitted, the lower the chance that user events will be missed.
>
> in this case I have to ask the obvious question: Why wait at all?
> It would seem to me that if you have spurious or intermittent errors
> the right time to retry is immediately.
Agreed.
This patch is intentionally small because I wasn't sure if a more
comprehensive fix is wanted.
Regards,
Liam
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] usbhid: tolerate intermittent errors
2026-02-09 10:06 ` Oliver Neukum
2026-02-09 10:49 ` Liam Mitchell
@ 2026-02-09 14:47 ` Alan Stern
1 sibling, 0 replies; 4+ messages in thread
From: Alan Stern @ 2026-02-09 14:47 UTC (permalink / raw)
To: Oliver Neukum
Cc: Liam Mitchell, Jiri Kosina, Benjamin Tissoires, linux-usb,
linux-input, linux-kernel
On Mon, Feb 09, 2026 at 11:06:03AM +0100, Oliver Neukum wrote:
> On 08.02.26 18:10, Liam Mitchell wrote:
> > Modifies the usbhid error handling logic to better handle intermittent
> > errors like EPROTO, which should only need resubmission of URBs and not
> > full device reset.
> >
> > Reduces initial retry delay from 13ms to 1ms. The faster the URB is
> > resubmitted, the lower the chance that user events will be missed.
>
> Hi,
>
> in this case I have to ask the obvious question: Why wait at all?
Because of the possibility that the error was caused by transient
interference that might not go away immediately.
> It would seem to me that if you have spurious or intermittent errors
> the right time to retry is immediately.
It depends on the cause of the errors. In any case, a short delay, such
as 1 ms, should not make much difference.
Alan Stern
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-02-09 14:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-08 17:10 [PATCH] usbhid: tolerate intermittent errors Liam Mitchell
2026-02-09 10:06 ` Oliver Neukum
2026-02-09 10:49 ` Liam Mitchell
2026-02-09 14:47 ` Alan Stern
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox