> -----Original Message----- > From: David Miller [mailto:davem@xxxxxxxxxxxxx] > Sent: Saturday, June 11, 2016 12:42 PM > To: andrew@xxxxxxx > Cc: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>; > hayeswang@xxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > netdev@xxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; pali.rohar@xxxxxxxxx; > anthony.wong@xxxxxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH v6] r8152: Add support for setting pass through MAC > address on RTL8153-AD > > From: Andrew Lunn <andrew@xxxxxxx> > Date: Sat, 11 Jun 2016 17:39:21 +0200 > > > What is still open is do we want to accept it at all? Do we accept the > > concept of putting the same MAC address on multiple interfaces at > > hotplug time? Do we trust BIOS vendors to not keep changing DSDT > > property name, since it is not standardised? > > It's worth saying - standardized a property name doesn't indemnify it. Properties change all the time from one version of a spec to another. I can only speak for Dell, but it's in our best interest to keep the BIOS side of the codebase around this simpler too. > > Do we want this at all should be decided by somebody more senior then > > those passing comments on the code. > > Indeed, I think the behavior of using the same MAC address on multiple > interfaces if we plug several of these in at once is not good. > > We shouldn't behave this way just because the Microsoft driver does. This is really grasping at an extreme corner case scenario. Dell TB15 and WD15 docks are currently only ones on the market with RTL8135-AD and MAC address pass through efuse bit set. These docks are not inexpensive. If someone really wants multiple USB NIC's plugged in, they can pick up a second USB NIC from the web for far cheaper than buying a second dock. Also for what it's worth, the docks don't allow daisy chaining. The dock EC's will reject the second dock from functioning through the downstream connection. The only way that two docks could be hooked up and functional is on a machine with multiple type C ports. If you still think it's worth solving, what would you like done as an alternative? I would really like to have some implementation of this that you guys are comfortable with upstream. There was already discussion and an implementation in this thread about tracking if the aux MAC was assigned to something and only allowing one device to get that assignment. There was a limitation that you won't be able to know which device gets the auxiliary MAC address. It will be based solely upon hotplug order. There was also in one version of the patch a way to turn off this behavior In a module parameter. Greg KH wasn't fond of that, so it's not present in the current version. I can add either of those back in if they would help the case. Another option I wanted to offer was turning this behavior on via kernel configuration option and let the distros decide if they want to turn it on for users. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
