ACK/Cmnt: [OEM-B/OEM-OSP1-B/B/E/F/U][PATCH 1/1] UBUNTU SAUCE: r8151: check disconnect status after long sleep

You-Sheng Yang vicamo.yang at canonical.com
Tue Mar 10 01:16:48 UTC 2020



On 2020-02-25 23:01, Kleber Souza wrote:
> On 24.02.20 07:58, You-Sheng Yang wrote:
>> BugLink: https://bugs.launchpad.net/bugs/1864284
>>
>> Dell USB Type C docking WD19/WD19DC attaches additional peripherals as:
>>
>>   /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
>>       |__ Port 1: Dev 11, If 0, Class=Hub, Driver=hub/4p, 5000M
>>           |__ Port 3: Dev 12, If 0, Class=Hub, Driver=hub/4p, 5000M
>>           |__ Port 4: Dev 13, If 0, Class=Vendor Specific Class,
>>               Driver=r8152, 5000M
>>
>> where usb 2-1-3 is a hub connecting all USB Type-A/C ports on the dock.
>>
>> When hotplugging such dock with additional usb devices already attached on
>> it, the probing process may reset usb 2.1 port, therefore r8152 ethernet
>> device is also reset. However, during r8152 device init there are several
>> for-loops that, when it's unable to retrieve hardware registers due to
>> being discconected from USB, may take up to 14 seconds each in practice,
>> and that has to be completed before USB may re-enumerate devices on the
>> bus. As a result, devices attached to the dock will only be available
>> after nearly 1 minute after the dock was plugged in:
>>
>>   [ 216.388290] [250] r8152 2-1.4:1.0: usb_probe_interface
>>   [ 216.388292] [250] r8152 2-1.4:1.0: usb_probe_interface - got id
>>   [ 258.830410] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): PHY not ready
>>   [ 258.830460] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Invalid header when reading pass-thru MAC addr
>>   [ 258.830464] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): Get ether addr fail
>>
>> This can be reproduced on all kernel versions up to latest v5.6-rc2, but
>> after v5.5-rc7 the reproduce rate is dramatically lower to 1/30 or so
>> while it was around 1/2.
>>
>> The time consuming for-loops are at:
>> https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L3206
>> https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5400
>> https://elixir.bootlin.com/linux/v5.5/source/drivers/net/usb/r8152.c#L5537
>>
>> Signed-off-by: You-Sheng Yang <vicamo.yang at canonical.com>
> 
> This fix looks contained and simple enough to pull it in before it gets
> accepted by upstream.
> 
> Note to the person applying this, to check the upstream discussion
> thread for updates on the patch:
> 
> https://lore.kernel.org/linux-usb/20200224071541.117363-1-vicamo.yang@canonical.com/

Applied in upstream
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git with a
few commit messages fix.

> Acked-by: Kleber Sacilotto de Souza <kleber.souza at canonical.com>
> 
>> ---
>>  drivers/net/usb/r8152.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
>> index 78ddbaf6401b..95b19ce96513 100644
>> --- a/drivers/net/usb/r8152.c
>> +++ b/drivers/net/usb/r8152.c
>> @@ -3221,6 +3221,8 @@ static u16 r8153_phy_status(struct r8152 *tp, u16 desired)
>>  		}
>>  
>>  		msleep(20);
>> +		if (test_bit(RTL8152_UNPLUG, &tp->flags))
>> +			break;
>>  	}
>>  
>>  	return data;
>> @@ -5402,7 +5404,10 @@ static void r8153_init(struct r8152 *tp)
>>  		if (ocp_read_word(tp, MCU_TYPE_PLA, PLA_BOOT_CTRL) &
>>  		    AUTOLOAD_DONE)
>>  			break;
>> +
>>  		msleep(20);
>> +		if (test_bit(RTL8152_UNPLUG, &tp->flags))
>> +			break;
>>  	}
>>  
>>  	data = r8153_phy_status(tp, 0);
>> @@ -5539,7 +5544,10 @@ static void r8153b_init(struct r8152 *tp)
>>  		if (ocp_read_word(tp, MCU_TYPE_PLA, PLA_BOOT_CTRL) &
>>  		    AUTOLOAD_DONE)
>>  			break;
>> +
>>  		msleep(20);
>> +		if (test_bit(RTL8152_UNPLUG, &tp->flags))
>> +			break;
>>  	}
>>  
>>  	data = r8153_phy_status(tp, 0);
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20200310/ad83ee87/attachment.sig>


More information about the kernel-team mailing list