> Le 27/11/2018 à 16:19, Mario.Limonciello@xxxxxxxx a écrit :
> >> Some news from today.
> >>
> >> I realized that I was not always restarting the computer when changing
> >> the Mac pass-through setting in the BIOS.
> >>
> >> Sometimes I was just hibernating, and this could be the origin of some
> >> failures.
> > OK. Great.
> >
> >> The second usbc dongle works again so there was no permanent change to
> >> the device.
> >>
> >> But Mac pass-through does not work for this device (even from a fresh
> >> restart with no dock connected). This is what I get when connecting it:
> >>
> >> Nov 27 11:06:53 latitude5285 kernel: [ 61.796105] usb 2-1: new
> >> SuperSpeed Gen 1 USB device number 2 using xhci_hcd
> >> Nov 27 11:06:53 latitude5285 kernel: [ 61.816686] usb 2-1: New USB
> >> device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
> >> Nov 27 11:06:53 latitude5285 kernel: [ 61.816688] usb 2-1: New USB
> >> device strings: Mfr=1, Product=2, SerialNumber=6
> >> Nov 27 11:06:53 latitude5285 kernel: [ 61.816688] usb 2-1: Product:
> >> USB 10/100/1000 LAN
> >> Nov 27 11:06:53 latitude5285 kernel: [ 61.816689] usb 2-1:
> >> Manufacturer: Realtek
> >> Nov 27 11:06:53 latitude5285 kernel: [ 61.816690] usb 2-1:
> >> SerialNumber: 000001
> >> Nov 27 11:06:53 latitude5285 kernel: [ 61.835060] usbcore: registered
> >> new interface driver r8152
> >> Nov 27 11:06:53 latitude5285 kernel: [ 61.837654] usbcore: registered
> >> new interface driver cdc_ether
> >> Nov 27 11:06:53 latitude5285 kernel: [ 61.964264] usb 2-1: reset
> >> SuperSpeed Gen 1 USB device number 2 using xhci_hcd
> >> Nov 27 11:06:53 latitude5285 kernel: [ 62.016553] r8152 2-1:1.0 eth0:
> >> v1.09.9
> >> Nov 27 11:06:53 latitude5285 kernel: [ 62.021108] r8152 2-1:1.0
> >> enx00e04c68035e: renamed from eth0
> >> Nov 27 11:06:53 latitude5285 kernel: [ 62.041086] IPv6:
> >> ADDRCONF(NETDEV_UP): enx00e04c68035e: link is not ready
> >> Nov 27 11:06:53 latitude5285 kernel: [ 62.045852] IPv6:
> >> ADDRCONF(NETDEV_UP): enx00e04c68035e: link is not ready
> >>
> > Did you have the debugging patch applied and the dynamic debugging properly
> > enabled during this time?
> Yes
> > I don't see any lines related to the MAC pass through failures here.
> > And to be clear - was this particular dongle ever working for MAC pass through?
>
> I don't know, I never tested it on windows.
If you have dynamic debugging turned on properly and this dongle meets the criteria
then the only thing that I can see looking through the code that would explain this is
tp->version == RTL_VER_01 on your particular dongle matching.
You can try this to see if it helps.
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f1b5201..29734ec 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1214,15 +1214,15 @@ static int set_ethernet_addr(struct r8152 *tp)
struct sockaddr sa;
int ret;
- if (tp->version == RTL_VER_01) {
- ret = pla_ocp_read(tp, PLA_IDR, 8, sa.sa_data);
- } else {
- /* if this is not an RTL8153-AD, no eFuse mac pass thru set,
- * or system doesn't provide valid _SB.AMAC this will be
- * be expected to non-zero
- */
- ret = vendor_mac_passthru_addr_read(tp, &sa);
- if (ret < 0)
+ /* if this is not an RTL8153-AD, no eFuse mac pass thru set,
+ * or system doesn't provide valid _SB.AMAC this will be
+ * be expected to non-zero
+ */
+ ret = vendor_mac_passthru_addr_read(tp, &sa);
+ if (ret < 0) {
+ if (tp->version == RTL_VER_01)
+ ret = pla_ocp_read(tp, PLA_IDR, 8, sa.sa_data);
+ else
ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
}
