* [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: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 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 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).