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

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

[Charles.Hyde]

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.

Signed-off-by: Charles Hyde <charles.hyde@dellteam.com>
Cc: Mario Limonciello <mario.limonciello@dell.com>
Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
Cc: linux-usb@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
---
 drivers/net/usb/r8152.c          | 44 +++--------------------
 include/acpi/acpi_mac_passthru.h | 16 +++++++++
 lib/Makefile                     |  3 +-
 lib/acpi_mac_passthru.c          | 61 ++++++++++++++++++++++++++++++++
 4 files changed, 83 insertions(+), 41 deletions(-)
 create mode 100644 include/acpi/acpi_mac_passthru.h
 create mode 100644 lib/acpi_mac_passthru.c

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0cc03a9ff545..b1dba3400b74 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -23,6 +23,7 @@
 #include <linux/usb/cdc.h>
 #include <linux/suspend.h>
 #include <linux/acpi.h>
+#include <acpi/acpi_mac_passthru.h>
 
 /* Information for net-next */
 #define NETNEXT_VERSION		"09"
@@ -1175,12 +1176,7 @@ static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
  */
 static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
 {
-	acpi_status status;
-	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
-	union acpi_object *obj;
-	int ret = -EINVAL;
 	u32 ocp_data;
-	unsigned char buf[6];
 
 	/* test for -AD variant of RTL8153 */
 	ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
@@ -1201,39 +1197,7 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
 			return -ENODEV;
 		}
 	}
-
-	/* returns _AUXMAC_#AABBCCDDEEFF# */
-	status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, &buffer);
-	obj = (union acpi_object *)buffer.pointer;
-	if (!ACPI_SUCCESS(status))
-		return -ENODEV;
-	if (obj->type != ACPI_TYPE_BUFFER || obj->string.length != 0x17) {
-		netif_warn(tp, probe, tp->netdev,
-			   "Invalid buffer for pass-thru MAC addr: (%d, %d)\n",
-			   obj->type, obj->string.length);
-		goto amacout;
-	}
-	if (strncmp(obj->string.pointer, "_AUXMAC_#", 9) != 0 ||
-	    strncmp(obj->string.pointer + 0x15, "#", 1) != 0) {
-		netif_warn(tp, probe, tp->netdev,
-			   "Invalid header when reading pass-thru MAC addr\n");
-		goto amacout;
-	}
-	ret = hex2bin(buf, obj->string.pointer + 9, 6);
-	if (!(ret == 0 && is_valid_ether_addr(buf))) {
-		netif_warn(tp, probe, tp->netdev,
-			   "Invalid MAC for pass-thru MAC addr: %d, %pM\n",
-			   ret, buf);
-		ret = -EINVAL;
-		goto amacout;
-	}
-	memcpy(sa->sa_data, buf, 6);
-	netif_info(tp, probe, tp->netdev,
-		   "Using pass-thru MAC addr %pM\n", sa->sa_data);
-
-amacout:
-	kfree(obj);
-	return ret;
+	return get_acpi_mac_passthru(&tp->intf->dev, sa);
 }
 
 static int determine_ethernet_addr(struct r8152 *tp, struct sockaddr *sa)
@@ -4309,10 +4273,10 @@ static int rtl8152_post_reset(struct usb_interface *intf)
 	if (!tp)
 		return 0;
 
-	/* reset the MAC adddress in case of policy change */
+	/* reset the MAC address in case of policy change */
 	if (determine_ethernet_addr(tp, &sa) >= 0) {
 		rtnl_lock();
-		dev_set_mac_address (tp->netdev, &sa, NULL);
+		dev_set_mac_address(tp->netdev, &sa, NULL);
 		rtnl_unlock();
 	}
 
