r8152: Increase USB control msg timeout to 5000ms as per spec
authorDouglas Anderson <dianders@chromium.org>
Fri, 20 Oct 2023 21:06:52 +0000 (14:06 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 2 Nov 2023 08:35:27 +0000 (09:35 +0100)
commitee73f937c5e9be8d7f778e9fbf383d3cee2292ea
tree782c86e2307721ef86acaf40d15cc06b124ae732
parent9eb275fec60252c7b461cc629a7e83f084c7e08b
r8152: Increase USB control msg timeout to 5000ms as per spec

[ Upstream commit a5feba71ec9c14a54c3babdc732c5b6866d8ee43 ]

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: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/net/usb/r8152.c