[PATCH v2] net: Add eth_platform_get_mac_address() helper.

A repeating pattern in drivers has become to use OF node information
and, if not found, platform specific host information to extract the
ethernet address for a given device.

Currently this is done with a call to of_get_mac_address() and then
some ifdef'd stuff for SPARC.

Consolidate this into a portable routine, and provide the
arch_get_platform_mac_address() weak function hook for all
architectures to implement if they want.

Signed-off-by: David S. Miller <davem@davemloft.net>
---

As promised back in November, I'm commiting this into net-next
now.  I'd work on the conversions of existing drivers, but I'd
rather someone with access to the hardware to so.

 arch/sparc/kernel/idprom.c  |  7 +++++++
 include/linux/etherdevice.h |  3 +++
 net/ethernet/eth.c          | 31 +++++++++++++++++++++++++++++++
 3 files changed, 41 insertions(+)

diff --git a/arch/sparc/kernel/idprom.c b/arch/sparc/kernel/idprom.c
index 6bd7501..f95dd11 100644
--- a/arch/sparc/kernel/idprom.c
+++ b/arch/sparc/kernel/idprom.c

@@ -9,6 +9,7 @@
 #include <linux/types.h>
 #include <linux/init.h>
 #include <linux/export.h>
+#include <linux/etherdevice.h>
 
 #include <asm/oplib.h>
 #include <asm/idprom.h>

@@ -60,6 +61,12 @@ static void __init display_system_type(unsigned char machtype)
 {
 }
 #endif
+
+unsigned char *arch_get_platform_mac_address(void)
+{
+	return idprom->id_ethaddr;
+}
+
 /* Calculate the IDPROM checksum (xor of the data bytes). */
 static unsigned char __init calc_idprom_cksum(struct idprom *idprom)
 {

diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index eb049c6..37ff4a6 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h

@@ -29,6 +29,9 @@
 #include <asm/bitsperlong.h>
 
 #ifdef __KERNEL__
+struct device;
+int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr);
+unsigned char *arch_get_platform_get_mac_address(void);
 u32 eth_get_headlen(void *data, unsigned int max_len);
 __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev);
 extern const struct header_ops eth_header_ops;

diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 9e63f25..1038717 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c

@@ -52,6 +52,8 @@
 #include <linux/errno.h>
 #include <linux/init.h>
 #include <linux/if_ether.h>
+#include <linux/of_net.h>
+#include <linux/pci.h>
 #include <net/dst.h>
 #include <net/arp.h>
 #include <net/sock.h>

@@ -485,3 +487,32 @@ static int __init eth_offload_init(void)
 }
 
 fs_initcall(eth_offload_init);
+
+unsigned char * __weak arch_get_platform_mac_address(void)
+{
+	return NULL;
+}
+
+int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr)
+{
+	const unsigned char *addr;
+	struct device_node *dp;
+
+	if (dev_is_pci(dev))
+		dp = pci_device_to_OF_node(to_pci_dev(dev));
+	else
+		dp = dev->of_node;
+
+	addr = NULL;
+	if (dp)
+		addr = of_get_mac_address(dp);
+	if (!addr)
+		addr = arch_get_platform_mac_address();
+
+	if (!addr)
+		return -ENODEV;
+
+	ether_addr_copy(mac_addr, addr);
+	return 0;
+}
+EXPORT_SYMBOL(eth_platform_get_mac_address);

-- 
2.4.1

On (01/06/16 16:33), David Miller wrote:

Signed-off-by: David S. Miller <davem@davemloft.net>

Acked-by: Sowmini Varadhan <redacted>

As promised back in November, I'm commiting this into net-next
now.  I'd work on the conversions of existing drivers, but I'd
rather someone with access to the hardware to so.

I'll look into this.

--Sowmini

On Wed, 2016-01-06 at 16:33 -0500, David Miller wrote:

A repeating pattern in drivers has become to use OF node information
and, if not found, platform specific host information to extract the
ethernet address for a given device.

[]

[]

WARN_ON_ONCE ?

Couldn't some oddball arch have an unaligned addr?

Joe Perches [off-list ref] writes:

On Wed, 2016-01-06 at 16:33 -0500, David Miller wrote:

quoted

A repeating pattern in drivers has become to use OF node information
and, if not found, platform specific host information to extract the
ethernet address for a given device.

[]

quoted

diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h

[]

quoted

@@ -485,3 +487,32 @@ static int __init eth_offload_init(void)

 }
 
 fs_initcall(eth_offload_init);
+
+unsigned char * __weak arch_get_platform_mac_address(void)
+{
+       return NULL;

WARN_ON_ONCE ?

That would prevent a driver from using this with additional fallback
methods.  For what reason?

I don't have a specific usecase, but I can imagine drivers falling back
to e.g a random address without wanting to be noisy about it.


Bjørn

On Thu, 2016-01-07 at 00:26 +0100, Bjørn Mork wrote:

Joe Perches [off-list ref] writes:

quoted

On Wed, 2016-01-06 at 16:33 -0500, David Miller wrote:

quoted

A repeating pattern in drivers has become to use OF node information
and, if not found, platform specific host information to extract the
ethernet address for a given device.

[]

quoted

diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h

[]

quoted

@@ -485,3 +487,32 @@ static int __init eth_offload_init(void)

 }
 
 fs_initcall(eth_offload_init);
