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@xxxxxxxxxx>
> >>> Suggested-by: Mark Lord <mlord@xxxxxxxxx>
> >>> 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
