| Message ID | 20170328.064215.1055636797214516339.rene@exactcode.com |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | David Miller |
| Headers | show |
> On Thu, 2017-03-30 at 19:47 +0200, René Rebe wrote: > > Hi, > > > > On Mar 30, 2017, at 19:06, Dan Williams <dcbw@redhat.com> wrote: > > > > > On Tue, 2017-03-28 at 06:42 +0200, Rene Rebe wrote: > > > > Without this the generic cdc_ether grabs the device, > > > > and does not really work. > > > > > > Does this need a corresponding blacklist in cdc_ether > > > then? Otherwise > > > you're really depending on driver loading order. > > > > right, I already test build, and will send after reboot. > > > > Any other nitpick in the meantime? > > Nope, other than it's pretty odd that the device would expose standard > cdc-ether compatible USB descriptors, but apparently not be compatible > with cdc-ether? Are we sure we don't just need a tweak or something to > cdc-ether? Based on the existing glue and blacklist code I would assume most if not all R8152 devices have this "issue". However, sometimes the standard macOS driver works with it. IIRC if the dock is connected after booting or so, so maybe the BIOS network boot glue alters the behavior or whatever. It never was able to TX any packet with the generic Linux cdc-ether, though. Anyways, given the existing specific Linux driver I would assume it is better to use it in any case. René
On Tue, 2017-03-28 at 06:42 +0200, Rene Rebe wrote: > Without this the generic cdc_ether grabs the device, > and does not really work. Does this need a corresponding blacklist in cdc_ether then? Otherwise you're really depending on driver loading order. Dan > Signed-off-by: René Rebe <rene@exactcode.com> > > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c > index c34df33..07f788c 100644 > --- a/drivers/net/usb/r8152.c > +++ b/drivers/net/usb/r8152.c > @@ -517,6 +517,7 @@ enum rtl8152_flags { > > /* Define these values to match your device */ > #define VENDOR_ID_REALTEK 0x0bda > +#define VENDOR_ID_MICROSOFT 0x045e > #define VENDOR_ID_SAMSUNG 0x04e8 > #define VENDOR_ID_LENOVO 0x17ef > #define VENDOR_ID_NVIDIA 0x0955 > @@ -4521,6 +4522,8 @@ static void rtl8152_disconnect(struct > usb_interface *intf) > static struct usb_device_id rtl8152_table[] = { > {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)}, > {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)}, > + {REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab)}, > + {REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07c6)}, > {REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)}, > {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x304f)}, > {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x3062)}, > > > -- > René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin > http://exactcode.com | http://t2-project.org | http://rene.rebe.de
Hi, On Mar 30, 2017, at 19:06, Dan Williams <dcbw@redhat.com> wrote: > On Tue, 2017-03-28 at 06:42 +0200, Rene Rebe wrote: >> Without this the generic cdc_ether grabs the device, >> and does not really work. > > Does this need a corresponding blacklist in cdc_ether then? Otherwise > you're really depending on driver loading order. right, I already test build, and will send after reboot. Any other nitpick in the meantime? > Dan > >> Signed-off-by: René Rebe <rene@exactcode.com> >> >> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c >> index c34df33..07f788c 100644 >> --- a/drivers/net/usb/r8152.c >> +++ b/drivers/net/usb/r8152.c >> @@ -517,6 +517,7 @@ enum rtl8152_flags { >> >> /* Define these values to match your device */ >> #define VENDOR_ID_REALTEK 0x0bda >> +#define VENDOR_ID_MICROSOFT 0x045e >> #define VENDOR_ID_SAMSUNG 0x04e8 >> #define VENDOR_ID_LENOVO 0x17ef >> #define VENDOR_ID_NVIDIA 0x0955 >> @@ -4521,6 +4522,8 @@ static void rtl8152_disconnect(struct >> usb_interface *intf) >> static struct usb_device_id rtl8152_table[] = { >> {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)}, >> {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)}, >> + {REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab)}, >> + {REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07c6)}, >> {REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)}, >> {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x304f)}, >> {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x3062)}, >> >> >> -- >> René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin >> http://exactcode.com | http://t2-project.org | http://rene.rebe.de
On Thu, 2017-03-30 at 19:47 +0200, René Rebe wrote: > Hi, > > On Mar 30, 2017, at 19:06, Dan Williams <dcbw@redhat.com> wrote: > > > On Tue, 2017-03-28 at 06:42 +0200, Rene Rebe wrote: > > > Without this the generic cdc_ether grabs the device, > > > and does not really work. > > > > Does this need a corresponding blacklist in cdc_ether > > then? Otherwise > > you're really depending on driver loading order. > > right, I already test build, and will send after reboot. > > Any other nitpick in the meantime? Nope, other than it's pretty odd that the device would expose standard cdc-ether compatible USB descriptors, but apparently not be compatible with cdc-ether? Are we sure we don't just need a tweak or something to cdc-ether? Dan > > Dan > > > > > Signed-off-by: René Rebe <rene@exactcode.com> > > > > > > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c > > > index c34df33..07f788c 100644 > > > --- a/drivers/net/usb/r8152.c > > > +++ b/drivers/net/usb/r8152.c > > > @@ -517,6 +517,7 @@ enum rtl8152_flags { > > > > > > /* Define these values to match your device */ > > > #define VENDOR_ID_REALTEK 0x0bda > > > +#define VENDOR_ID_MICROSOFT 0x045e > > > #define VENDOR_ID_SAMSUNG 0x04e8 > > > #define VENDOR_ID_LENOVO 0x17ef > > > #define VENDOR_ID_NVIDIA 0x0955 > > > @@ -4521,6 +4522,8 @@ static void rtl8152_disconnect(struct > > > usb_interface *intf) > > > static struct usb_device_id rtl8152_table[] = { > > > {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)}, > > > {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)}, > > > + {REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab)}, > > > + {REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07c6)}, > > > {REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)}, > > > {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x304f)}, > > > {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x3062)}, > > > > > > > > > -- > > > René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 > > > Berlin > > > http://exactcode.com | http://t2-project.org | > > > http://rene.rebe.de > >
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index c34df33..07f788c 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -517,6 +517,7 @@ enum rtl8152_flags { /* Define these values to match your device */ #define VENDOR_ID_REALTEK 0x0bda +#define VENDOR_ID_MICROSOFT 0x045e #define VENDOR_ID_SAMSUNG 0x04e8 #define VENDOR_ID_LENOVO 0x17ef #define VENDOR_ID_NVIDIA 0x0955 @@ -4521,6 +4522,8 @@ static void rtl8152_disconnect(struct usb_interface *intf) static struct usb_device_id rtl8152_table[] = { {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)}, {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)}, + {REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab)}, + {REALTEK_USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07c6)}, {REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, 0xa101)}, {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x304f)}, {REALTEK_USB_DEVICE(VENDOR_ID_LENOVO, 0x3062)},
Without this the generic cdc_ether grabs the device, and does not really work. Signed-off-by: René Rebe <rene@exactcode.com>