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: Wed, 28 Aug 2019 16:41:53 +0000	[thread overview]
Message-ID: <d800fe75f26b4bd2aa59e5c176eae15a@AUSX13MPS307.AMER.DELL.COM> (raw)
In-Reply-To: <ae55e4a85d594e27a46cab32ad675208@AUSX13MPC101.AMER.DELL.COM>

<snipped>

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

There is nothing in this method that needs to be x86 only.  If this method is made available to other architectures, then it is possible for systems based on other architectures to benefit and make inroads into the enterprise space.  Dell might be the only company using this method, but it could be adopted by others for the same reasons Dell created it in the first place.

I looked at eth_platform_get_mac_address() per Bjørn's suggestion, and added a dev_info() statement to let me know if and when this driver function is executed when I booted my chromebook and plugged in a Dell Universal Dock D6000.  Unfortunately for my experiment, this function is not called.  Therefore, it makes no sense to add code here for Dell's needs at this time.  Furthermore, I believe that it is not now, nor was it ever, Dell's intention to have on-board ethernet MAC addresses be reprogrammed by this method.. I believe it was Dell's intention to apply this to only USB Type-C based ethernet devices, hence the original code was applied to only drivers/net/usb/r8152.c.  That is not to say this method is limited to only USB Type-C devices, it can be used by whomever for whichever drivers deem it advantageous, regardless of underlying CPU architecture.

-- 
Charles