aboutsummaryrefslogtreecommitdiff
path: root/lib/crypto/mpi/mpiutil.c
diff options
context:
space:
mode:
authorDouglas Anderson <dianders@chromium.org>2023-10-20 14:06:52 -0700
committerDavid S. Miller <davem@davemloft.net>2023-10-22 11:46:17 +0100
commita5feba71ec9c14a54c3babdc732c5b6866d8ee43 (patch)
treea69c8de6c4050d34398a1e7a173a5a10d2d5a356 /lib/crypto/mpi/mpiutil.c
parent51a32e828109b4a209efde44505baa356b37a4ce (diff)
r8152: Increase USB control msg timeout to 5000ms as per spec
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>
Diffstat (limited to 'lib/crypto/mpi/mpiutil.c')
0 files changed, 0 insertions, 0 deletions