> -----Original Message----- > From: Hyde, Charles - Dell Team > Sent: Tuesday, August 27, 2019 5:08 PM > To: Limonciello, Mario; Bjørn Mork > Cc: linux-acpi@xxxxxxxxxxxxxxx; oliver@xxxxxxxxxx; nic_swsd@xxxxxxxxxxx; > linux-usb@xxxxxxxxxxxxxxx > Subject: RE: [RFC 2/3] ACPI: move ACPI functionality out of r8152 driver > > > > > > This change moves ACPI functionality out of the Realtek r8152 driver > > > > to its own source and header file, making it available to other > > > > drivers as needed now and into the future. At the time this ACPI > > > > snippet was introduced in 2016, only the Realtek driver made use of > > > > it in support of Dell's enterprise IT policy efforts. There comes > > > > now a need for this same support in a different driver, also in > > > > support of Dell's enterprise IT policy efforts. > > > > > > Why not make a standalone driver out of this, making the MAC address > > > (and other system specifc objects?) available to userspace? Then you > > > can just distribute updated udev rules or systemd units or whatever > > > for the next docking product. > > > > > > I don't think system specific policies should be put into device > > > drivers. Users will combine systems and devices in ways you don't > > > foresee, and may have good reasons to want some non-default policy even > > for supported combinations. > > > > I recall that when this was first done for r8152 we actually experimented with > > exactly that and ran into two problems: > > > > 1) With userspace races with ethernet device renaming > > 2) The details needed to tell which devices this should apply to (such as eFuse > > settings or other identifying factors) aren't exported to userspace. > > > > We only want this applying to devices that keep the same policy in the > > firmware for things like PXE or HTTP booting and dual booting other operating > > systems. > > We've been very careful in r8152 that MAC passthrough only applies to the > > correct devices with unique identifiers to be a Dell dock as such. > > > > > > > > If you really want to have this policy in the driver(s), then please > > > consider extending eth_platform_get_mac_address() with an x86/acpi > > > method. This will make the device driver code support fetching the > > > mac address from device tree and Sparc idproms too. Provided the netdev > > folks things this is OK, of course. > > > This needs to be discussed there, like get_maintainer.pl would have told you. > > > > > > Making sure we can modify the MAC address of USB ethernet devices is > > > obviously a good thing regardless of how/where you fetch it. > > > > > > > > > > > > > > > > > > Bjørn > > By moving acpi_mac_passthru.c into drivers/acpi/, what is the suggested edit to > Makefile for this? I am thinking it could be added immediately following the > comment "These are (potentially) separate modules" with: > > apic-y += acpi_mac_passthru.o > > I removed extra spacing above for posting here. > I believe that Bjørn specifically recommended to put it in drivers/acpi/x86. Which that would mean it's: acpi-$(CONFIG_X86) += x86/acpi_mac_passthrough.o
