Support Mac address pass through on Dell DS1000 dock

Support Mac address pass through on Dell DS1000 dock

[Mario Limonciello]

> I tried with your patch but the Mac address pass-through still does not
> work with the usbc adaptor, so it probably does not support it.
> 
> So I will buy a Dell one, it should work.
> 
> Thanks anyway. Frédéric

OK, sounds good.

Oliver,

That debugging patch that provided to Frédéric, would you consider to formally
submit it?  I do think it could be useful if a similar situation crops up again down
the road to make debugging easier.

Thanks,

Support Mac address pass through on Dell DS1000 dock

[Frédéric Parrenin]

Le 30/11/2018 à 17:15, Frédéric Parrenin a écrit :
>
> Le 29/11/2018 à 15:10, Mario.Limonciello@dell.com a écrit :
>>> I tried with your patch but the Mac address pass-through still does not
>>> work with the usbc adaptor, so it probably does not support it.
>>>
>>> So I will buy a Dell one, it should work.
>>>
>>> Thanks anyway. Frédéric
>> OK, sounds good.
>>
> For your information: I bought a Dell UsbC to RJ45 adaptor, and it 
> works perfectly with Mac Address pass-through on linux.
>
For your information: I re-installed windows 10 on this Dell Latitude 
5285 laptop.
So I tried again Mac pass-through with the UNI adaptor bought on Amazon.
Network works, but with the adaptor Mac address, not the laptop Mac 
address, even when pass-through is enabled in the BIOS.
So we have exactly the same behavior than on Linux.

All the best, Frederic

Support Mac address pass through on Dell DS1000 dock

[Frédéric Parrenin]

Le 29/11/2018 à 15:10, Mario.Limonciello@dell.com a écrit :
>> I tried with your patch but the Mac address pass-through still does not
>> work with the usbc adaptor, so it probably does not support it.
>>
>> So I will buy a Dell one, it should work.
>>
>> Thanks anyway. Frédéric
> OK, sounds good.
>
For your information: I bought a Dell UsbC to RJ45 adaptor, and it works 
perfectly with Mac Address pass-through on linux.

Support Mac address pass through on Dell DS1000 dock

[Frédéric Parrenin]

Le 27/11/2018 à 21:27, Mario.Limonciello@dell.com a écrit :
>> Le 27/11/2018 à 16:19, Mario.Limonciello@dell.com 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);
>          }
>
>
I tried with your patch but the Mac address pass-through still does not 
work with the usbc adaptor, so it probably does not support it.

So I will buy a Dell one, it should work.

Thanks anyway. Frédéric

Support Mac address pass through on Dell DS1000 dock

[Mario Limonciello]

> Le 27/11/2018 à 16:19, Mario.Limonciello@dell.com 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);
        }

Support Mac address pass through on Dell DS1000 dock

[Frédéric Parrenin]

Le 27/11/2018 à 16:19, Mario.Limonciello@dell.com 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.

Support Mac address pass through on Dell DS1000 dock

[Mario Limonciello]

> 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?
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?

Support Mac address pass through on Dell DS1000 dock

[Frédéric Parrenin]

Le 26/11/2018 à 21:27, Mario.Limonciello@dell.com a écrit :
> It would be most useful if you can share the kernel's output when you have dynamic
> debugging enabled as Bjorn said for these other devices so we can see why that's
> happening.

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.

The Mac pass-through works with the DS1000 dock. This is what I get in 
/var/log/kern.log when plugging it:

Nov 27 10:29:26 latitude5285 kernel: [  261.052176] usb 2-4: new 
SuperSpeed Gen 1 USB device number 2 using xhci_hcd
Nov 27 10:29:26 latitude5285 kernel: [  261.072519] usb 2-4: New USB 
device found, idVendor=0424, idProduct=5537, bcdDevice=60.80
Nov 27 10:29:26 latitude5285 kernel: [  261.072525] usb 2-4: New USB 
device strings: Mfr=2, Product=3, SerialNumber=0
Nov 27 10:29:26 latitude5285 kernel: [  261.072528] usb 2-4: Product: 
USB5537B
Nov 27 10:29:26 latitude5285 kernel: [  261.072532] usb 2-4: 
Manufacturer: SMSC
Nov 27 10:29:26 latitude5285 kernel: [  261.073789] hub 2-4:1.0: USB hub 
found
Nov 27 10:29:26 latitude5285 kernel: [  261.073884] hub 2-4:1.0: 7 ports 
detected
Nov 27 10:29:26 latitude5285 kernel: [  261.204095] usb 1-3: new 
high-speed USB device number 4 using xhci_hcd
Nov 27 10:29:26 latitude5285 kernel: [  261.356422] usb 1-3: New USB 
device found, idVendor=0424, idProduct=2137, bcdDevice=60.80
Nov 27 10:29:26 latitude5285 kernel: [  261.356427] usb 1-3: New USB 
device strings: Mfr=1, Product=2, SerialNumber=0
Nov 27 10:29:26 latitude5285 kernel: [  261.356430] usb 1-3: Product: 
USB2137B
Nov 27 10:29:26 latitude5285 kernel: [  261.356432] usb 1-3: 
Manufacturer: SMSC
Nov 27 10:29:26 latitude5285 kernel: [  261.357318] hub 1-3:1.0: USB hub 
found
Nov 27 10:29:26 latitude5285 kernel: [  261.357348] hub 1-3:1.0: 7 ports 
detected
Nov 27 10:29:27 latitude5285 kernel: [  261.436176] usb 2-4.2: new 
SuperSpeed Gen 1 USB device number 3 using xhci_hcd
Nov 27 10:29:27 latitude5285 kernel: [  261.456901] usb 2-4.2: New USB 
device found, idVendor=0bda, idProduct=8153, bcdDevice=30.01
Nov 27 10:29:27 latitude5285 kernel: [  261.456908] usb 2-4.2: New USB 
device strings: Mfr=1, Product=2, SerialNumber=6
Nov 27 10:29:27 latitude5285 kernel: [  261.456913] usb 2-4.2: Product: 
USB 10/100/1000 LAN
Nov 27 10:29:27 latitude5285 kernel: [  261.456917] usb 2-4.2: 
Manufacturer: Realtek
Nov 27 10:29:27 latitude5285 kernel: [  261.456921] usb 2-4.2: 
SerialNumber: 000001000000
Nov 27 10:29:27 latitude5285 kernel: [  261.514209] usbcore: registered 
new interface driver r8152
Nov 27 10:29:27 latitude5285 kernel: [  261.519460] usbcore: registered 
new interface driver cdc_ether
Nov 27 10:29:27 latitude5285 kernel: [  261.596505] usb 2-4.2: reset 
SuperSpeed Gen 1 USB device number 3 using xhci_hcd
Nov 27 10:29:27 latitude5285 kernel: [  261.620503] r8152 2-4.2:1.0 
(unnamed net_device) (uninitialized): Using pass-thru MAC addr 
10:65:30:d9:91:18
Nov 27 10:29:27 latitude5285 kernel: [  261.666029] r8152 2-4.2:1.0 
eth0: v1.09.9
Nov 27 10:29:27 latitude5285 kernel: [  261.671909] r8152 2-4.2:1.0 
enx106530d99118: renamed from eth0
Nov 27 10:29:27 latitude5285 kernel: [  261.699661] IPv6: 
ADDRCONF(NETDEV_UP): enx106530d99118: link is not ready
Nov 27 10:29:27 latitude5285 kernel: [  261.706122] IPv6: 
ADDRCONF(NETDEV_UP): enx106530d99118: link is not ready
Nov 27 10:29:27 latitude5285 kernel: [  261.708040] usb 1-3.4: new 
high-speed USB device number 5 using xhci_hcd
Nov 27 10:29:27 latitude5285 kernel: [  261.808389] usb 1-3.4: New USB 
device found, idVendor=0451, idProduct=8142, bcdDevice= 1.00
Nov 27 10:29:27 latitude5285 kernel: [  261.808396] usb 1-3.4: New USB 
device strings: Mfr=0, Product=0, SerialNumber=1
Nov 27 10:29:27 latitude5285 kernel: [  261.808400] usb 1-3.4: 
SerialNumber: 390E084127A2
Nov 27 10:29:27 latitude5285 kernel: [  261.809460] hub 1-3.4:1.0: USB 
hub found
Nov 27 10:29:27 latitude5285 kernel: [  261.809515] hub 1-3.4:1.0: 4 
ports detected
Nov 27 10:29:27 latitude5285 kernel: [  261.888112] usb 1-3.5: new 
high-speed USB device number 6 using xhci_hcd
Nov 27 10:29:27 latitude5285 kernel: [  261.902864] usb 1-3: USB 
disconnect, device number 4
Nov 27 10:29:27 latitude5285 kernel: [  261.903092] usb 1-3-port5: 
attempt power cycle
Nov 27 10:29:27 latitude5285 kernel: [  261.919318] r8152 2-4.2:1.0 
enx106530d99118: Stop submitting intr, status -71
Nov 27 10:29:27 latitude5285 kernel: [  262.092099] usb 2-4: USB 
disconnect, device number 2
Nov 27 10:29:27 latitude5285 kernel: [  262.092105] usb 2-4.2: USB 
disconnect, device number 3
Nov 27 10:29:27 latitude5285 kernel: [  262.216526] usb 1-3.4: USB 
disconnect, device number 5
Nov 27 10:29:27 latitude5285 kernel: [  262.404166] usb 2-4: new 
SuperSpeed Gen 1 USB device number 4 using xhci_hcd
Nov 27 10:29:27 latitude5285 kernel: [  262.424514] usb 2-4: New USB 
device found, idVendor=0424, idProduct=5537, bcdDevice=60.80
Nov 27 10:29:27 latitude5285 kernel: [  262.424520] usb 2-4: New USB 
device strings: Mfr=2, Product=3, SerialNumber=0
Nov 27 10:29:27 latitude5285 kernel: [  262.424525] usb 2-4: Product: 
USB5537B
Nov 27 10:29:27 latitude5285 kernel: [  262.424529] usb 2-4: 
Manufacturer: SMSC
Nov 27 10:29:27 latitude5285 kernel: [  262.425821] hub 2-4:1.0: USB hub 
found
Nov 27 10:29:27 latitude5285 kernel: [  262.425873] hub 2-4:1.0: 7 ports 
detected
Nov 27 10:29:28 latitude5285 kernel: [  262.531598] hub 2-4:1.0: 
hub_ext_port_status failed (err = -71)
Nov 27 10:29:28 latitude5285 kernel: [  262.652111] usb 2-4: USB 
disconnect, device number 4
Nov 27 10:29:28 latitude5285 kernel: [  262.652127] usb 2-4: Failed to 
suspend device, error -19
Nov 27 10:29:29 latitude5285 kernel: [  263.452019] usb 1-3: new 
high-speed USB device number 10 using xhci_hcd
Nov 27 10:29:29 latitude5285 kernel: [  263.600610] usb 1-3: New USB 
device found, idVendor=0424, idProduct=2137, bcdDevice=60.80
Nov 27 10:29:29 latitude5285 kernel: [  263.600617] usb 1-3: New USB 
device strings: Mfr=1, Product=2, SerialNumber=0
Nov 27 10:29:29 latitude5285 kernel: [  263.600621] usb 1-3: Product: 
USB2137B
Nov 27 10:29:29 latitude5285 kernel: [  263.600625] usb 1-3: 
Manufacturer: SMSC
Nov 27 10:29:29 latitude5285 kernel: [  263.601702] hub 1-3:1.0: USB hub 
found
Nov 27 10:29:29 latitude5285 kernel: [  263.601739] hub 1-3:1.0: 7 ports 
detected
Nov 27 10:29:29 latitude5285 kernel: [  263.796171] usb 2-4: new 
SuperSpeed Gen 1 USB device number 5 using xhci_hcd
Nov 27 10:29:29 latitude5285 kernel: [  263.816495] usb 2-4: New USB 
device found, idVendor=0424, idProduct=5537, bcdDevice=60.80
Nov 27 10:29:29 latitude5285 kernel: [  263.816501] usb 2-4: New USB 
device strings: Mfr=2, Product=3, SerialNumber=0
Nov 27 10:29:29 latitude5285 kernel: [  263.816506] usb 2-4: Product: 
USB5537B
Nov 27 10:29:29 latitude5285 kernel: [  263.816510] usb 2-4: 
Manufacturer: SMSC
Nov 27 10:29:29 latitude5285 kernel: [  263.817934] hub 2-4:1.0: USB hub 
found
Nov 27 10:29:29 latitude5285 kernel: [  263.817988] hub 2-4:1.0: 7 ports 
detected
Nov 27 10:29:29 latitude5285 kernel: [  263.900103] usb 1-3.5: new 
high-speed USB device number 11 using xhci_hcd
Nov 27 10:29:29 latitude5285 kernel: [  264.075953] usb 1-3.5: New USB 
device found, idVendor=0bda, idProduct=4014, bcdDevice= 0.05
Nov 27 10:29:29 latitude5285 kernel: [  264.075960] usb 1-3.5: New USB 
device strings: Mfr=3, Product=1, SerialNumber=2
Nov 27 10:29:29 latitude5285 kernel: [  264.075965] usb 1-3.5: Product: 
USB Audio
Nov 27 10:29:29 latitude5285 kernel: [  264.075969] usb 1-3.5: 
Manufacturer: Generic
Nov 27 10:29:29 latitude5285 kernel: [  264.075973] usb 1-3.5: 
SerialNumber: 200901010001
Nov 27 10:29:29 latitude5285 kernel: [  264.140160] usb 2-4.2: new 
SuperSpeed Gen 1 USB device number 6 using xhci_hcd
Nov 27 10:29:29 latitude5285 kernel: [  264.161067] usb 2-4.2: New USB 
device found, idVendor=0bda, idProduct=8153, bcdDevice=30.01
Nov 27 10:29:29 latitude5285 kernel: [  264.161073] usb 2-4.2: New USB 
device strings: Mfr=1, Product=2, SerialNumber=6
Nov 27 10:29:29 latitude5285 kernel: [  264.161078] usb 2-4.2: Product: 
USB 10/100/1000 LAN
Nov 27 10:29:29 latitude5285 kernel: [  264.161082] usb 2-4.2: 
Manufacturer: Realtek
Nov 27 10:29:29 latitude5285 kernel: [  264.161086] usb 2-4.2: 
SerialNumber: 000001000000
Nov 27 10:29:30 latitude5285 kernel: [  264.867241] usbcore: registered 
new interface driver snd-usb-audio
Nov 27 10:29:30 latitude5285 kernel: [  264.872154] usb 2-4.3: new 
SuperSpeed Gen 1 USB device number 7 using xhci_hcd
Nov 27 10:29:30 latitude5285 kernel: [  264.901147] usb 2-4.3: New USB 
device found, idVendor=04e8, idProduct=61f5, bcdDevice= 1.00
Nov 27 10:29:30 latitude5285 kernel: [  264.901151] usb 2-4.3: New USB 
device strings: Mfr=2, Product=3, SerialNumber=1
Nov 27 10:29:30 latitude5285 kernel: [  264.901153] usb 2-4.3: Product: 
Portable SSD T5
Nov 27 10:29:30 latitude5285 kernel: [  264.901155] usb 2-4.3: 
Manufacturer: Samsung
Nov 27 10:29:30 latitude5285 kernel: [  264.901157] usb 2-4.3: 
SerialNumber: 1234567C23E6
Nov 27 10:29:30 latitude5285 kernel: [  264.980481] usb 2-4.2: reset 
SuperSpeed Gen 1 USB device number 6 using xhci_hcd
Nov 27 10:29:30 latitude5285 kernel: [  265.066593] r8152 2-4.2:1.0 
(unnamed net_device) (uninitialized): Using pass-thru MAC addr 
10:65:30:d9:91:18
Nov 27 10:29:30 latitude5285 kernel: [  265.097823] r8152 2-4.2:1.0 
eth0: v1.09.9
Nov 27 10:29:30 latitude5285 kernel: [  265.111034] SCSI subsystem 
initialized
Nov 27 10:29:30 latitude5285 kernel: [  265.113917] usbcore: registered 
new interface driver usb-storage
Nov 27 10:29:30 latitude5285 kernel: [  265.233672] scsi host0: uas
Nov 27 10:29:30 latitude5285 kernel: [  265.234181] usbcore: registered 
new interface driver uas
Nov 27 10:29:30 latitude5285 kernel: [  265.234715] scsi 0:0:0:0: 
Direct-Access     Samsung  Portable SSD T5  0    PQ: 0 ANSI: 6
Nov 27 10:29:30 latitude5285 kernel: [  265.254051] scsi 0:0:0:0: 
Attached scsi generic sg0 type 0
Nov 27 10:29:30 latitude5285 kernel: [  265.257435] sd 0:0:0:0: [sda] 
1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
Nov 27 10:29:30 latitude5285 kernel: [  265.257559] sd 0:0:0:0: [sda] 
Write Protect is off
Nov 27 10:29:30 latitude5285 kernel: [  265.257563] sd 0:0:0:0: [sda] 
Mode Sense: 43 00 00 00
Nov 27 10:29:30 latitude5285 kernel: [  265.257717] sd 0:0:0:0: [sda] 
Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Nov 27 10:29:30 latitude5285 kernel: [  265.261613]  sda: sda1
Nov 27 10:29:30 latitude5285 kernel: [  265.262637] sd 0:0:0:0: [sda] 
Attached SCSI disk
Nov 27 10:29:30 latitude5285 kernel: [  265.274324] r8152 2-4.2:1.0 
enx106530d99118: renamed from eth0
Nov 27 10:29:30 latitude5285 kernel: [  265.323059] IPv6: 
ADDRCONF(NETDEV_UP): enx106530d99118: link is not ready
Nov 27 10:29:30 latitude5285 kernel: [  265.332485] IPv6: 
ADDRCONF(NETDEV_UP): enx106530d99118: link is not ready
Nov 27 10:29:34 latitude5285 kernel: [  268.780822] IPv6: 
ADDRCONF(NETDEV_CHANGE): enx106530d99118: link becomes ready
Nov 27 10:29:34 latitude5285 kernel: [  268.781426] r8152 2-4.2:1.0 
enx106530d99118: carrier on
Nov 27 10:29:41 latitude5285 kernel: [  276.013642] [drm] Reducing the 
compressed framebuffer size. This may lead to less power savings than a 
non-reduced-size. Try to increase stolen memory size if available in BIOS.
Nov 27 10:29:43 latitude5285 kernel: [  277.446087] EXT4-fs (sda1): 
recovery complete
Nov 27 10:29:43 latitude5285 kernel: [  277.452343] EXT4-fs (sda1): 
mounted filesystem with ordered data mode. Opts: (null)
Nov 27 10:30:39 latitude5285 kernel: [  334.390136] wlp2s0: 
disassociated from 00:a7:42:cd:7b:bd (Reason: 1=UNSPECIFIED)
Nov 27 10:30:40 latitude5285 kernel: [  334.946708] wlp2s0: authenticate 
with 38:0e:4d:03:07:8d
Nov 27 10:30:40 latitude5285 kernel: [  334.958771] wlp2s0: send auth to 
38:0e:4d:03:07:8d (try 1/3)
Nov 27 10:30:40 latitude5285 kernel: [  334.962243] wlp2s0: authenticated
Nov 27 10:30:40 latitude5285 kernel: [  334.972067] wlp2s0: associate 
with 38:0e:4d:03:07:8d (try 1/3)
Nov 27 10:30:40 latitude5285 kernel: [  334.974221] wlp2s0: RX AssocResp 
from 38:0e:4d:03:07:8d (capab=0x101 status=0 aid=21)
Nov 27 10:30:40 latitude5285 kernel: [  334.987756] wlp2s0: associated
Nov 27 10:30:40 latitude5285 kernel: [  335.140188] wlp2s0: Limiting TX 
power to 17 dBm as advertised by 38:0e:4d:03:07:8d
Nov 27 10:30:43 latitude5285 kernel: [  337.695933] wlp2s0: disconnect 
from AP 38:0e:4d:03:07:8d for new auth to 00:a7:42:cd:7b:b2
Nov 27 10:30:43 latitude5285 kernel: [  337.707584] wlp2s0: authenticate 
with 00:a7:42:cd:7b:b2
Nov 27 10:30:43 latitude5285 kernel: [  337.717626] wlp2s0: send auth to 
00:a7:42:cd:7b:b2 (try 1/3)
Nov 27 10:30:43 latitude5285 kernel: [  337.735082] wlp2s0: authenticated
Nov 27 10:30:43 latitude5285 kernel: [  337.736059] wlp2s0: associate 
with 00:a7:42:cd:7b:b2 (try 1/3)
Nov 27 10:30:43 latitude5285 kernel: [  337.739701] wlp2s0: RX 
ReassocResp from 00:a7:42:cd:7b:b2 (capab=0x421 status=0 aid=6)
Nov 27 10:30:43 latitude5285 kernel: [  337.742057] wlp2s0: associated
Nov 27 10:30:43 latitude5285 kernel: [  337.830710] wlp2s0: Limiting TX 
power to 7 dBm as advertised by 00:a7:42:cd:7b:b2
Nov 27 10:31:44 latitude5285 kernel: [  398.688870] [drm] Reducing the 
compressed framebuffer size. This may lead to less power savings than a 
non-reduced-size. Try to increase stolen memory size if available in BIOS.

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

Best,

Frédéric

Support Mac address pass through on Dell DS1000 dock

[Frédéric Parrenin]

Le 26/11/2018 à 21:27, Mario.Limonciello@dell.com a écrit :
>> -----Original Message-----
>> From: Frédéric Parrenin <frederic.parrenin@univ-grenoble-alpes.fr>
>> Sent: Monday, November 26, 2018 2:08 PM
>> To: Limonciello, Mario; oneukum@suse.com; gregkh@linuxfoundation.org
>> Cc: bjorn@mork.no; linux-usb@vger.kernel.org
>> Subject: Re: Support Mac address pass through on Dell DS1000 dock
>>
>>
>> [EXTERNAL EMAIL]
>>
>>
>> Le 26/11/2018 à 19:55, Mario.Limonciello@dell.com a écrit :
>>>> Le 26/11/2018 à 15:21, Mario.Limonciello@dell.com a écrit :
>>>>> Any feedback from testing with this debugging patch to identify what's
>>>> happening?
>>>>
>>>> This is super strange, but Mac address pass-through is now working in my
>>>> configuration, although I did not change anything.
>>>> The network is up and running and I have the right Mac Address
>>> I guess I would say try it a few times to see if you can trigger your failure again.
>>>
>>> Also it might be worth trying some different permutations of power applied to the
>>> dock before plugging into the machine or after plugging into the machine to see
>>> if there is some correlation with a potential ethernet controller bootup race
>> condition.
>>>> For your information, I recompile the kernel and this is the message I
>>>> got in /sys/kernel/debug/dynamic_debug/control:
>>>>
>>>> drivers/net/usb/r8152.c:5149 [r8152]rtl_get_version =_ "Detected version
>>>> 0x%04x\012"
>>>> drivers/net/usb/r8152.c:1178 [r8152]vendor_mac_passthru_addr_read =_
>>>> "pass-through bit not set.\012"
>>>> drivers/net/usb/r8152.c:1170 [r8152]vendor_mac_passthru_addr_read =_
>>>> "Not an AD type.\012"
>>>>
>>>> Not sure if it is the information you were looking for (sorry, I am new
>>>> in kernel debugging).
>>> These indicate that you turned on the right dynamic debugging lines, but the
>> actual
>>> output of them will show up in your kernel log.
>>>
>>> If you happen to reproduce the failure again while dynamic debugging is enabled
>> for those
>>> it should save to the kernel log what is happening.
>> On a related note, I tried Mac Address pass-through with two different
>> usbc/rj45 dongles, and they both stopped working (they were before).
>>
> It would be most useful if you can share the kernel's output when you have dynamic
> debugging enabled as Bjorn said for these other devices so we can see why that's
> happening.
>
>> So I was wondering, is it possible that the driver makes some permanent
>> changes to these devices?
> I wouldn't expect any "permanent" changes to the device from MAC address
> pass through.  However I would wonder are you plugging these dongles into
> the dock and the dock is staying powered so they can't be updated again?
No, the dongles are plugged directly to the laptop.
>
> If they are not getting power cycled between your tests, maybe the hardware
> will not support actually updating the MAC address again?
>
> I know at least in TB16 there is a special flow that clears the MAC address on the
> 8153-AD when the dock is unplugged so it can be reprogrammed on next plugin.
>
> If you look at the source it's very intentional that the pass through MAC is read
> at the time it is.  This is before the MAC has even been configured the first time.
>
> If you can please share your kernel output with dynamic debugging turned on
> and annotate it along what actions you are performing and the topology of the
> dock and dongles we might be able to make better sense of what is happening.
>
>> Of course it is possible that both devices had hardware issues, but the
>> coincidence is surprising.
> Is this with a combination of them plugged in?
No, the dongles are plugged separately.

Support Mac address pass through on Dell DS1000 dock

[Mario Limonciello]

> -----Original Message-----
> From: Frédéric Parrenin <frederic.parrenin@univ-grenoble-alpes.fr>
> Sent: Monday, November 26, 2018 2:08 PM
> To: Limonciello, Mario; oneukum@suse.com; gregkh@linuxfoundation.org
> Cc: bjorn@mork.no; linux-usb@vger.kernel.org
> Subject: Re: Support Mac address pass through on Dell DS1000 dock
> 
> 
> [EXTERNAL EMAIL]
> 
> 
> Le 26/11/2018 à 19:55, Mario.Limonciello@dell.com a écrit :
> >> Le 26/11/2018 à 15:21, Mario.Limonciello@dell.com a écrit :
> >>> Any feedback from testing with this debugging patch to identify what's
> >> happening?
> >>
> >> This is super strange, but Mac address pass-through is now working in my
> >> configuration, although I did not change anything.
> >> The network is up and running and I have the right Mac Address
> > I guess I would say try it a few times to see if you can trigger your failure again.
> >
> > Also it might be worth trying some different permutations of power applied to the
> > dock before plugging into the machine or after plugging into the machine to see
> > if there is some correlation with a potential ethernet controller bootup race
> condition.
> >
> >> For your information, I recompile the kernel and this is the message I
> >> got in /sys/kernel/debug/dynamic_debug/control:
> >>
> >> drivers/net/usb/r8152.c:5149 [r8152]rtl_get_version =_ "Detected version
> >> 0x%04x\012"
> >> drivers/net/usb/r8152.c:1178 [r8152]vendor_mac_passthru_addr_read =_
> >> "pass-through bit not set.\012"
> >> drivers/net/usb/r8152.c:1170 [r8152]vendor_mac_passthru_addr_read =_
> >> "Not an AD type.\012"
> >>
> >> Not sure if it is the information you were looking for (sorry, I am new
> >> in kernel debugging).
> > These indicate that you turned on the right dynamic debugging lines, but the
> actual
> > output of them will show up in your kernel log.
> >
> > If you happen to reproduce the failure again while dynamic debugging is enabled
> for those
> > it should save to the kernel log what is happening.
> On a related note, I tried Mac Address pass-through with two different
> usbc/rj45 dongles, and they both stopped working (they were before).
> 

It would be most useful if you can share the kernel's output when you have dynamic
debugging enabled as Bjorn said for these other devices so we can see why that's
happening.

> So I was wondering, is it possible that the driver makes some permanent
> changes to these devices?

I wouldn't expect any "permanent" changes to the device from MAC address
pass through.  However I would wonder are you plugging these dongles into
the dock and the dock is staying powered so they can't be updated again?

If they are not getting power cycled between your tests, maybe the hardware
will not support actually updating the MAC address again?

I know at least in TB16 there is a special flow that clears the MAC address on the
8153-AD when the dock is unplugged so it can be reprogrammed on next plugin.

If you look at the source it's very intentional that the pass through MAC is read
at the time it is.  This is before the MAC has even been configured the first time.

If you can please share your kernel output with dynamic debugging turned on
and annotate it along what actions you are performing and the topology of the
dock and dongles we might be able to make better sense of what is happening.

> 
> Of course it is possible that both devices had hardware issues, but the
> coincidence is surprising.

Is this with a combination of them plugged in?

Support Mac address pass through on Dell DS1000 dock

[Frédéric Parrenin]

Le 26/11/2018 à 19:55, Mario.Limonciello@dell.com a écrit :
>> Le 26/11/2018 à 15:21, Mario.Limonciello@dell.com a écrit :
>>> Any feedback from testing with this debugging patch to identify what's
>> happening?
>>
>> This is super strange, but Mac address pass-through is now working in my
>> configuration, although I did not change anything.
>> The network is up and running and I have the right Mac Address
> I guess I would say try it a few times to see if you can trigger your failure again.
>
> Also it might be worth trying some different permutations of power applied to the
> dock before plugging into the machine or after plugging into the machine to see
> if there is some correlation with a potential ethernet controller bootup race condition.
>
>> For your information, I recompile the kernel and this is the message I
>> got in /sys/kernel/debug/dynamic_debug/control:
>>
>> drivers/net/usb/r8152.c:5149 [r8152]rtl_get_version =_ "Detected version
>> 0x%04x\012"
>> drivers/net/usb/r8152.c:1178 [r8152]vendor_mac_passthru_addr_read =_
>> "pass-through bit not set.\012"
>> drivers/net/usb/r8152.c:1170 [r8152]vendor_mac_passthru_addr_read =_
>> "Not an AD type.\012"
>>
>> Not sure if it is the information you were looking for (sorry, I am new
>> in kernel debugging).
> These indicate that you turned on the right dynamic debugging lines, but the actual
> output of them will show up in your kernel log.
>
> If you happen to reproduce the failure again while dynamic debugging is enabled for those
> it should save to the kernel log what is happening.
On a related note, I tried Mac Address pass-through with two different 
usbc/rj45 dongles, and they both stopped working (they were before).

So I was wondering, is it possible that the driver makes some permanent 
changes to these devices?

Of course it is possible that both devices had hardware issues, but the 
coincidence is surprising.

Support Mac address pass through on Dell DS1000 dock

[Bjørn Mork]

Frédéric Parrenin <frederic.parrenin@univ-grenoble-alpes.fr> writes:

> Le 26/11/2018 à 15:21, Mario.Limonciello@dell.com a écrit :
>>
>> Any feedback from testing with this debugging patch to identify what's happening?
>
> This is super strange, but Mac address pass-through is now working in
> my configuration, although I did not change anything.
> The network is up and running and I have the right Mac Address
>
> For your information, I recompile the kernel and this is the message I
> got in /sys/kernel/debug/dynamic_debug/control:
>
> drivers/net/usb/r8152.c:5149 [r8152]rtl_get_version =_ "Detected
> version 0x%04x\012"
> drivers/net/usb/r8152.c:1178 [r8152]vendor_mac_passthru_addr_read =_
> "pass-through bit not set.\012"
> drivers/net/usb/r8152.c:1170 [r8152]vendor_mac_passthru_addr_read =_
> "Not an AD type.\012"
>
> Not sure if it is the information you were looking for (sorry, I am
> new in kernel debugging).


/sys/kernel/debug/dynamic_debug/control lists all the *available* debug
messages.  You still need to enable them.  The "=_" in the lines above
indicate that they are disabled.

E.g. to enable all r8152.c related debug messages prefixed with the
function name:

 echo 'file r8152.c +fp' >/sys/kernel/debug/dynamic_debug/control


See
https://www.kernel.org/doc/Documentation/admin-guide/dynamic-debug-howto.rst
for more info on the dynamic debug feature.



Bjørn

Support Mac address pass through on Dell DS1000 dock

[Mario Limonciello]

> Le 26/11/2018 à 15:21, Mario.Limonciello@dell.com a écrit :
> >
> > Any feedback from testing with this debugging patch to identify what's
> happening?
> 
> This is super strange, but Mac address pass-through is now working in my
> configuration, although I did not change anything.
> The network is up and running and I have the right Mac Address

I guess I would say try it a few times to see if you can trigger your failure again.

Also it might be worth trying some different permutations of power applied to the
dock before plugging into the machine or after plugging into the machine to see
if there is some correlation with a potential ethernet controller bootup race condition.

> 
> For your information, I recompile the kernel and this is the message I
> got in /sys/kernel/debug/dynamic_debug/control:
> 
> drivers/net/usb/r8152.c:5149 [r8152]rtl_get_version =_ "Detected version
> 0x%04x\012"
> drivers/net/usb/r8152.c:1178 [r8152]vendor_mac_passthru_addr_read =_
> "pass-through bit not set.\012"
> drivers/net/usb/r8152.c:1170 [r8152]vendor_mac_passthru_addr_read =_
> "Not an AD type.\012"
> 
> Not sure if it is the information you were looking for (sorry, I am new
> in kernel debugging).

These indicate that you turned on the right dynamic debugging lines, but the actual
output of them will show up in your kernel log.

If you happen to reproduce the failure again while dynamic debugging is enabled for those
it should save to the kernel log what is happening.

Support Mac address pass through on Dell DS1000 dock

[Frédéric Parrenin]

Le 26/11/2018 à 15:21, Mario.Limonciello@dell.com a écrit :
>
> Any feedback from testing with this debugging patch to identify what's happening?

This is super strange, but Mac address pass-through is now working in my 
configuration, although I did not change anything.
The network is up and running and I have the right Mac Address

For your information, I recompile the kernel and this is the message I 
got in /sys/kernel/debug/dynamic_debug/control:

drivers/net/usb/r8152.c:5149 [r8152]rtl_get_version =_ "Detected version 
0x%04x\012"
drivers/net/usb/r8152.c:1178 [r8152]vendor_mac_passthru_addr_read =_ 
"pass-through bit not set.\012"
drivers/net/usb/r8152.c:1170 [r8152]vendor_mac_passthru_addr_read =_ 
"Not an AD type.\012"

Not sure if it is the information you were looking for (sorry, I am new 
in kernel debugging).

FP

Support Mac address pass through on Dell DS1000 dock

[Mario Limonciello]

> 
> Le 22/11/2018 à 18:15, Oliver Neukum a écrit :
> > On Do, 2018-11-22 at 12:06 +0100, Frédéric Parrenin         wrote:
> >> Le 22/11/2018 à 11:22, Oliver Neukum a écrit :
> >>> On Mi, 2018-11-21 at 16:50 +0100, Frédéric Parrenin  wrote:
> >>>> which over rides the Mac on the dock. So, the answer is, "it's not an
> >>>> issue if the dock supports it, as the laptop BIOS is what is determining
> >>>> if it is supported".
> >>>>
> >>>> So what is the truth?
> >>> For pass thru you must meet multiple conditions:
> >>>
> >>> /* if this is not an RTL8153-AD, no eFuse mac passthru set,
> >>>    * or system doesn't provide valid _SB.AMAC this will be
> >>>    * be expected to non-zero
> >>>    */>
> >>>
> >>> They can be manually verified. Do you need a debugging patch?
> >> OK, let us try a debugging patch.
> > Here you go.
> > PLease enable dynamic debugging for the driver and ramp up
> > your logging level.
> >
> >
> Thanks.
> I will try the debugging patch, although Bjorn's solution seems to me to
> be the best (having something in userspace which does not depend on the
> dock/dongle device).

Any feedback from testing with this debugging patch to identify what's happening?

FWIW that was my original implementation doing it in userspace.  There are
two problems with this flow:
1) Many of the details needed to know when to activate are driver specific
internal details.  Such as knowing whether the bit to enable feature is set, and
exact chipset, and exporting the MAC address.

Yes; it's technically possible to export each of those (or even a 0/1 hint that all the r8152
driver stuff was met) and also allow end userspace policy to apply them more liberally.
The current path is supposed to apply it only at the same times that it would be in
UEFI/PXE and Windows.

2) I do recall I was encountering race condition problems with some existing
userspace utilities that tried to rename the device based on MAC address.
These would need to be resolved.

Support Mac address pass through on Dell DS1000 dock

[Frédéric Parrenin]

Le 22/11/2018 à 18:15, Oliver Neukum a écrit :
> On Do, 2018-11-22 at 12:06 +0100, Frédéric Parrenin         wrote:
>> Le 22/11/2018 à 11:22, Oliver Neukum a écrit :
>>> On Mi, 2018-11-21 at 16:50 +0100, Frédéric Parrenin  wrote:
>>>> which over rides the Mac on the dock. So, the answer is, "it's not an
>>>> issue if the dock supports it, as the laptop BIOS is what is determining
>>>> if it is supported".
>>>>
>>>> So what is the truth?
>>> For pass thru you must meet multiple conditions:
>>>
>>> /* if this is not an RTL8153-AD, no eFuse mac passthru set,
>>>    * or system doesn't provide valid _SB.AMAC this will be
>>>    * be expected to non-zero
>>>    */>
>>>
>>> They can be manually verified. Do you need a debugging patch?
>> OK, let us try a debugging patch.
> Here you go.
> PLease enable dynamic debugging for the driver and ramp up
> your logging level.
>
> 	
Thanks.
I will try the debugging patch, although Bjorn's solution seems to me to 
be the best (having something in userspace which does not depend on the 
dock/dongle device).

Support Mac address pass through on Dell DS1000 dock

[Oliver Neukum]

On Do, 2018-11-22 at 12:06 +0100, Frédéric Parrenin         wrote:
> Le 22/11/2018 à 11:22, Oliver Neukum a écrit :
> > On Mi, 2018-11-21 at 16:50 +0100, Frédéric Parrenin  wrote:
> > > which over rides the Mac on the dock. So, the answer is, "it's not an
> > > issue if the dock supports it, as the laptop BIOS is what is determining
> > > if it is supported".
> > > 
> > > So what is the truth?
> > 
> > For pass thru you must meet multiple conditions:
> > 
> > /* if this is not an RTL8153-AD, no eFuse mac passthru set,
> >   * or system doesn't provide valid _SB.AMAC this will be
> >   * be expected to non-zero
> >   */>
> > 
> > They can be manually verified. Do you need a debugging patch?
> 
> OK, let us try a debugging patch.

Here you go.
PLease enable dynamic debugging for the driver and ramp up
your logging level.

	Regards
		Oliver

From 3661ff35782f7b26df3204f4f7a18929e0c74ff7 Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum@suse.com>
Date: Thu, 22 Nov 2018 18:08:43 +0100
Subject: [PATCH] rtl8152: debugging for MAC pass-through

This adds debugging statements for failure cases in MAC
pass-through

Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 drivers/net/usb/r8152.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 7345a2258ee4..3ed52806164c 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1168,19 +1168,28 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
 
 	/* test for -AD variant of RTL8153 */
 	ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
-	if ((ocp_data & AD_MASK) != 0x1000)
+	if ((ocp_data & AD_MASK) != 0x1000) {
+		netif_dbg(tp, probe, tp->netdev,
+				"Not an AD type.\n");
 		return -ENODEV;
+	}
 
 	/* test for MAC address pass-through bit */
 	ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, EFUSE);
-	if ((ocp_data & PASS_THRU_MASK) != 1)
+	if ((ocp_data & PASS_THRU_MASK) != 1) {
+		netif_dbg(tp, probe, tp->netdev,
+				"pass-through bit not set.\n");
 		return -ENODEV;
+	}
 
 	/* returns _AUXMAC_#AABBCCDDEEFF# */
 	status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, &buffer);
 	obj = (union acpi_object *)buffer.pointer;
-	if (!ACPI_SUCCESS(status))
+	if (!ACPI_SUCCESS(status)) {
+		netif_warn(tp, probe, tp->netdev,
+				"pass-through firmware failure.\n");
 		return -ENODEV;
+	}
 	if (obj->type != ACPI_TYPE_BUFFER || obj->string.length != 0x17) {
 		netif_warn(tp, probe, tp->netdev,
 			   "Invalid buffer for pass-thru MAC addr: (%d, %d)\n",
-- 
2.16.4