diff --git a/include/acpi/acpi_mac_passthru.h b/include/acpi/acpi_mac_passthru.h
new file mode 100644
index 000000000000..fb2b114c2765
--- /dev/null
+++ b/include/acpi/acpi_mac_passthru.h
@@ -0,0 +1,16 @@
+/*
+ *  Copyright (c) 2019 Dell Technology. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/acpi.h>
+#include <linux/socket.h>
+
+int get_acpi_mac_passthru(struct device *dev, struct sockaddr *sa);
+
diff --git a/lib/Makefile b/lib/Makefile
index 29c02a924973..a902bec0ac65 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -35,7 +35,8 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
 	 flex_proportions.o ratelimit.o show_mem.o \
 	 is_single_threaded.o plist.o decompress.o kobject_uevent.o \
 	 earlycpio.o seq_buf.o siphash.o dec_and_lock.o \
-	 nmi_backtrace.o nodemask.o win_minmax.o memcat_p.o
+	 nmi_backtrace.o nodemask.o win_minmax.o memcat_p.o \
+	 acpi_mac_passthru.o
 
 lib-$(CONFIG_PRINTK) += dump_stack.o
 lib-$(CONFIG_MMU) += ioremap.o
diff --git a/lib/acpi_mac_passthru.c b/lib/acpi_mac_passthru.c
new file mode 100644
index 000000000000..832596433592
--- /dev/null
+++ b/lib/acpi_mac_passthru.c
@@ -0,0 +1,61 @@
+/*
+ *  Copyright (c) 2019 Dell Technology. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include <acpi/acpi_mac_passthru.h>
+#include <linux/etherdevice.h>
+
+int get_acpi_mac_passthru(struct device *dev, struct sockaddr *sa)
+{
+#ifdef CONFIG_ACPI
+	acpi_status status;
+	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+	union acpi_object *obj;
+	int ret = -EINVAL;
+	unsigned char buf[6];
+
+	/* returns _AUXMAC_#AABBCCDDEEFF# */
+	status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, &buffer);
+	obj = (union acpi_object *)buffer.pointer;
+	if (!ACPI_SUCCESS(status))
+		return -ENODEV;
+	if (obj->type != ACPI_TYPE_BUFFER || obj->string.length != 0x17) {
+		dev_warn(dev,
+			 "Invalid buffer for pass-thru MAC addr: (%d, %d)\n",
+			 obj->type, obj->string.length);
+		goto amacout;
+	}
+	if (strncmp(obj->string.pointer, "_AUXMAC_#", 9) != 0 ||
+	    strncmp(obj->string.pointer + 0x15, "#", 1) != 0) {
+		dev_warn(dev,
+			 "Invalid header when reading pass-thru MAC addr\n");
+		goto amacout;
+	}
+	ret = hex2bin(buf, obj->string.pointer + 9, 6);
+	if (!(ret == 0 && is_valid_ether_addr(buf))) {
+		dev_warn(dev,
+			 "Invalid MAC for pass-thru MAC addr: %d, %pM\n",
+			 ret, buf);
+		ret = -EINVAL;
+		goto amacout;
+	}
+	memcpy(sa->sa_data, buf, 6);
+	dev_info(dev, "Pass-thru MAC addr %pM\n", sa->sa_data);
+
+amacout:
+	kfree(obj);
+	return ret;
+
+#else	/* !CONFIG_ACPI */
+	(void)dev;
+	(void)sa;
+
+	return -ENODEV;
+#endif
+}
+EXPORT_SYMBOL_GPL(get_acpi_mac_passthru);
-- 
2.20.1

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

[Greg KH]

On Fri, Aug 23, 2019 at 10:28:24PM +0000, Charles.Hyde@dellteam.com wrote:
> --- /dev/null
> +++ b/lib/acpi_mac_passthru.c
> @@ -0,0 +1,61 @@
> +/*
> + *  Copyright (c) 2019 Dell Technology. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + */

You didn't run your patch through checkpatch.pl :(

Anyway, drop the license boilerplate please and use a SPDX line, like
checkpatch asks you to.

> +
> +#include <acpi/acpi_mac_passthru.h>
> +#include <linux/etherdevice.h>
> +
> +int get_acpi_mac_passthru(struct device *dev, struct sockaddr *sa)
> +{
> +#ifdef CONFIG_ACPI
> +	acpi_status status;
> +	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> +	union acpi_object *obj;
> +	int ret = -EINVAL;
> +	unsigned char buf[6];
> +
> +	/* returns _AUXMAC_#AABBCCDDEEFF# */
> +	status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, &buffer);
> +	obj = (union acpi_object *)buffer.pointer;
> +	if (!ACPI_SUCCESS(status))
> +		return -ENODEV;
> +	if (obj->type != ACPI_TYPE_BUFFER || obj->string.length != 0x17) {
> +		dev_warn(dev,
> +			 "Invalid buffer for pass-thru MAC addr: (%d, %d)\n",
> +			 obj->type, obj->string.length);
> +		goto amacout;
> +	}
> +	if (strncmp(obj->string.pointer, "_AUXMAC_#", 9) != 0 ||
> +	    strncmp(obj->string.pointer + 0x15, "#", 1) != 0) {
> +		dev_warn(dev,
> +			 "Invalid header when reading pass-thru MAC addr\n");
> +		goto amacout;
> +	}
> +	ret = hex2bin(buf, obj->string.pointer + 9, 6);
> +	if (!(ret == 0 && is_valid_ether_addr(buf))) {
> +		dev_warn(dev,
> +			 "Invalid MAC for pass-thru MAC addr: %d, %pM\n",
> +			 ret, buf);
> +		ret = -EINVAL;
> +		goto amacout;
> +	}
> +	memcpy(sa->sa_data, buf, 6);
> +	dev_info(dev, "Pass-thru MAC addr %pM\n", sa->sa_data);
> +
> +amacout:
> +	kfree(obj);
> +	return ret;
> +
> +#else	/* !CONFIG_ACPI */
> +	(void)dev;
> +	(void)sa;
> +
> +	return -ENODEV;

No #ifdef in .c files, especially for something as trivial as this.  The
#ifdef needs to be in the .h file, and don't build this unless acpi is
enabled.  And then, just move this to the acpi core, not in lib/

thanks,

greg k-h

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

[Bjørn Mork]

<Charles.Hyde@dellteam.com> writes:

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

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

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

[Mario.Limonciello]

> -----Original Message-----
> From: Bjørn Mork <bjorn@mork.no>
> Sent: Saturday, August 24, 2019 5:26 AM
> To: Hyde, Charles - Dell Team
> Cc: linux-acpi@vger.kernel.org; Limonciello, Mario; 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
> 
> 
> [EXTERNAL EMAIL]
> 
> <Charles.Hyde@dellteam.com> writes:
> 
> > 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

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

[Charles.Hyde]

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

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

[Mario.Limonciello]

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

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

[Charles.Hyde]

<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