linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Lauri Jakku <lja@iki.fi>
Cc: oneukum@suse.com, benjamin.tissoires@redhat.com,
	jikos@kernel.org, linux-input@vger.kernel.org,
	linux-usb@vger.kernel.org
Subject: Re: [PATCH v5] USB: HID: random timeout failures tackle try.
Date: Tue, 4 Feb 2020 18:11:15 +0000	[thread overview]
Message-ID: <20200204181115.GA1115743@kroah.com> (raw)
In-Reply-To: <20200204175238.3817-1-lja@iki.fi>

On Tue, Feb 04, 2020 at 07:52:39PM +0200, Lauri Jakku wrote:
> -- v1 ------------------------------------------------------------
> send, 20ms apart, control messages, if error is timeout.
> 
> There is multiple reports of random behaviour of USB HID devices.
> 
> I have mouse that acts sometimes quite randomly, I debugged with
> logs others have published that there is HW timeouts that leave
> device in state that it is errorneus.
> 
> To fix this I introduced retry mechanism in root of USB HID drivers.
> 
> Fix does not slow down operations at all if there is no -ETIMEDOUT
> got from control message sending. If there is one, then sleep 20ms
> and try again. Retry count is 20 witch translates maximium of 400ms
> before giving up.
> 
> NOTE: This does not sleep anymore then before, if all is golden.
> 
> -- v2 ------------------------------------------------------------
> 
> If there is timeout, then sleep 20ms and try again. Retry count is 20
> witch translates maximium of 400ms before giving up. If the 400ms
> boundary is reached the HW is really bad.
> 
> JUST to be clear:
>     This does not make USB HID devices to sleep anymore than
>     before, if all is golden.
> 
> Why modify usb-hid-core: No need to modify driver by driver.
> 
> -- v3 ------------------------------------------------------------
> 
> Timeout given is divided by 100, but taken care that it is always
> at least 10ms.
> 
> so total time in common worst-case-scenario is:
> 
>  sleep of 20ms + common timeout divided by 100 (50ms) makes
>  70ms per loop, 20 loops => 1.4sec .
> 
> -- v4 ------------------------------------------------------------
> No changes in code, just elaborating what is done in v[1,2,3].
> 
> -- v5 ------------------------------------------------------------
> changes in code: what the build robot found:
>    drivers/usb/core/message.c: In function 'usb_control_msg':
> >> drivers/usb/core/message.c:173:11: error: type defaults to 'int' \
>      in declaration of 'timeout_happened' [-Werror=implicit-int]
>        static timeout_happened = 0;
>               ^~~~~~~~~~~~~~~~
>    cc1: some warnings being treated as errors
> 
> Fix done: added int to declaration.

Um, please read the documentation for how to do versioning of patches.
Or look at examples on the mailing list for this as well.  What you have
here will unfortunately not work at all.

thanks,

greg k-h

  parent reply	other threads:[~2020-02-04 18:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04 17:52 [PATCH v5] USB: HID: random timeout failures tackle try Lauri Jakku
2020-02-04 18:07 ` Alan Stern
2020-02-04 20:14   ` Lauri Jakku
2020-02-04 18:11 ` Greg KH [this message]
2020-02-04 18:15 ` Greg KH
2020-02-04 20:05   ` Lauri Jakku
2020-02-05 10:03 ` Oliver Neukum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200204181115.GA1115743@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lja@iki.fi \
    --cc=oneukum@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).