Patch "r8152: Increase USB control msg timeout to 5000ms as per spec" has been added to the 5.4-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    r8152: Increase USB control msg timeout to 5000ms as per spec

to the 5.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     r8152-increase-usb-control-msg-timeout-to-5000ms-as-.patch
and it can be found in the queue-5.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit a59209469a674eb82268f81db7fd267ed59cb202
Author: Douglas Anderson <dianders@xxxxxxxxxxxx>
Date:   Fri Oct 20 14:06:52 2023 -0700

    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@xxxxxxxxxxx>
    Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
    Reviewed-by: Grant Grundler <grundler@xxxxxxxxxxxx>
    Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a19f0431e6f99..fa13a19e844c1 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -850,7 +850,7 @@ int get_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data)
 
 	ret = usb_control_msg(tp->udev, usb_rcvctrlpipe(tp->udev, 0),
 			      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
@@ -873,7 +873,7 @@ int set_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data)
 
 	ret = usb_control_msg(tp->udev, usb_sndctrlpipe(tp->udev, 0),
 			      RTL8152_REQ_SET_REGS, RTL8152_REQT_WRITE,
-			      value, index, tmp, size, 500);
+			      value, index, tmp, size, USB_CTRL_SET_TIMEOUT);
 
 	kfree(tmp);
 
@@ -5584,7 +5584,8 @@ static u8 rtl_get_version(struct usb_interface *intf)
 
 	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;
 



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux