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