lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171124082805.GA22586@kroah.com>
Date:   Fri, 24 Nov 2017 09:28:05 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Kai Heng Feng <kai.heng.feng@...onical.com>
Cc:     David Miller <davem@...emloft.net>, hayeswang@...ltek.co,
        linux-usb@...r.kernel.org, netdev@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Mario Limonciello <mario.limonciello@...l.com>
Subject: Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock

On Fri, Nov 24, 2017 at 11:44:02AM +0800, Kai Heng Feng wrote:
> 
> 
> > On 23 Nov 2017, at 5:24 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> > 
> > On Thu, Nov 23, 2017 at 04:53:41PM +0800, Kai Heng Feng wrote:
> >> 
> >> What I want to do here is to finding this connection:
> >> Realtek r8153 <-> SMSC hub (USD ID: 0424:5537) <-> 
> >> ASMedia XHCI controller (PCI ID: 1b21:1142).
> >> 
> >> Is there a safer way to do this?
> > 
> > Nope!  You can't do that at all from within a USB driver, sorry.  As you
> > really should not care at all :)
> 
> Got it :)
> 
> The r8153 in Dell TB dock has version information, RTL_VER_05.
> We can use it to check for workaround, but many working RTL_VER_05 devices
> will also be affected.
> Do you think it’s an acceptable compromise?

I think all of the users of this device that is working just fine for
them would not like that to happen :(

> >> I have a r8153 <-> USB 3.0 dongle which work just fine. I can’t find any 
> >> information to differentiate them. Hence I want to use the connection to
> >> identify if r8153 is on a Dell TB dock.
> > 
> > Are you sure there is nothing different in the version or release number
> > of the device?  'lsusb -v' shows the exact same information for both
> > devices?
> 
> Yes. I attached `lsusb -v` for r8153 on Dell TB dock, on a RJ45 <-> USB 3.0 dongle,
> and on a RJ45 <-> USB Type-C dongle.

The bcdDevice is different between the dock device and the "real"
device, why not use that?

> >> Yes. From what I know, ASMedia is working on it, but not sure how long it
> >> will take. In the meantime, I’d like to workaround this issue for the users.
> > 
> > Again, it's a host controller bug, it should be fixed there, don't try
> > to paper over the real issue in different individual drivers.
> > 
> > I think I've seen various patches on the linux-usb list for this
> > controller already, have you tried them?
> 
> Yes. These patches are all in mainline Linux now.

Then there is still a bug.  Who as ASMedia is working on this, have they
posted anything to the linux-usb mailing list about it?

> >> Actually no.
> >> I just plugged r8153 dongle into the same hub, surprisingly the issue
> >> doesn’t happen in this scenario.
> > 
> > Then something seems to be wrong with the device itself, as that would
> > be the same exact electrical/logical path, right?
> 
> I have no idea why externally plugged one doesn’t have this issue.
> Maybe it’s related how it’s wired inside the Dell TB dock...

Maybe.  Have you tried using usbmon to see what the data streams are for
the two devices and where they have problems and diverge?  Is the dock
device doing something different in response to something from the host
that the "real" device does not do?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