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

From: <Charles.Hyde@dellteam.com>
To: <Mario.Limonciello@dell.com>, <bjorn@mork.no>
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
Date: Tue, 27 Aug 2019 22:08:24 +0000	[thread overview]
Message-ID: <6e404c3d3c344342b09b475e64b4ff3e@AUSX13MPS303.AMER.DELL.COM> (raw)
In-Reply-To: <b3062089954f43259f8dfce9076b78ad@AUSX13MPC101.AMER.DELL.COM>

> > > 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.

Thank you,
Charles Hyde