RE: [RFC 2/3] ACPI: move ACPI functionality out of r8152 driver

[<Mario.Limonciello@dell.com>]

> -----Original Message-----
> From: Hyde, Charles - Dell Team
> Sent: Tuesday, August 27, 2019 5:08 PM
> To: Limonciello, Mario; Bjørn Mork
> Cc: linux-acpi@vger.kernel.org; oliver@neukum.org; nic_swsd@realtek.com;
> linux-usb@vger.kernel.org
> 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