[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Jun 2023 15:27:37 +0200 (CEST)
From: Jiri Kosina <jikos@...nel.org>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
cc: Bastien Nocera <hadess@...ess.net>, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
"Peter F . Patel-Schneider" <pfpschneider@...il.com>,
Filipe LaĆns <lains@...eup.net>,
Nestor Lopez Casado <nlopezcasad@...itech.com>,
Mark Lord <mlord@...ox.com>
Subject: Re: [PATCH] HID: logitech-hidpp: Handle timeout differently from
busy
On Mon, 5 Jun 2023, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>> If an attempt at contacting a receiver or a device fails because the
> >>> receiver or device never responds, don't restart the communication, only
> >>> restart it if the receiver or device answers that it's busy, as originally
> >>> intended.
> >>>
> >>> This was the behaviour on communication timeout before commit 586e8fede795
> >>> ("HID: logitech-hidpp: Retry commands when device is busy").
> >>>
> >>> This fixes some overly long waits in a critical path on boot, when
> >>> checking whether the device is connected by getting its HID++ version.
> >>>
> >>> Signed-off-by: Bastien Nocera <hadess@...ess.net>
> >>> Suggested-by: Mark Lord <mlord@...ox.com>
> >>> Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy")
> >>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412
> > [...]
> >>
> >> I have applied this even before getting confirmation from the reporters in
> >> bugzilla, as it's the right thing to do anyway.
> >
> > Unfortunately it doesn't seem to cure the reported issue (while reverting
> > 586e8fede79 does):
>
> BTW, remind me again: was fixing this by reverting 586e8fede79 for now a
> option? I guess it's not, but if I'm wrong I wonder if that might at
> this point be the best way forward.
This should now all be fixed by
https://git.kernel.org/linus/7c28afd5512e371773dbb2bf95a31ed5625651d9
> > https://bugzilla.kernel.org/show_bug.cgi?id=217523#c2
>
> FWIW, another comment showed up there:
>
> ```
> > --- Comment #6 from vova7890 ---
> > Same problem. I researched this some time ago. I noticed that if I add a small
> > delay between commands to the dongle - everything goes fine. Repeated
> > request(586e8fede7953b1695b5ccc6112eff9b052e79ac) made the situation more
> > visible
>
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists