From: Florian Fainelli <f.fainelli@gmail.com>
To: Douglas Anderson <dianders@chromium.org>,
Jakub Kicinski <kuba@kernel.org>,
Hayes Wang <hayeswang@realtek.com>,
"David S . Miller" <davem@davemloft.net>
Cc: "Edward Hill" <ecgh@chromium.org>,
"Laura Nao" <laura.nao@collabora.com>,
"Alan Stern" <stern@rowland.harvard.edu>,
"Simon Horman" <horms@kernel.org>,
linux-usb@vger.kernel.org,
"Grant Grundler" <grundler@chromium.org>,
"Bjørn Mork" <bjorn@mork.no>,
"Eric Dumazet" <edumazet@google.com>,
"Paolo Abeni" <pabeni@redhat.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v5 1/8] r8152: Increase USB control msg timeout to 5000ms as per spec
Date: Mon, 23 Oct 2023 18:23:37 -0700 [thread overview]
Message-ID: <2f12beb1-ff94-4806-8ed7-e78eb8474a7d@gmail.com> (raw)
In-Reply-To: <20231020140655.v5.1.I6e4fb5ae61b4c6ab32058cb12228fd5bd32da676@changeid>
On 10/20/2023 2:06 PM, Douglas Anderson wrote:
> According to the comment next to USB_CTRL_GET_TIMEOUT and
> USB_CTRL_SET_TIMEOUT, although sending/receiving control messages is
> usually quite fast, the spec allows them to take up to 5 seconds.
> Let's increase the timeout in the Realtek driver from 500ms to 5000ms
> (using the #defines) to account for this.
>
> This is not just a theoretical change. The need for the longer timeout
> was seen in testing. Specifically, if you drop a sc7180-trogdor based
> Chromebook into the kdb debugger and then "go" again after sitting in
> the debugger for a while, the next USB control message takes a long
> time. Out of ~40 tests the slowest USB control message was 4.5
> seconds.
>
> While dropping into kdb is not exactly an end-user scenario, the above
> is similar to what could happen due to an temporary interrupt storm,
> what could happen if there was a host controller (HW or SW) issue, or
> what could happen if the Realtek device got into a confused state and
> needed time to recover.
>
> This change is fairly critical since the r8152 driver in Linux doesn't
> expect register reads/writes (which are backed by USB control
> messages) to fail.
>
> Fixes: ac718b69301c ("net/usb: new driver for RTL8152")
> Suggested-by: Hayes Wang <hayeswang@realtek.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
next prev parent reply other threads:[~2023-10-24 1:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-20 21:06 [PATCH v5 0/8] r8152: Avoid writing garbage to the adapter's registers Douglas Anderson
2023-10-20 21:06 ` [PATCH v5 1/8] r8152: Increase USB control msg timeout to 5000ms as per spec Douglas Anderson
2023-10-21 14:48 ` Grant Grundler
2023-10-24 1:23 ` Florian Fainelli [this message]
2023-10-20 21:06 ` [PATCH v5 2/8] r8152: Run the unload routine if we have errors during probe Douglas Anderson
2023-10-21 14:50 ` Grant Grundler
2023-10-24 1:24 ` Florian Fainelli
2023-10-20 21:06 ` [PATCH v5 3/8] r8152: Cancel hw_phy_work if we have an error in probe Douglas Anderson
2023-10-21 14:52 ` Grant Grundler
2023-10-24 1:24 ` Florian Fainelli
2023-10-20 21:06 ` [PATCH v5 4/8] r8152: Release firmware " Douglas Anderson
2023-10-21 15:01 ` Grant Grundler
2023-10-24 1:25 ` Florian Fainelli
2023-10-20 21:06 ` [PATCH v5 5/8] r8152: Check for unplug in rtl_phy_patch_request() Douglas Anderson
2023-10-21 15:03 ` Grant Grundler
2023-10-24 1:25 ` Florian Fainelli
2023-10-20 21:06 ` [PATCH v5 6/8] r8152: Check for unplug in r8153b_ups_en() / r8153c_ups_en() Douglas Anderson
2023-10-21 15:05 ` Grant Grundler
2023-10-24 1:25 ` Florian Fainelli
2023-10-20 21:06 ` [PATCH v5 7/8] r8152: Rename RTL8152_UNPLUG to RTL8152_INACCESSIBLE Douglas Anderson
2023-10-21 15:06 ` Grant Grundler
2023-10-24 1:26 ` Florian Fainelli
2023-10-20 21:06 ` [PATCH v5 8/8] r8152: Block future register access if register access fails Douglas Anderson
2023-10-21 15:35 ` Grant Grundler
2023-10-25 16:28 ` Simon Horman
2023-10-25 20:24 ` Doug Anderson
2023-11-03 16:52 ` Simon Horman
2023-10-22 10:50 ` [PATCH v5 0/8] r8152: Avoid writing garbage to the adapter's registers patchwork-bot+netdevbpf
2023-10-24 1:27 ` Florian Fainelli
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=2f12beb1-ff94-4806-8ed7-e78eb8474a7d@gmail.com \
--to=f.fainelli@gmail.com \
--cc=bjorn@mork.no \
--cc=davem@davemloft.net \
--cc=dianders@chromium.org \
--cc=ecgh@chromium.org \
--cc=edumazet@google.com \
--cc=grundler@chromium.org \
--cc=hayeswang@realtek.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=laura.nao@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stern@rowland.harvard.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.