Am Tue, 4 Jan 2022 12:00:27 -0800 schrieb Jakub Kicinski <kuba@xxxxxxxxxx>: > On Tue, 4 Jan 2022 19:34:55 +0100 Henning Schild wrote: > > Am Wed, 5 Jan 2022 01:40:42 +0800 > > schrieb Aaron Ma <aaron.ma@xxxxxxxxxxxxx>: > > > Yes, it's expected to be a mess if multiple r8152 are attached to > > > Lenovo USB-C/TBT docks. The issue had been discussed for several > > > times in LKML. Either lose this feature or add potential risk for > > > multiple r8152. > > > > > > The idea is to make the Dock work which only ship with one r8152. > > > It's really hard to say r8152 is from dock or another plugin one. > > > > > > If revert this patch, then most users with the original shipped > > > dock may lose this feature. That's the problem this patch try to > > > fix. > > > > I understand that. But i would say people can not expect such a crap > > feature on Linux, or we really need very good reasoning to cause MAC > > collisions with the real PHY and on top claim ETOOMANY of the > > dongles. > > > > The other vendors seem to check bits of the "golden" dongle. At > > least that is how i understand BD/AD/BND_MASK > > > > How about making it a module param and default to off, and dev_warn > > if BIOS has it turned on. That sounds like a reasonable compromise > > and whoever turns it on twice probably really wants it. (note that > > BIOS defaults to on ... so that was never intended by users, and > > corporate users might not be allowed/able to turn that off) > > > > MACs change ... all the time, people should use radius x509. The > > request is probably coming from corporate users, and they are all > > on a zero trust journey and will eventually stop relying on MACs > > anyways. > > > > And if ubuntu wants to cater by default, there can always be an udev > > rule or setting that module param to "on". > > Let's split the problem into the clear regression caused by the patch > and support of the feature on newer docks. I think we should fix the > regression ASAP (the patch has also been backported to 5.15, so it's > going to get more and more widely deployed). Then we can worry about > the MAC addr copy on newer docks and the feature in a wider context. > Is there really nothing in the usb info of the r8152 instance to > indicate that it's part of the dock? Does the device have EEPROM which > could contain useful info, maybe? As far as i can tell a simple revert will do the trick. In which case only "well known" docks will be affected and hopefully do not have any other r8152 dongles attached. If a dock does not have its own USB device ID ... like travel adaptors or plain USB ethernet thingys ... MAC inheritance might be "going too far". And if a new "active dock" shows up ... its device ID should be added and matched. But it is not easy to split up really ... because people might be using "active" docks from other vendors. Nobody said that i can not use an HP USB-C thingy for my Lenovo machine or the other way around. The code currently matches vendor specific ACPI with vendor specific USB, which creates a kind of nasty vendor lock-in situation for accessory. Henning > > > For now I suggest to disable it in BIOS if you got multiple r8152. > > > > > > Let me try to make some changes to limit this feature in one > > > r8152. > > > > Which one? ;) And how to deal with the real NIC once you picked one? > > Looking forward, please Cc me. >
