* [PATCH] r8152: disable rx checksum offload on Dell TB dock @ 2017-11-23 6:38 Kai-Heng Feng 2017-11-23 7:58 ` Greg KH 0 siblings, 1 reply; 12+ messages in thread From: Kai-Heng Feng @ 2017-11-23 6:38 UTC (permalink / raw) To: davem Cc: hayeswang, linux-usb, netdev, linux-kernel, Kai-Heng Feng, Mario Limonciello r8153 on Dell TB dock corrupts rx packets. The root cause is not found yet, but disabling rx checksumming can workaround the issue. We can use this connection to decide if it's a Dell TB dock: Realtek r8153 <-> SMSC hub <-> ASMedia XHCI controller BugLink: https://bugs.launchpad.net/bugs/1729674 Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> --- drivers/net/usb/r8152.c | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index d51d9abf7986..58b80b5e7803 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -27,6 +27,8 @@ #include <linux/usb/cdc.h> #include <linux/suspend.h> #include <linux/acpi.h> +#include <linux/pci.h> +#include <linux/usb/hcd.h> /* Information for net-next */ #define NETNEXT_VERSION "09" @@ -5135,6 +5137,35 @@ static u8 rtl_get_version(struct usb_interface *intf) return version; } +/* Ethernet on Dell TB 15/16 dock is connected this way: + * Realtek r8153 <-> SMSC hub <-> ASMedia XHCI controller + * We use this connection to make sure r8153 is on the Dell TB dock. + */ +static bool check_dell_tb_dock(struct usb_device *udev) +{ + struct usb_device *hub = udev->parent; + struct usb_device *root_hub; + struct pci_dev *controller; + + if (!hub) + return false; + + if (!(le16_to_cpu(hub->descriptor.idVendor) == 0x0424 && + le16_to_cpu(hub->descriptor.idProduct) == 0x5537)) + return false; + + root_hub = hub->parent; + if (!root_hub || root_hub->parent) + return false; + + controller = to_pci_dev(bus_to_hcd(root_hub->bus)->self.controller); + + if (controller->vendor == 0x1b21 && controller->device == 0x1142) + return true; + + return false; +} + static int rtl8152_probe(struct usb_interface *intf, const struct usb_device_id *id) { @@ -5202,7 +5233,7 @@ static int rtl8152_probe(struct usb_interface *intf, NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | NETIF_F_IPV6_CSUM | NETIF_F_TSO6; - if (tp->version == RTL_VER_01) { + if (tp->version == RTL_VER_01 || check_dell_tb_dock(udev)) { netdev->features &= ~NETIF_F_RXCSUM; netdev->hw_features &= ~NETIF_F_RXCSUM; } -- 2.14.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock 2017-11-23 6:38 [PATCH] r8152: disable rx checksum offload on Dell TB dock Kai-Heng Feng @ 2017-11-23 7:58 ` Greg KH 2017-11-23 8:53 ` Kai Heng Feng 0 siblings, 1 reply; 12+ messages in thread From: Greg KH @ 2017-11-23 7:58 UTC (permalink / raw) To: Kai-Heng Feng Cc: davem, hayeswang, linux-usb, netdev, linux-kernel, Mario Limonciello On Thu, Nov 23, 2017 at 01:38:38AM -0500, Kai-Heng Feng wrote: > r8153 on Dell TB dock corrupts rx packets. > > The root cause is not found yet, but disabling rx checksumming can > workaround the issue. We can use this connection to decide if it's > a Dell TB dock: > Realtek r8153 <-> SMSC hub <-> ASMedia XHCI controller > > BugLink: https://bugs.launchpad.net/bugs/1729674 > Cc: Mario Limonciello <mario.limonciello@dell.com> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> > --- > drivers/net/usb/r8152.c | 33 ++++++++++++++++++++++++++++++++- > 1 file changed, 32 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c > index d51d9abf7986..58b80b5e7803 100644 > --- a/drivers/net/usb/r8152.c > +++ b/drivers/net/usb/r8152.c > @@ -27,6 +27,8 @@ > #include <linux/usb/cdc.h> > #include <linux/suspend.h> > #include <linux/acpi.h> > +#include <linux/pci.h> > +#include <linux/usb/hcd.h> > > /* Information for net-next */ > #define NETNEXT_VERSION "09" > @@ -5135,6 +5137,35 @@ static u8 rtl_get_version(struct usb_interface *intf) > return version; > } > > +/* Ethernet on Dell TB 15/16 dock is connected this way: > + * Realtek r8153 <-> SMSC hub <-> ASMedia XHCI controller > + * We use this connection to make sure r8153 is on the Dell TB dock. > + */ > +static bool check_dell_tb_dock(struct usb_device *udev) > +{ > + struct usb_device *hub = udev->parent; > + struct usb_device *root_hub; > + struct pci_dev *controller; > + > + if (!hub) > + return false; > + > + if (!(le16_to_cpu(hub->descriptor.idVendor) == 0x0424 && > + le16_to_cpu(hub->descriptor.idProduct) == 0x5537)) > + return false; > + > + root_hub = hub->parent; > + if (!root_hub || root_hub->parent) > + return false; > + > + controller = to_pci_dev(bus_to_hcd(root_hub->bus)->self.controller); That's a very scary, and dangerous, cast. You can not ever be sure that the hub really is a "root hub" like this. > + if (controller->vendor == 0x1b21 && controller->device == 0x1142) > + return true; Why can't you just look at the USB device itself and go off of a quirk in it? Something like a version or string or something else? This sounds like a USB host controller issue, not a USB device issue, can't we fix the "real" problem here instead of this crazy work-around? Odds are any device plugged into the hub should have the same issue, right? thanks, greg k-h ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock 2017-11-23 7:58 ` Greg KH @ 2017-11-23 8:53 ` Kai Heng Feng 2017-11-23 9:24 ` Greg KH 0 siblings, 1 reply; 12+ messages in thread From: Kai Heng Feng @ 2017-11-23 8:53 UTC (permalink / raw) To: Greg KH Cc: David Miller, hayeswang, linux-usb, netdev, LKML, Mario Limonciello > On 23 Nov 2017, at 3:58 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Thu, Nov 23, 2017 at 01:38:38AM -0500, Kai-Heng Feng wrote: >> r8153 on Dell TB dock corrupts rx packets. >> >> The root cause is not found yet, but disabling rx checksumming can >> workaround the issue. We can use this connection to decide if it's >> a Dell TB dock: >> Realtek r8153 <-> SMSC hub <-> ASMedia XHCI controller >> >> BugLink: https://bugs.launchpad.net/bugs/1729674 >> Cc: Mario Limonciello <mario.limonciello@dell.com> >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> >> --- >> drivers/net/usb/r8152.c | 33 ++++++++++++++++++++++++++++++++- >> 1 file changed, 32 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c >> index d51d9abf7986..58b80b5e7803 100644 >> --- a/drivers/net/usb/r8152.c >> +++ b/drivers/net/usb/r8152.c >> @@ -27,6 +27,8 @@ >> #include <linux/usb/cdc.h> >> #include <linux/suspend.h> >> #include <linux/acpi.h> >> +#include <linux/pci.h> >> +#include <linux/usb/hcd.h> >> >> /* Information for net-next */ >> #define NETNEXT_VERSION "09" >> @@ -5135,6 +5137,35 @@ static u8 rtl_get_version(struct usb_interface *intf) >> return version; >> } >> >> +/* Ethernet on Dell TB 15/16 dock is connected this way: >> + * Realtek r8153 <-> SMSC hub <-> ASMedia XHCI controller >> + * We use this connection to make sure r8153 is on the Dell TB dock. >> + */ >> +static bool check_dell_tb_dock(struct usb_device *udev) >> +{ >> + struct usb_device *hub = udev->parent; >> + struct usb_device *root_hub; >> + struct pci_dev *controller; >> + >> + if (!hub) >> + return false; >> + >> + if (!(le16_to_cpu(hub->descriptor.idVendor) == 0x0424 && >> + le16_to_cpu(hub->descriptor.idProduct) == 0x5537)) >> + return false; >> + >> + root_hub = hub->parent; >> + if (!root_hub || root_hub->parent) >> + return false; >> + >> + controller = to_pci_dev(bus_to_hcd(root_hub->bus)->self.controller); > > That's a very scary, and dangerous, cast. You can not ever be sure that > the hub really is a "root hub" like this. 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? > >> + if (controller->vendor == 0x1b21 && controller->device == 0x1142) >> + return true; > > Why can't you just look at the USB device itself and go off of a quirk > in it? Something like a version or string or something else? 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. > > This sounds like a USB host controller issue, not a USB device issue, > can't we fix the "real" problem here instead of this crazy work-around? 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. > Odds are any device plugged into the hub should have the same issue, > right? Actually no. I just plugged r8153 dongle into the same hub, surprisingly the issue doesn’t happen in this scenario. Kai-Heng > > thanks, > > greg k-h ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock 2017-11-23 8:53 ` Kai Heng Feng @ 2017-11-23 9:24 ` Greg KH 2017-11-24 3:44 ` Kai Heng Feng 0 siblings, 1 reply; 12+ messages in thread From: Greg KH @ 2017-11-23 9:24 UTC (permalink / raw) To: Kai Heng Feng Cc: David Miller, hayeswang, linux-usb, netdev, LKML, Mario Limonciello On Thu, Nov 23, 2017 at 04:53:41PM +0800, Kai Heng Feng wrote: > > > On 23 Nov 2017, at 3:58 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > > > > On Thu, Nov 23, 2017 at 01:38:38AM -0500, Kai-Heng Feng wrote: > >> r8153 on Dell TB dock corrupts rx packets. > >> > >> The root cause is not found yet, but disabling rx checksumming can > >> workaround the issue. We can use this connection to decide if it's > >> a Dell TB dock: > >> Realtek r8153 <-> SMSC hub <-> ASMedia XHCI controller > >> > >> BugLink: https://bugs.launchpad.net/bugs/1729674 > >> Cc: Mario Limonciello <mario.limonciello@dell.com> > >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> > >> --- > >> drivers/net/usb/r8152.c | 33 ++++++++++++++++++++++++++++++++- > >> 1 file changed, 32 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c > >> index d51d9abf7986..58b80b5e7803 100644 > >> --- a/drivers/net/usb/r8152.c > >> +++ b/drivers/net/usb/r8152.c > >> @@ -27,6 +27,8 @@ > >> #include <linux/usb/cdc.h> > >> #include <linux/suspend.h> > >> #include <linux/acpi.h> > >> +#include <linux/pci.h> > >> +#include <linux/usb/hcd.h> > >> > >> /* Information for net-next */ > >> #define NETNEXT_VERSION "09" > >> @@ -5135,6 +5137,35 @@ static u8 rtl_get_version(struct usb_interface *intf) > >> return version; > >> } > >> > >> +/* Ethernet on Dell TB 15/16 dock is connected this way: > >> + * Realtek r8153 <-> SMSC hub <-> ASMedia XHCI controller > >> + * We use this connection to make sure r8153 is on the Dell TB dock. > >> + */ > >> +static bool check_dell_tb_dock(struct usb_device *udev) > >> +{ > >> + struct usb_device *hub = udev->parent; > >> + struct usb_device *root_hub; > >> + struct pci_dev *controller; > >> + > >> + if (!hub) > >> + return false; > >> + > >> + if (!(le16_to_cpu(hub->descriptor.idVendor) == 0x0424 && > >> + le16_to_cpu(hub->descriptor.idProduct) == 0x5537)) > >> + return false; > >> + > >> + root_hub = hub->parent; > >> + if (!root_hub || root_hub->parent) > >> + return false; > >> + > >> + controller = to_pci_dev(bus_to_hcd(root_hub->bus)->self.controller); > > > > That's a very scary, and dangerous, cast. You can not ever be sure that > > the hub really is a "root hub" like this. > > 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 :) > >> + if (controller->vendor == 0x1b21 && controller->device == 0x1142) > >> + return true; > > > > Why can't you just look at the USB device itself and go off of a quirk > > in it? Something like a version or string or something else? > > 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? > > This sounds like a USB host controller issue, not a USB device issue, > > can't we fix the "real" problem here instead of this crazy work-around? > > 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? > > Odds are any device plugged into the hub should have the same issue, > > right? > > 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? thanks, greg k-h ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock 2017-11-23 9:24 ` Greg KH @ 2017-11-24 3:44 ` Kai Heng Feng 2017-11-24 8:28 ` Greg KH 2017-11-27 15:13 ` Mario.Limonciello 0 siblings, 2 replies; 12+ messages in thread From: Kai Heng Feng @ 2017-11-24 3:44 UTC (permalink / raw) To: Greg KH Cc: David Miller, hayeswang, linux-usb, netdev, LKML, Mario Limonciello [-- Attachment #1: Type: text/plain, Size: 2083 bytes --] > On 23 Nov 2017, at 5:24 PM, Greg KH <gregkh@linuxfoundation.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 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. >> 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. >> 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... Kai-Heng [-- Attachment #2: lsusb-a --] [-- Type: application/octet-stream, Size: 6414 bytes --] Bus 004 Device 008: ID 0bda:8153 Realtek Semiconductor Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x8153 bcdDevice 30.00 iManufacturer 1 Realtek iProduct 2 USB 10/100/1000 LAN iSerial 6 000001000000 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 57 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 64mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 8 bMaxBurst 0 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 98 bNumInterfaces 2 bConfigurationValue 2 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 64mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 6 Ethernet Networking bInterfaceProtocol 0 iInterface 5 CDC Communications Control CDC Header: bcdCDC 1.10 CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC Ethernet: iMacAddress 3 9CEBE817AA5A bmEthernetStatistics 0x00000000 wMaxSegmentSize 1514 wNumberMCFilters 0x0000 bNumberPowerFilters 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 8 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 4 Ethernet Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x02 Latency Tolerance Messages (LTM) Supported wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 2 Lowest fully-functional device speed is High Speed (480Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds Device Status: 0x0000 (Bus Powered) [-- Attachment #3: lsusb-c --] [-- Type: application/octet-stream, Size: 6484 bytes --] Bus 006 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x8153 bcdDevice 30.00 iManufacturer 1 Realtek iProduct 2 USB 10/100/1000 LAN iSerial 6 000001000000 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 57 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 64mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 8 bMaxBurst 0 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 98 bNumInterfaces 2 bConfigurationValue 2 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 64mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 6 Ethernet Networking bInterfaceProtocol 0 iInterface 5 CDC Communications Control CDC Header: bcdCDC 1.10 CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC Ethernet: iMacAddress 3 9CEBE830B8E0 bmEthernetStatistics 0x00000000 wMaxSegmentSize 1514 wNumberMCFilters 0x0000 bNumberPowerFilters 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 8 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 4 Ethernet Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x02 Latency Tolerance Messages (LTM) Supported wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 2 Lowest fully-functional device speed is High Speed (480Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds Device Status: 0x001c (Bus Powered) U1 Enabled U2 Enabled Latency Tolerance Messaging (LTM) Enabled [-- Attachment #4: lsusb-dock --] [-- Type: application/octet-stream, Size: 6414 bytes --] Bus 004 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x8153 bcdDevice 30.01 iManufacturer 1 Realtek iProduct 2 USB 10/100/1000 LAN iSerial 6 000001000000 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 57 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 64mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 8 bMaxBurst 0 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 98 bNumInterfaces 2 bConfigurationValue 2 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 64mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 6 Ethernet Networking bInterfaceProtocol 0 iInterface 5 CDC Communications Control CDC Header: bcdCDC 1.10 CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC Ethernet: iMacAddress 3 F8CAB847C234 bmEthernetStatistics 0x00000000 wMaxSegmentSize 1514 wNumberMCFilters 0x0000 bNumberPowerFilters 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 8 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 4 Ethernet Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 3 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 22 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x02 Latency Tolerance Messages (LTM) Supported wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 2 Lowest fully-functional device speed is High Speed (480Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 2047 micro seconds Device Status: 0x0000 (Bus Powered) [-- Attachment #5: Type: text/plain, Size: 26 bytes --] > thanks, > > greg k-h ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock 2017-11-24 3:44 ` Kai Heng Feng @ 2017-11-24 8:28 ` Greg KH 2017-11-24 8:29 ` Greg KH 2017-11-24 8:57 ` Kai Heng Feng 2017-11-27 15:13 ` Mario.Limonciello 1 sibling, 2 replies; 12+ messages in thread From: Greg KH @ 2017-11-24 8:28 UTC (permalink / raw) To: Kai Heng Feng Cc: David Miller, hayeswang, linux-usb, netdev, LKML, Mario Limonciello 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@linuxfoundation.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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock 2017-11-24 8:28 ` Greg KH @ 2017-11-24 8:29 ` Greg KH 2017-11-24 8:59 ` Kai Heng Feng 2017-11-24 8:57 ` Kai Heng Feng 1 sibling, 1 reply; 12+ messages in thread From: Greg KH @ 2017-11-24 8:29 UTC (permalink / raw) To: Kai Heng Feng Cc: David Miller, hayeswang, linux-usb, netdev, LKML, Mario Limonciello On Fri, Nov 24, 2017 at 09:28:05AM +0100, Greg KH wrote: > 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@linuxfoundation.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? Also the MAC address is different, can you just trigger off of Dell's MAC address space instead of the address space of the dongle device? thanks, greg k-h ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock 2017-11-24 8:29 ` Greg KH @ 2017-11-24 8:59 ` Kai Heng Feng 2017-11-27 15:11 ` Mario.Limonciello 0 siblings, 1 reply; 12+ messages in thread From: Kai Heng Feng @ 2017-11-24 8:59 UTC (permalink / raw) To: Greg KH Cc: David Miller, hayeswang, linux-usb, netdev, LKML, Mario Limonciello > Also the MAC address is different, can you just trigger off of Dell's > MAC address space instead of the address space of the dongle device? A really good idea, never thought of this. Thanks for the hint :) Still, I need to ask Dell folks to get all the answers. Kai-Heng ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH] r8152: disable rx checksum offload on Dell TB dock 2017-11-24 8:59 ` Kai Heng Feng @ 2017-11-27 15:11 ` Mario.Limonciello 0 siblings, 0 replies; 12+ messages in thread From: Mario.Limonciello @ 2017-11-27 15:11 UTC (permalink / raw) To: kai.heng.feng, gregkh; +Cc: davem, hayeswang, linux-usb, netdev, linux-kernel > -----Original Message----- > From: Kai Heng Feng [mailto:kai.heng.feng@canonical.com] > Sent: Friday, November 24, 2017 3:00 AM > To: Greg KH <gregkh@linuxfoundation.org> > Cc: David Miller <davem@davemloft.net>; hayeswang@realtek.co; linux- > usb@vger.kernel.org; netdev@vger.kernel.org; LKML <linux- > kernel@vger.kernel.org>; Limonciello, Mario <Mario_Limonciello@Dell.com> > Subject: Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock > > > > Also the MAC address is different, can you just trigger off of Dell's > > MAC address space instead of the address space of the dongle device? > > A really good idea, never thought of this. Thanks for the hint :) > Still, I need to ask Dell folks to get all the answers. > > Kai-Heng The MAC address stuff is workable to tell if it's a r8153-AD (which is in Dell Inc Type C dongles, TB16 and WD15 docks). This alone wouldn't be enough to tell if it's a TB16. I believe you'd need to have an extra check for that, but maybe this workaround can run after you verify it's r8153-AD in the special MAC address handling section of r8153 driver. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock 2017-11-24 8:28 ` Greg KH 2017-11-24 8:29 ` Greg KH @ 2017-11-24 8:57 ` Kai Heng Feng 1 sibling, 0 replies; 12+ messages in thread From: Kai Heng Feng @ 2017-11-24 8:57 UTC (permalink / raw) To: Greg KH Cc: David Miller, hayeswang, linux-usb, netdev, LKML, Mario Limonciello > On 24 Nov 2017, at 4:28 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > > The bcdDevice is different between the dock device and the "real" > device, why not use that? Yea, I’ll poke around and see if bcdDevice alone can be a good predicate. > 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? I think they are doing this internally. I’ll advice them to ask questions here if they encounter any problem. > 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? No I haven’t. Not really sure how do debug network packets over USB. I’ll do some research on the topic. Kai-Heng ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH] r8152: disable rx checksum offload on Dell TB dock 2017-11-24 3:44 ` Kai Heng Feng 2017-11-24 8:28 ` Greg KH @ 2017-11-27 15:13 ` Mario.Limonciello 2017-11-28 9:40 ` Kai Heng Feng 1 sibling, 1 reply; 12+ messages in thread From: Mario.Limonciello @ 2017-11-27 15:13 UTC (permalink / raw) To: kai.heng.feng, gregkh; +Cc: davem, hayeswang, linux-usb, netdev, linux-kernel > -----Original Message----- > From: Kai Heng Feng [mailto:kai.heng.feng@canonical.com] > Sent: Thursday, November 23, 2017 9:44 PM > To: Greg KH <gregkh@linuxfoundation.org> > Cc: David Miller <davem@davemloft.net>; hayeswang@realtek.co; linux- > usb@vger.kernel.org; netdev@vger.kernel.org; LKML <linux- > kernel@vger.kernel.org>; Limonciello, Mario <Mario_Limonciello@Dell.com> > Subject: Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock > > > > > On 23 Nov 2017, at 5:24 PM, Greg KH <gregkh@linuxfoundation.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 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. > > >> 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. > > >> 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... > > Kai-Heng This is quite surprising to me too. The externally plugged in r8153 dongle, was it connected over type C port or over type A port? AFAIK Type C port is actually Alpine ridge pass through port. It is not connected to XHCI controller or USB hub. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] r8152: disable rx checksum offload on Dell TB dock 2017-11-27 15:13 ` Mario.Limonciello @ 2017-11-28 9:40 ` Kai Heng Feng 0 siblings, 0 replies; 12+ messages in thread From: Kai Heng Feng @ 2017-11-28 9:40 UTC (permalink / raw) To: Mario.Limonciello Cc: Greg KH, David Miller, hayeswang, linux-usb, netdev, linux-kernel > On 27 Nov 2017, at 11:13 PM, <Mario.Limonciello@dell.com> <Mario.Limonciello@dell.com> wrote: > > This is quite surprising to me too. The externally plugged in r8153 dongle, > was it connected over type C port or over type A port? AFAIK Type C port is > actually Alpine ridge pass through port. It is not connected to XHCI controller > or USB hub. Over the front type A port, which connects to SMSC hub then ASMedia controller. The type C port indeed connects to AR directly, hence no such issue. Kai-Heng ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-11-28 9:40 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-23 6:38 [PATCH] r8152: disable rx checksum offload on Dell TB dock Kai-Heng Feng 2017-11-23 7:58 ` Greg KH 2017-11-23 8:53 ` Kai Heng Feng 2017-11-23 9:24 ` Greg KH 2017-11-24 3:44 ` Kai Heng Feng 2017-11-24 8:28 ` Greg KH 2017-11-24 8:29 ` Greg KH 2017-11-24 8:59 ` Kai Heng Feng 2017-11-27 15:11 ` Mario.Limonciello 2017-11-24 8:57 ` Kai Heng Feng 2017-11-27 15:13 ` Mario.Limonciello 2017-11-28 9:40 ` Kai Heng Feng
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).