| Message ID | 20231020140655.v5.1.I6e4fb5ae61b4c6ab32058cb12228fd5bd32da676@changeid (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | a5feba71ec9c14a54c3babdc732c5b6866d8ee43 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | r8152: Avoid writing garbage to the adapter's registers | expand |
On Fri, Oct 20, 2023 at 2:08 PM Douglas Anderson <dianders@chromium.org> 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: Grant Grundler <grundler@chromium.org> > --- > > (no changes since v1) > > drivers/net/usb/r8152.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c > index 0c13d9950cd8..482957beae66 100644 > --- a/drivers/net/usb/r8152.c > +++ b/drivers/net/usb/r8152.c > @@ -1212,7 +1212,7 @@ int get_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data) > > ret = usb_control_msg(tp->udev, tp->pipe_ctrl_in, > RTL8152_REQ_GET_REGS, RTL8152_REQT_READ, > - value, index, tmp, size, 500); > + value, index, tmp, size, USB_CTRL_GET_TIMEOUT); > if (ret < 0) > memset(data, 0xff, size); > else > @@ -1235,7 +1235,7 @@ int set_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data) > > ret = usb_control_msg(tp->udev, tp->pipe_ctrl_out, > RTL8152_REQ_SET_REGS, RTL8152_REQT_WRITE, > - value, index, tmp, size, 500); > + value, index, tmp, size, USB_CTRL_SET_TIMEOUT); > > kfree(tmp); > > @@ -9494,7 +9494,8 @@ static u8 __rtl_get_hw_ver(struct usb_device *udev) > > ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), > RTL8152_REQ_GET_REGS, RTL8152_REQT_READ, > - PLA_TCR0, MCU_TYPE_PLA, tmp, sizeof(*tmp), 500); > + PLA_TCR0, MCU_TYPE_PLA, tmp, sizeof(*tmp), > + USB_CTRL_GET_TIMEOUT); > if (ret > 0) > ocp_data = (__le32_to_cpu(*tmp) >> 16) & VERSION_MASK; > > -- > 2.42.0.758.gaed0368e0e-goog >
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>
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 0c13d9950cd8..482957beae66 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -1212,7 +1212,7 @@ int get_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data) ret = usb_control_msg(tp->udev, tp->pipe_ctrl_in, RTL8152_REQ_GET_REGS, RTL8152_REQT_READ, - value, index, tmp, size, 500); + value, index, tmp, size, USB_CTRL_GET_TIMEOUT); if (ret < 0) memset(data, 0xff, size); else @@ -1235,7 +1235,7 @@ int set_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data) ret = usb_control_msg(tp->udev, tp->pipe_ctrl_out, RTL8152_REQ_SET_REGS, RTL8152_REQT_WRITE, - value, index, tmp, size, 500); + value, index, tmp, size, USB_CTRL_SET_TIMEOUT); kfree(tmp); @@ -9494,7 +9494,8 @@ static u8 __rtl_get_hw_ver(struct usb_device *udev) ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), RTL8152_REQ_GET_REGS, RTL8152_REQT_READ, - PLA_TCR0, MCU_TYPE_PLA, tmp, sizeof(*tmp), 500); + PLA_TCR0, MCU_TYPE_PLA, tmp, sizeof(*tmp), + USB_CTRL_GET_TIMEOUT); if (ret > 0) ocp_data = (__le32_to_cpu(*tmp) >> 16) & VERSION_MASK;
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> --- (no changes since v1) drivers/net/usb/r8152.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)