> I have some other questions which answers should we know: > > 1) Is that AUX MAC address implemented only in customized windows Dell > driver? Or also in "upstream" windows Realtek driver and all users of > Realtek hw can install it (or update via next driver update)? > I don't have the information on this. Realtek will have to comment here as this part is a black box to me. I'm asking my internal colleagues about this too. > 2) Can you share pseudo code or description of algorithm which decide > MAC address for newly connected r8152 device on windows? This could help > us to decide if something similar/same cannot be implemented also on > linux (either in kernel or userspace). What I would like to know are > those situations when you connect more r8152 devices (some Dell and some > non-Dell). > This is another thing I don't have the information for right now. I can install Windows on a laptop, install the Realtek driver and experiment, but it would be better to get this directly from Realtek if at all possible. > > I do have a way to query if a dock is plugged in via SMM, but I doubt > > that's what Realtek is using on the Windows side. > > So there is some way to check if Dell dock is plugged, right? But what > happen if you connect Dell dock and also non-Dell r8152 device? Can you > distinguish which device is Dell and which non-Dell? Yes, when querying if a Dell dock is plugged in, a "location" and "count" parameter is returned. I'd have to figure out how to translate that into what the Linux kernel sees. Actually the information for how to do this is already public too. It's in a pull request for Dock FW updating in the fwupd project. https://github.com/hughsie/fwupd/pull/49/files#diff-81b55c87ce1542a18b0a4b2b228b9129R189 > > Anyway, I think that by SMM you mean dell smbios API call. Cannot you > guys in Dell release documentation of all smbios calls to community? Well dell SMBIOS API call really means to use dcdbas kernel module which does SMM.. > Time to time you release some small parts in libsmbios project which > then we can use for implementing useful parts in kernel (e.g. LED driver > for controlling keyboard backlight). But there are couple of > undocumented APIs and maybe some can also help with this problem... > Releasing different bits of our SMBIOS document requires approvals. We can't just release the whole thing as there are lots of interfaces that aren't intended for the OS to be using. They're used only by Dell tools. For example we just had approval for information about querying TPM and dock information and those are present in the fwupd pull request for dock and TPM FW updates you see above. If you have some API's in particular you would like more information on, I'm happy to have internal discussion to see if we can release information on those. > > I'd leave that as > > a second to last resort (last resort being move back to userspace > > again). > > > > > What you definitely should not do is to change the mac for some > > > arbitrary "first" device. Then you are better off with the > > > userspace proposal where you and your users have some chance to > > > implement a sensible policy based on e.g. usb port numbers. > > > > OK, if I can't come up with a way to key on the device being a Dell > > dock I'll scrap this entirely kernel approach. > > E.g. PCI devices have ordinary PCI device & vendor IDs, but have Dell > specific subsystem IDs. And via subsystem IDs we can distinguish between > Intel graphics card on Dell laptop and on non-Dell laptop. > > Does not you have some special/modified firmware in those Dell realtek > docks (and ability to check from OS some registers)? I think so. Otherwise there would be all the same concerns you have outlined with generic devices. Like I said this part is currently a black box to me. I hope Realtek can publicly comment on this, or I can get some information from my colleagues. ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