+
+unsigned char * __weak arch_get_platform_mac_address(void)
+{
+       return NULL;

WARN_ON_ONCE ?

That would prevent a driver from using this with additional fallback
methods.  For what reason?

It's declared __weak and should be overridden by
an arch specific function.

A NULL address would cause a fault when using
a function like copy_ether_addr.

I don't have a specific usecase, but I can imagine drivers falling back
to e.g a random address without wanting to be noisy about it.

Joe Perches [off-list ref] writes:

On Thu, 2016-01-07 at 00:26 +0100, Bjørn Mork wrote:

quoted

Joe Perches [off-list ref] writes:

quoted

On Wed, 2016-01-06 at 16:33 -0500, David Miller wrote:

quoted

A repeating pattern in drivers has become to use OF node information
and, if not found, platform specific host information to extract the
ethernet address for a given device.

[]

quoted

diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h

[]

quoted

@@ -485,3 +487,32 @@ static int __init eth_offload_init(void)

 }
 
 fs_initcall(eth_offload_init);
+
+unsigned char * __weak arch_get_platform_mac_address(void)
+{
+       return NULL;

WARN_ON_ONCE ?

That would prevent a driver from using this with additional fallback
methods.  For what reason?

It's declared __weak and should be overridden by
an arch specific function.

"should"?  Why?  Do you have a suggested implementation for - say - x86?

A NULL address would cause a fault when using
a function like copy_ether_addr.

You should not do that then :)


Bjørn

From: Joe Perches <joe@perches.com>
Date: Wed, 06 Jan 2016 15:32:24 -0800

On Thu, 2016-01-07 at 00:26 +0100, Bjørn Mork wrote:

quoted

Joe Perches [off-list ref] writes:

quoted

On Wed, 2016-01-06 at 16:33 -0500, David Miller wrote:

quoted

A repeating pattern in drivers has become to use OF node information
and, if not found, platform specific host information to extract the
ethernet address for a given device.

[]

quoted

diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h

[]

quoted

@@ -485,3 +487,32 @@ static int __init eth_offload_init(void)

 }
 
 fs_initcall(eth_offload_init);
+
+unsigned char * __weak arch_get_platform_mac_address(void)
+{
+       return NULL;

WARN_ON_ONCE ?

That would prevent a driver from using this with additional fallback
methods.  For what reason?

It's declared __weak and should be overridden by
an arch specific function.

A NULL address would cause a fault when using
a function like copy_ether_addr.

The caller checks for NULL, and this is the default implementation
doing precisely what it is meant to do.

On Wed, 2016-01-06 at 19:01 -0500, David Miller wrote:

The caller checks for NULL, and this is the default implementation
doing precisely what it is meant to do.

Yeah, I noticed that later. Nevermind...

cheers, Joe

On (01/06/16 16:33), David Miller wrote:

A repeating pattern in drivers has become to use OF node information
and, if not found, platform specific host information to extract the
ethernet address for a given device.

    :

Consolidate this into a portable routine, and provide the
arch_get_platform_mac_address() weak function hook for all
architectures to implement if they want.

    :

As promised back in November, I'm commiting this into net-next
now.  I'd work on the conversions of existing drivers, but I'd
rather someone with access to the hardware to so.

I finally have all the ducks lined up for ixgbe/i40e around this. 
Should I go ahead and send this off (I think it first gets staged 
through Jeff's repo?) or is it better to wait for net-next to be 
open again?

--Sowmini

On Jan 12, 2016, at 16:49, Sowmini Varadhan [off-list ref] wrote:

quoted

On (01/06/16 16:33), David Miller wrote:

A repeating pattern in drivers has become to use OF node information
and, if not found, platform specific host information to extract the
ethernet address for a given device.

   :

quoted

Consolidate this into a portable routine, and provide the
arch_get_platform_mac_address() weak function hook for all
architectures to implement if they want.

   :

quoted

As promised back in November, I'm commiting this into net-next
now.  I'd work on the conversions of existing drivers, but I'd
rather someone with access to the hardware to so.

I finally have all the ducks lined up for ixgbe/i40e around this. 
Should I go ahead and send this off (I think it first gets staged 
through Jeff's repo?) or is it better to wait for net-next to be 
open again?

please go ahead and send it to intel-wired-lan@lists.osuosl.org so we can review and test the driver parts so when net-next opens it should be ready to push upstream.

From: Sowmini Varadhan <redacted>
Date: Tue, 12 Jan 2016 19:49:16 -0500

I finally have all the ducks lined up for ixgbe/i40e around this. 
Should I go ahead and send this off (I think it first gets staged 
through Jeff's repo?) or is it better to wait for net-next to be 
open again?

If you want to send it to Jeff and the Intel folks for them to
queue it up there, that's fine.