RE: r8152: data corruption in various scenarios

[Mario.Limonciello]

> -----Original Message-----
> From: Mark Lord <mlord@xxxxxxxxx>
> Sent: Monday, January 7, 2019 12:06 PM
> To: Limonciello, Mario; hayeswang@xxxxxxxxxxx; kai.heng.feng@xxxxxxxxxxxxx
> Cc: aatteka@xxxxxxxxxx; davem@xxxxxxxxxxxxx; greg@xxxxxxxxx;
> romieu@xxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; nic_swsd@xxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; ryankao@xxxxxxxxxxx
> Subject: Re: r8152: data corruption in various scenarios
> 
> 
> [EXTERNAL EMAIL]
> 
> On 2019-01-07 11:01 a.m., Mario.Limonciello@xxxxxxxx wrote:
> >
> > TB16 contains ASMedia host controller.  It's a Thunderbolt dock and all USB
> devices
> > are connected to ASMedia host controller in the dock.
> >
> > WD15 does not contain an ASMedia host controller, it connected to system's
> > USB host controller.
> 
> 
> Thank-you, Mario.
> 
> So.. why are we enabling the r8153 (USB-ethernet) workaround on this WD15
> dock?
> The discussion back in 2017 was that only the TB15/TB16 were affected by
> the XHCI overruns it produces?
> 
> --

The xHCI overrun workaround should only be applied on TB16/TB16, correct.

Can you double check the verbose information from lsusb for the r8153 device
on your WD15?

I just double checked on my on hand WD15 with an XPS 9380 and it's not activating the
quirk (bcdDevice was different).

If it's the same information as the TB16 (which it sounds like it is) Kai Heng and I will check
around internally to find out why they're looking the same.

I can hypothesize a few guesses of what happened.
My first guess would be a comparison issue with the logic in 176eb614b.

Looking at that commit, I guess I would ask on the compiler behavior of !strcmp().
Would that be matching the less than case as well as the zero case?
If so, it might need to be changed to strcmp() == 0.

My second guess would be maybe newer ethernet NVM in manufacturing.
My third guess would be a manufacturing issue putting wrong NVM image on your WD15.