[RFC PATCH 0/2] OMAP2+: PANDA: Provide unique-ish MAC addresses for Ethernet and WLAN interfaces

[RFC PATCH 0/2] OMAP2+: PANDA: Provide unique-ish MAC addresses for Ethernet and WLAN interfaces

[Andy Green]

The following series solves a problem Panda suffers from where
because there is no local MAC address storage on the board, a
new random MAC address is applied to the onboard Ethernet
interface each time, and the wl12xx module's wlan0 interface is
always found with an unworkable 00:00:00:00:00:00 MAC.

The series adds an omap id-related API to generate a
6-byte Ethernet MAC address from "hashing" a little the CPU ID
registers.  It is understood from TI that these contain data
that at least in a subset of the 128 bits of the ID are unique per-CPU.

It then introduces code in the Panda board definition file to
watch network interface creation and if the device's path is on
a list, set its MAC address to the CPU ID-generated one, plus
two bits which differ according to which interface in the list
is being changed.  (This scheme was suggested by Alan Cox).

The device paths for the onboard Ethernet smsc95xx, and the
onboard WLAN wl12xx are listed, so both of these will get
assigned a consistent, unique-ish locally administered MAC
address with these patches.

It's beleived the current scheme for MAC generation from ID
data captures most of the entropy, but if there is a better scheme
more closely mapped to what the unique factory areas are advice
is welcome.

The patches are against linux-omap which already has a prerequisite
patch that fixes a problem with device ID capture on OMAP4.

---

Andy Green (2):
      OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0
      OMAP2+: add cpu id register to MAC address helper


 arch/arm/mach-omap2/board-omap4panda.c |   91 ++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/id.c               |   39 ++++++++++++++
 arch/arm/mach-omap2/include/mach/id.h  |    1 
 3 files changed, 131 insertions(+), 0 deletions(-)

-- 
Signature

[RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

[Andy Green]

Introduce a generic helper function that can set a MAC address using
data from the OMAP unique CPU ID register.

For comparison purposes this produces a MAC address of

  2e:40:70:f0:12:06

for the ethernet device on my Panda.


Note that this patch requires the fix patch for CPU ID register
indexes previously posted to linux-omap, otherwise the CPU ID is
misread on Panda by the existing function to do it.  This patch
is already on linux-omap.

"OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430"
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b235e007831dbf57710e59cd4a120e2f374eecb9

Signed-off-by: Andy Green <andy.green@linaro.org>
---

 arch/arm/mach-omap2/id.c              |   39 +++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/include/mach/id.h |    1 +
 2 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2537090..e46b430 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -557,3 +557,42 @@ void __init omap2_set_globals_tap(struct omap_globals *omap2_globals)
 	else
 		tap_prod_id = 0x0208;
 }
+
+/*
+ * this uses the unique per-cpu info from the cpu fuses set at factory to
+ * generate a 6-byte MAC address.  Two bits in the generated code are used
+ * to elaborate the generated address into four, so it can be used on multiple
+ * network interfaces.
+ */
+
+void omap2_die_id_to_ethernet_mac(u8 *mac, int subtype)
+{
+	struct omap_die_id odi;
+	u32 tap = read_tap_reg(OMAP_TAP_IDCODE);
+
+	omap_get_die_id(&odi);
+
+	mac[0] = odi.id_2;
+	mac[1] = odi.id_2 >> 8;
+	mac[2] = odi.id_1;
+	mac[3] = odi.id_1 >> 8;
+	mac[4] = odi.id_1 >> 16;
+	mac[5] = odi.id_1 >> 24;
+
+	/* XOR other chip-specific data with ID */
+
+	tap ^= odi.id_3;
+
+	mac[0] ^= tap;
+	mac[1] ^= tap >> 8;
+	mac[2] ^= tap >> 16;
+	mac[3] ^= tap >> 24;
+
+	/* allow four MACs from this same basic data */
+
+	mac[1] = (mac[1] & ~0xc0) | ((subtype & 3) << 6);
+
+	/* mark it as not multicast and outside official 80211 MAC namespace */
+
+	mac[0] = (mac[0] & ~1) | 2;
+}
diff --git a/arch/arm/mach-omap2/include/mach/id.h b/arch/arm/mach-omap2/include/mach/id.h
index 02ed3aa..373313a 100644
--- a/arch/arm/mach-omap2/include/mach/id.h
+++ b/arch/arm/mach-omap2/include/mach/id.h
@@ -18,5 +18,6 @@ struct omap_die_id {
 };
 
 void omap_get_die_id(struct omap_die_id *odi);
+void omap2_die_id_to_ethernet_mac(u8 *mac, int subtype);
 
 #endif

[RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

[Arnd Bergmann]

On Thursday 24 March 2011, Andy Green wrote:
> Introduce a generic helper function that can set a MAC address using
> data from the OMAP unique CPU ID register.
> 
> For comparison purposes this produces a MAC address of
> 
>   2e:40:70:f0:12:06
> 
> for the ethernet device on my Panda.
> 
> 
> Note that this patch requires the fix patch for CPU ID register
> indexes previously posted to linux-omap, otherwise the CPU ID is
> misread on Panda by the existing function to do it.  This patch
> is already on linux-omap.
> 
> "OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430"
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b235e007831dbf57710e59cd4a120e2f374eecb9
> 
> Signed-off-by: Andy Green <andy.green@linaro.org>

Acked-by: Arnd Bergmann <arnd@arndb.de>

TI folks: While this is a working solution, I still think it would
be good to get an officially sanctioned method that allows the creation
of a IEEE 802 MAC address in a range assigned to TI instead of using
an address from the locally administered range.

Is that something that can be done?

	Arnd

[RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

[Andy Green]

On 03/25/2011 11:49 AM, Somebody in the thread at some point said:
> On Thursday 24 March 2011, Andy Green wrote:
>> Introduce a generic helper function that can set a MAC address using
>> data from the OMAP unique CPU ID register.
>>
>> For comparison purposes this produces a MAC address of
>>
>>    2e:40:70:f0:12:06
>>
>> for the ethernet device on my Panda.
>>
>>
>> Note that this patch requires the fix patch for CPU ID register
>> indexes previously posted to linux-omap, otherwise the CPU ID is
>> misread on Panda by the existing function to do it.  This patch
>> is already on linux-omap.
>>
>> "OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430"
>> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b235e007831dbf57710e59cd4a120e2f374eecb9
>>
>> Signed-off-by: Andy Green<andy.green@linaro.org>
>
> Acked-by: Arnd Bergmann<arnd@arndb.de>

Thanks.

> TI folks: While this is a working solution, I still think it would
> be good to get an officially sanctioned method that allows the creation
> of a IEEE 802 MAC address in a range assigned to TI instead of using
> an address from the locally administered range.
>
> Is that something that can be done?

Having a proper MAC from IEEE assigned for each interface is of course 
ideal.

But even if that happened today though, on Panda there is no "board 
identity storage" to put the reserved MAC addresses in to bind it to the 
physical board.  If you try to manage them on SD Card, you have the 
problem of dealing with correct MAC addresses needing putting there 
again every time it is nuked.  So it doesn't in itself help in the Panda 
case.

David Anders mentioned yesterday that for next OMAP board, he probably 
puts a general board identity EEPROM where one could stash MACs.  This 
kind of API can be extended to query the EEPROM at device-register-time 
and fetch the MAC instead of compute it.  So I think we go in a 
reasonable direction even when it is possible to get assigned MACs.

-Andy

[RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

[Arnd Bergmann]

On Friday 25 March 2011, Andy Green wrote:
> Having a proper MAC from IEEE assigned for each interface is of course 
> ideal.
> 
> But even if that happened today though, on Panda there is no "board 
> identity storage" to put the reserved MAC addresses in to bind it to the 
> physical board.  If you try to manage them on SD Card, you have the 
> problem of dealing with correct MAC addresses needing putting there 
> again every time it is nuked.  So it doesn't in itself help in the Panda 
> case.

What I meant is computing an official MAC address from the same input
data as you already do. Unfortunately that would mean having at most 24
bits available instead of the 44 or so bits you currently use, because
the upper half of the address then becomes fixed.

Also it would require
1. defining an new algorithm that computes the lower 24 bits from the
   die ID in a way that minimises the chances of collision
2. Getting an official identifier for the upper half of the address
   assigned to the OMAP3/OMAP4 CPUs
3. Documenting this method in the OMAP data sheets.

	Arnd

[RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

[Andy Green]

On 03/25/2011 01:24 PM, Somebody in the thread at some point said:
> On Friday 25 March 2011, Andy Green wrote:
>> Having a proper MAC from IEEE assigned for each interface is of course
>> ideal.
>>
>> But even if that happened today though, on Panda there is no "board
>> identity storage" to put the reserved MAC addresses in to bind it to the
>> physical board.  If you try to manage them on SD Card, you have the
>> problem of dealing with correct MAC addresses needing putting there
>> again every time it is nuked.  So it doesn't in itself help in the Panda
>> case.
>
> What I meant is computing an official MAC address from the same input
> data as you already do. Unfortunately that would mean having at most 24
> bits available instead of the 44 or so bits you currently use, because
> the upper half of the address then becomes fixed.
>
> Also it would require
> 1. defining an new algorithm that computes the lower 24 bits from the
>     die ID in a way that minimises the chances of collision
> 2. Getting an official identifier for the upper half of the address
>     assigned to the OMAP3/OMAP4 CPUs
> 3. Documenting this method in the OMAP data sheets.

I see.  It would work OK then.  They probably wouldn't want to blow 
their $1750 just on Panda though, so maybe they set 4 bits or whatever 
and let 20 be computed.

However, the only practical advantage is that it would show up as a TI 
MAC in an OUI database.  The "locally administered" address as used at 
the moment is otherwise legal in every respect AFAIK.

-Andy

[RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

[Arnd Bergmann]

On Friday 25 March 2011, Andy Green wrote:
> I see.  It would work OK then.  They probably wouldn't want to blow 
> their $1750 just on Panda though, so maybe they set 4 bits or whatever 
> and let 20 be computed.

Well, if the algorithm is defined well, it could be used for any device
based on OMAP. The marketing department could turn this into a win by
declaring "does not require external EEPROM for ethernet mac address" ;-)
 
> However, the only practical advantage is that it would show up as a TI 
> MAC in an OUI database.  The "locally administered" address as used at 
> the moment is otherwise legal in every respect AFAIK.

It should work almost always, except in very special corner cases:

* If you have a netboot setup, you want the boot loader to use the
same mac address for requesting the kernel image that you use later,
otherwise the switch might consider it a MAC spoofing attach and disable
the port. The obvious workaround is to put your code into the boot loader
as well.

* Some environments might be configured to disallow locally administered
MAC addresses for "security" reasons. A bit bogus, but not unheard of.

* Some places try to keep a database of all used machines and their MAC
addresses to monitor who connects to the network. This requires the address
to be stable. It also prevents the use of virtualization, so it's becoming
less common.

	Arnd

[RFC PATCH 1/2] OMAP2+: add cpu id register to MAC address helper

[Andy Green]

On 03/25/2011 02:50 PM, Somebody in the thread at some point said:
> On Friday 25 March 2011, Andy Green wrote:
>> I see.  It would work OK then.  They probably wouldn't want to blow
>> their $1750 just on Panda though, so maybe they set 4 bits or whatever
>> and let 20 be computed.
>
> Well, if the algorithm is defined well, it could be used for any device
> based on OMAP. The marketing department could turn this into a win by
> declaring "does not require external EEPROM for ethernet mac address" ;-)

Okay, can't argue with it ^^

> * Some places try to keep a database of all used machines and their MAC
> addresses to monitor who connects to the network. This requires the address
> to be stable. It also prevents the use of virtualization, so it's becoming
> less common.

They will probably just be happy the crazy noise they have been seeing 
from current Panda MACs changing every session will go away, it doesn't 
seem to add anything it's an OUI namespace MAC.  In the patch case the 
"locally administered" mac will be "stable".

Anyway since I understood it, I can see your idea is a cool approach, 
it's up to TI what they will do about it but I guess it's OK with or 
without it.

-Andy

[RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

[Andy Green]

This patch registers a network device notifier callback to set the mac
addresses for the onboard network assets of Panda correctly, despite the
drivers involved have used a random or all-zeros MAC address.

The technique was suggested by Alan Cox on lkml.

It works by device path so it corrects the MAC addresses even if the
drivers are in modules loaded in an order that changes their interface
name from usual (eg, the onboard module might be "wlan1" if there is a
USB wireless stick plugged in and its module is inserted first.)

Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andy Green <andy.green@linaro.org>
---

 arch/arm/mach-omap2/board-omap4panda.c |   91 ++++++++++++++++++++++++++++++++
 1 files changed, 91 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 80b8860..0b92873 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -28,9 +28,12 @@
 #include <linux/regulator/machine.h>
 #include <linux/regulator/fixed.h>
 #include <linux/wl12xx.h>
+#include <linux/netdevice.h>
+#include <linux/if_ether.h>
 
 #include <mach/hardware.h>
 #include <mach/omap4-common.h>
+#include <mach/id.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -506,6 +509,92 @@ static inline void board_serial_init(void)
 }
 #endif
 
+/*
+ * These device paths represent the onboard USB <-> Ethernet bridge, and
+ * the WLAN module on Panda, both of which need their random or all-zeros
+ * mac address replacing with a per-cpu stable generated one
+ */
+
+static const char * const panda_fixup_mac_device_paths[] = {
+	"usb1/1-1/1-1.1/1-1.1:1.0",
+	"mmc1:0001:2",
+};
+
+static int panda_device_path_need_mac(struct device *dev)
+{
+	const char **try = panda_fixup_mac_device_paths;
+	const char *path;
+	int count = ARRAY_SIZE(panda_fixup_mac_device_paths);
+	const char *p;
+	int len;
+	struct device *devn;
+
+	while (count--) {
+
+		p = *try + strlen(*try);
+		devn = dev;
+
+		while (devn) {
+
+			path = dev_name(devn);
+			len = strlen(path);
+
+			if ((p - *try) < len) {
+				devn = NULL;
+				continue;
+			}
+
+			p -= len;
+
+			if (strncmp(path, p, len)) {
+				devn = NULL;
+				continue;
+			}
+
+			devn = devn->parent;
+			if (p == *try)
+				return count;
+
+			if (devn != NULL && (p - *try) < 2)
+				devn = NULL;
+
+			p--;
+			if (devn != NULL && *p != '/')
+				devn = NULL;
+		}
+
+		try++;
+	}
+
+	return -ENOENT;
+}
+
+static int omap_panda_netdev_event(struct notifier_block *this,
+						 unsigned long event, void *ptr)
+{
+	struct net_device *dev = ptr;
+	struct sockaddr sa;
+	int n;
+
+	if (event != NETDEV_REGISTER)
+		return NOTIFY_DONE;
+
+	n = panda_device_path_need_mac(dev->dev.parent);
+	if (n >= 0) {
+		sa.sa_family = dev->type;
+		omap2_die_id_to_ethernet_mac(sa.sa_data, n);
+		dev->netdev_ops->ndo_set_mac_address(dev, &sa);
+	}
+
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block omap_panda_netdev_notifier = {
+	.notifier_call = omap_panda_netdev_event,
+	.priority = 1,
+};
+
+
 static void __init omap4_panda_init(void)
 {
 	int package = OMAP_PACKAGE_CBS;
@@ -517,6 +606,8 @@ static void __init omap4_panda_init(void)
 	if (wl12xx_set_platform_data(&omap_panda_wlan_data))
 		pr_err("error setting wl12xx data\n");
 
+	register_netdevice_notifier(&omap_panda_netdev_notifier);
+
 	omap4_panda_i2c_init();
 	platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
 	platform_device_register(&omap_vwlan_device);

[RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

[Hema Kalliguddi]

Hi,

one Minor comment.

>-----Original Message-----
From: linux-omap-owner@vger.kernel.org
>[mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Andy Green
>Sent: Friday, March 25, 2011 2:58 AM
>To: linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org
>Cc: patches at linaro.org; nicolas.pitre at linaro.org;
>arnd at arndb.de; x0132446 at ti.com; s-jan at ti.com;
>tony at atomide.com; Alan Cox; Andy Green
>Subject: [RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or
>missing MAC addresses for eth0 and wlan0
>
>This patch registers a network device notifier callback to set the mac
>addresses for the onboard network assets of Panda correctly,
>despite the
>drivers involved have used a random or all-zeros MAC address.
>
>The technique was suggested by Alan Cox on lkml.
>
>It works by device path so it corrects the MAC addresses even if the
>drivers are in modules loaded in an order that changes their interface
>name from usual (eg, the onboard module might be "wlan1" if there is a
>USB wireless stick plugged in and its module is inserted first.)
>
>Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
>Signed-off-by: Andy Green <andy.green@linaro.org>
>---
>
> arch/arm/mach-omap2/board-omap4panda.c |   91
>++++++++++++++++++++++++++++++++
> 1 files changed, 91 insertions(+), 0 deletions(-)
>
>diff --git a/arch/arm/mach-omap2/board-omap4panda.c
>b/arch/arm/mach-omap2/board-omap4panda.c
>index 80b8860..0b92873 100644
>--- a/arch/arm/mach-omap2/board-omap4panda.c
>+++ b/arch/arm/mach-omap2/board-omap4panda.c
>@@ -28,9 +28,12 @@
> #include <linux/regulator/machine.h>
> #include <linux/regulator/fixed.h>
> #include <linux/wl12xx.h>
>+#include <linux/netdevice.h>
>+#include <linux/if_ether.h>
>
> #include <mach/hardware.h>
> #include <mach/omap4-common.h>
>+#include <mach/id.h>
> #include <asm/mach-types.h>
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
>@@ -506,6 +509,92 @@ static inline void board_serial_init(void)
> }
> #endif
>
>+/*
>+ * These device paths represent the onboard USB <-> Ethernet
>bridge, and
>+ * the WLAN module on Panda, both of which need their random
>or all-zeros
>+ * mac address replacing with a per-cpu stable generated one
>+ */
>+
>+static const char * const panda_fixup_mac_device_paths[] = {
>+	"usb1/1-1/1-1.1/1-1.1:1.0",
>+	"mmc1:0001:2",
>+};
>+
>+static int panda_device_path_need_mac(struct device *dev)
>+{
>+	const char **try = panda_fixup_mac_device_paths;
>+	const char *path;
>+	int count = ARRAY_SIZE(panda_fixup_mac_device_paths);
>+	const char *p;
>+	int len;
>+	struct device *devn;
>+
>+	while (count--) {
>+
>+		p = *try + strlen(*try);
>+		devn = dev;
>+
>+		while (devn) {
>+
>+			path = dev_name(devn);
>+			len = strlen(path);
>+
>+			if ((p - *try) < len) {
>+				devn = NULL;
>+				continue;
>+			}
>+
>+			p -= len;
>+
>+			if (strncmp(path, p, len)) {
>+				devn = NULL;
>+				continue;
>+			}
>+
>+			devn = devn->parent;
>+			if (p == *try)
>+				return count;
>+
>+			if (devn != NULL && (p - *try) < 2)
>+				devn = NULL;
>+
>+			p--;
>+			if (devn != NULL && *p != '/')
>+				devn = NULL;
>+		}
>+
>+		try++;
>+	}
>+
>+	return -ENOENT;
>+}
>+
>+static int omap_panda_netdev_event(struct notifier_block *this,
>+						 unsigned long
>event, void *ptr)
>+{
>+	struct net_device *dev = ptr;
>+	struct sockaddr sa;
>+	int n;
>+
>+	if (event != NETDEV_REGISTER)
>+		return NOTIFY_DONE;
>+
>+	n = panda_device_path_need_mac(dev->dev.parent);
>+	if (n >= 0) {
>+		sa.sa_family = dev->type;
>+		omap2_die_id_to_ethernet_mac(sa.sa_data, n);
>+		dev->netdev_ops->ndo_set_mac_address(dev, &sa);
>+	}
>+
>+	return NOTIFY_DONE;
>+}
>+
>+static struct notifier_block omap_panda_netdev_notifier = {
>+	.notifier_call = omap_panda_netdev_event,
>+	.priority = 1,
>+};
>+
>+

One extra blank line not needed.

Regards,
Hema

> static void __init omap4_panda_init(void)
> {
> 	int package = OMAP_PACKAGE_CBS;
>@@ -517,6 +606,8 @@ static void __init omap4_panda_init(void)
> 	if (wl12xx_set_platform_data(&omap_panda_wlan_data))
> 		pr_err("error setting wl12xx data\n");
>
>+	register_netdevice_notifier(&omap_panda_netdev_notifier);
>+
> 	omap4_panda_i2c_init();
> 	platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
> 	platform_device_register(&omap_vwlan_device);
>
>--
>To unsubscribe from this list: send the line "unsubscribe
>linux-omap" in
>the body of a message to majordomo at vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

[Jason Kridner]

On Fri, Mar 25, 2011 at 3:39 AM, Hema Kalliguddi <hemahk@ti.com> wrote:
> Hi,
>
> one Minor comment.
>
>>-----Original Message-----
>>From: linux-omap-owner at vger.kernel.org
>>[mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Andy Green
>>Sent: Friday, March 25, 2011 2:58 AM
>>To: linux-arm-kernel at lists.infradead.org; linux-omap at vger.kernel.org
>>Cc: patches at linaro.org; nicolas.pitre at linaro.org;
>>arnd at arndb.de; x0132446 at ti.com; s-jan at ti.com;
>>tony at atomide.com; Alan Cox; Andy Green
>>Subject: [RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or
>>missing MAC addresses for eth0 and wlan0
>>
>>This patch registers a network device notifier callback to set the mac
>>addresses for the onboard network assets of Panda correctly,
>>despite the
>>drivers involved have used a random or all-zeros MAC address.
>>
>>The technique was suggested by Alan Cox on lkml.
>>
>>It works by device path so it corrects the MAC addresses even if the
>>drivers are in modules loaded in an order that changes their interface
>>name from usual (eg, the onboard module might be "wlan1" if there is a
>>USB wireless stick plugged in and its module is inserted first.)
>>
>>Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
>>Signed-off-by: Andy Green <andy.green@linaro.org>

I very much like this approach.  I believed the ability to use the die
ID to get a unique code was reasonable approach and that is why I
didn't get an EEPROM put onto the BeagleBoard, though Gerald is
looking at adding one on a future revision because the lack of one
wasn't well received.  Minor questions below.

>>---
>>
>> arch/arm/mach-omap2/board-omap4panda.c | ? 91
>>++++++++++++++++++++++++++++++++
>> 1 files changed, 91 insertions(+), 0 deletions(-)
>>
>>diff --git a/arch/arm/mach-omap2/board-omap4panda.c
>>b/arch/arm/mach-omap2/board-omap4panda.c
>>index 80b8860..0b92873 100644
>>--- a/arch/arm/mach-omap2/board-omap4panda.c
>>+++ b/arch/arm/mach-omap2/board-omap4panda.c
>>@@ -28,9 +28,12 @@
>> #include <linux/regulator/machine.h>
>> #include <linux/regulator/fixed.h>
>> #include <linux/wl12xx.h>
>>+#include <linux/netdevice.h>
>>+#include <linux/if_ether.h>
>>
>> #include <mach/hardware.h>
>> #include <mach/omap4-common.h>
>>+#include <mach/id.h>
>> #include <asm/mach-types.h>
>> #include <asm/mach/arch.h>
>> #include <asm/mach/map.h>
>>@@ -506,6 +509,92 @@ static inline void board_serial_init(void)
>> }
>> #endif
>>
>>+/*
>>+ * These device paths represent the onboard USB <-> Ethernet
>>bridge, and
>>+ * the WLAN module on Panda, both of which need their random
>>or all-zeros
>>+ * mac address replacing with a per-cpu stable generated one
>>+ */
>>+
>>+static const char * const panda_fixup_mac_device_paths[] = {
>>+ ? ? ?"usb1/1-1/1-1.1/1-1.1:1.0",
>>+ ? ? ?"mmc1:0001:2",
>>+};
>>+
>>+static int panda_device_path_need_mac(struct device *dev)
>>+{
>>+ ? ? ?const char **try = panda_fixup_mac_device_paths;
>>+ ? ? ?const char *path;
>>+ ? ? ?int count = ARRAY_SIZE(panda_fixup_mac_device_paths);
>>+ ? ? ?const char *p;
>>+ ? ? ?int len;
>>+ ? ? ?struct device *devn;
>>+
>>+ ? ? ?while (count--) {
>>+
>>+ ? ? ? ? ? ? ?p = *try + strlen(*try);
>>+ ? ? ? ? ? ? ?devn = dev;
>>+
>>+ ? ? ? ? ? ? ?while (devn) {
>>+
>>+ ? ? ? ? ? ? ? ? ? ? ?path = dev_name(devn);
>>+ ? ? ? ? ? ? ? ? ? ? ?len = strlen(path);
>>+
>>+ ? ? ? ? ? ? ? ? ? ? ?if ((p - *try) < len) {
>>+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?devn = NULL;
>>+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?continue;
>>+ ? ? ? ? ? ? ? ? ? ? ?}
>>+
>>+ ? ? ? ? ? ? ? ? ? ? ?p -= len;
>>+
>>+ ? ? ? ? ? ? ? ? ? ? ?if (strncmp(path, p, len)) {
>>+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?devn = NULL;
>>+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?continue;
>>+ ? ? ? ? ? ? ? ? ? ? ?}
>>+
>>+ ? ? ? ? ? ? ? ? ? ? ?devn = devn->parent;
>>+ ? ? ? ? ? ? ? ? ? ? ?if (p == *try)
>>+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return count;
>>+
>>+ ? ? ? ? ? ? ? ? ? ? ?if (devn != NULL && (p - *try) < 2)
>>+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?devn = NULL;
>>+
>>+ ? ? ? ? ? ? ? ? ? ? ?p--;
>>+ ? ? ? ? ? ? ? ? ? ? ?if (devn != NULL && *p != '/')
>>+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?devn = NULL;
>>+ ? ? ? ? ? ? ?}
>>+
>>+ ? ? ? ? ? ? ?try++;
>>+ ? ? ?}
>>+
>>+ ? ? ?return -ENOENT;
>>+}
>>+
>>+static int omap_panda_netdev_event(struct notifier_block *this,
>>+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unsigned long

The use of the OMAP die id below makes this OMAP specific and the list
referenced below of the devices to be referenced makes it Panda
specific.  Is there a way to make the list board specific, but to make
these functions that will be used across many OMAP platforms reusable?
 I believe that this current code will result in a lot of
cut-and-paste.  My preference is that this is accepted and that we
make this more general when we add this to other OMAP platforms, but
it'd be great to capture your suggestions on how to do so before those
cut-and-paste patch sets start coming in.

>>event, void *ptr)
>>+{
>>+ ? ? ?struct net_device *dev = ptr;
>>+ ? ? ?struct sockaddr sa;
>>+ ? ? ?int n;
>>+
>>+ ? ? ?if (event != NETDEV_REGISTER)
>>+ ? ? ? ? ? ? ?return NOTIFY_DONE;
>>+
>>+ ? ? ?n = panda_device_path_need_mac(dev->dev.parent);
>>+ ? ? ?if (n >= 0) {
>>+ ? ? ? ? ? ? ?sa.sa_family = dev->type;
>>+ ? ? ? ? ? ? ?omap2_die_id_to_ethernet_mac(sa.sa_data, n);
>>+ ? ? ? ? ? ? ?dev->netdev_ops->ndo_set_mac_address(dev, &sa);
>>+ ? ? ?}
>>+
>>+ ? ? ?return NOTIFY_DONE;
>>+}
>>+
>>+static struct notifier_block omap_panda_netdev_notifier = {
>>+ ? ? ?.notifier_call = omap_panda_netdev_event,
>>+ ? ? ?.priority = 1,
>>+};
>>+
>>+
>
> One extra blank line not needed.
>
> Regards,
> Hema
>
>> static void __init omap4_panda_init(void)
>> {
>> ? ? ? int package = OMAP_PACKAGE_CBS;
>>@@ -517,6 +606,8 @@ static void __init omap4_panda_init(void)
>> ? ? ? if (wl12xx_set_platform_data(&omap_panda_wlan_data))
>> ? ? ? ? ? ? ? pr_err("error setting wl12xx data\n");
>>
>>+ ? ? ?register_netdevice_notifier(&omap_panda_netdev_notifier);
>>+

I just want to make sure I understand how this works.  When a new
network device is added, if the device name matches one of the above
listed device paths, then the die id based MAC id is applied.  This
must be done via a device registration notifier as the registration is
triggered when the device is detected.

>> ? ? ? omap4_panda_i2c_init();
>> ? ? ? platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
>> ? ? ? platform_device_register(&omap_vwlan_device);
>>
>>--
>>To unsubscribe from this list: send the line "unsubscribe
>>linux-omap" in
>>the body of a message to majordomo at vger.kernel.org
>>More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>

[RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

[Arnd Bergmann]

On Friday 25 March 2011 21:13:05 Jason Kridner wrote:
> The use of the OMAP die id below makes this OMAP specific and the list
> referenced below of the devices to be referenced makes it Panda
> specific.  Is there a way to make the list board specific, but to make
> these functions that will be used across many OMAP platforms reusable?
>  I believe that this current code will result in a lot of
> cut-and-paste.  My preference is that this is accepted and that we
> make this more general when we add this to other OMAP platforms, but
> it'd be great to capture your suggestions on how to do so before those
> cut-and-paste patch sets start coming in.
 
Do you know of other existing boards without the EEPROM?
If we need the code to be more general, it will simply have
to move out of the panda specific board file into one file
that can be selected for compilation by other boards.

> >> static void __init omap4_panda_init(void)
> >> {
> >>       int package = OMAP_PACKAGE_CBS;
> >>@@ -517,6 +606,8 @@ static void __init omap4_panda_init(void)
> >>       if (wl12xx_set_platform_data(&omap_panda_wlan_data))
> >>               pr_err("error setting wl12xx data\n");
> >>
> >>+      register_netdevice_notifier(&omap_panda_netdev_notifier);
> >>+
> 
> I just want to make sure I understand how this works.  When a new
> network device is added, if the device name matches one of the above
> listed device paths, then the die id based MAC id is applied.  This
> must be done via a device registration notifier as the registration is
> triggered when the device is detected.

Correct.

	Arnd

[RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

[Nicolas Pitre]

On Fri, 25 Mar 2011, Jason Kridner wrote:

> I very much like this approach.  I believed the ability to use the die
> ID to get a unique code was reasonable approach and that is why I
> didn't get an EEPROM put onto the BeagleBoard, though Gerald is
> looking at adding one on a future revision because the lack of one
> wasn't well received.  Minor questions below.

If this code had been available and/or the procedure well documented 
before then I believe the reception would have been better.

> The use of the OMAP die id below makes this OMAP specific and the list
> referenced below of the devices to be referenced makes it Panda
> specific.  Is there a way to make the list board specific, but to make
> these functions that will be used across many OMAP platforms reusable?
>  I believe that this current code will result in a lot of
> cut-and-paste.  My preference is that this is accepted and that we
> make this more general when we add this to other OMAP platforms, but
> it'd be great to capture your suggestions on how to do so before those
> cut-and-paste patch sets start coming in.

It is true that this might get copied.  But as I suggested to Andy, it 
is best to wait and see how often this happens before generalizing the 
approach.  Consolidation is easier when you can see what is actually 
common and what is board specific.  Otherwise it is easy to 
fall into the over-engineering trap.


Nicolas

[RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

[Jason Kridner]

On Fri, Mar 25, 2011 at 4:23 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Fri, 25 Mar 2011, Jason Kridner wrote:
>
>> I very much like this approach. ?I believed the ability to use the die
>> ID to get a unique code was reasonable approach and that is why I
>> didn't get an EEPROM put onto the BeagleBoard, though Gerald is
>> looking at adding one on a future revision because the lack of one
>> wasn't well received. ?Minor questions below.
>
> If this code had been available and/or the procedure well documented
> before then I believe the reception would have been better.

Understood.  Live and learn and try not to repeat the same mistakes.
Hopefully others pick up on this one.

>
>> The use of the OMAP die id below makes this OMAP specific and the list
>> referenced below of the devices to be referenced makes it Panda
>> specific. ?Is there a way to make the list board specific, but to make
>> these functions that will be used across many OMAP platforms reusable?
>> ?I believe that this current code will result in a lot of
>> cut-and-paste. ?My preference is that this is accepted and that we
>> make this more general when we add this to other OMAP platforms, but
>> it'd be great to capture your suggestions on how to do so before those
>> cut-and-paste patch sets start coming in.
>
> It is true that this might get copied. ?But as I suggested to Andy, it
> is best to wait and see how often this happens before generalizing the
> approach. ?Consolidation is easier when you can see what is actually
> common and what is board specific. ?Otherwise it is easy to
> fall into the over-engineering trap.

Makes sense.  I hope to see this patch accepted for Panda quickly and
we can follow Andy's advice on how to make it more general in the
future as we wee how people use/need it.

>
>
> Nicolas
>

[RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

[Andy Green]

On 03/25/2011 08:13 PM, Somebody in the thread at some point said:

Hi -

> I very much like this approach.  I believed the ability to use the die
> ID to get a unique code was reasonable approach and that is why I
> didn't get an EEPROM put onto the BeagleBoard, though Gerald is
> looking at adding one on a future revision because the lack of one
> wasn't well received.  Minor questions below.

Great.  FWIW I think it'd be a lost opportunity to wire the EEPROM 
direct to the network device.  It's more flexible and powerful to regard 
the EEPROM as general "board identity storage", a way to bind 
information to the physical board.  Then you can stick any kind of 
information that you need to bind to the board in the same 25c device 
and in-kernel code can take care of discovering that data when needed on 
any subsystem that takes an interest.

> The use of the OMAP die id below makes this OMAP specific and the list
> referenced below of the devices to be referenced makes it Panda
> specific.  Is there a way to make the list board specific, but to make
> these functions that will be used across many OMAP platforms reusable?
>   I believe that this current code will result in a lot of
> cut-and-paste.  My preference is that this is accepted and that we
> make this more general when we add this to other OMAP platforms, but
> it'd be great to capture your suggestions on how to do so before those
> cut-and-paste patch sets start coming in.

Sure, I would be happy to put this stuff at OMAP platform layer for 
example if it makes sense to OMAP guys more generally.

> I just want to make sure I understand how this works.  When a new
> network device is added, if the device name matches one of the above
> listed device paths, then the die id based MAC id is applied.  This
> must be done via a device registration notifier as the registration is
> triggered when the device is detected.

That's right.  Arguably it would be better if there was a core API to 
register your board-specific uniqueness / entropy, and the drivers were 
able to use that instead of "random" ethernet address all in network 
layer.   But after wasting two weeks getting pointlessly beaten up on 
lkml largely on the question of how generic this issue is, I would 
rather restart somewhere specific where everyone can see the obvious 
benefit and if it's seen as more useful migrate it.

-Andy

[RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

[Arnd Bergmann]

On Thursday 24 March 2011, Andy Green wrote:
> This patch registers a network device notifier callback to set the mac
> addresses for the onboard network assets of Panda correctly, despite the
> drivers involved have used a random or all-zeros MAC address.
> 
> The technique was suggested by Alan Cox on lkml.
> 
> It works by device path so it corrects the MAC addresses even if the
> drivers are in modules loaded in an order that changes their interface
> name from usual (eg, the onboard module might be "wlan1" if there is a
> USB wireless stick plugged in and its module is inserted first.)
> 
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Signed-off-by: Andy Green <andy.green@linaro.org>

It looks like this is the best solution so far.

Acked-by: Arnd Bergmann <arnd@arndb.de>

[RFC PATCH 0/2] OMAP2+: PANDA: Provide unique-ish MAC addresses for Ethernet and WLAN interfaces

[Arnd Bergmann]

On Thursday 24 March 2011, Andy Green wrote:
> The following series solves a problem Panda suffers from where
> because there is no local MAC address storage on the board, a
> new random MAC address is applied to the onboard Ethernet
> interface each time, and the wl12xx module's wlan0 interface is
> always found with an unworkable 00:00:00:00:00:00 MAC.
> 
> The series adds an omap id-related API to generate a
> 6-byte Ethernet MAC address from "hashing" a little the CPU ID
> registers.  It is understood from TI that these contain data
> that at least in a subset of the 128 bits of the ID are unique per-CPU.
> 
> It then introduces code in the Panda board definition file to
> watch network interface creation and if the device's path is on
> a list, set its MAC address to the CPU ID-generated one, plus
> two bits which differ according to which interface in the list
> is being changed.  (This scheme was suggested by Alan Cox).
> 
> The device paths for the onboard Ethernet smsc95xx, and the
> onboard WLAN wl12xx are listed, so both of these will get
> assigned a consistent, unique-ish locally administered MAC
> address with these patches.
> 
> It's beleived the current scheme for MAC generation from ID
> data captures most of the entropy, but if there is a better scheme
> more closely mapped to what the unique factory areas are advice
> is welcome.
> 
> The patches are against linux-omap which already has a prerequisite
> patch that fixes a problem with device ID capture on OMAP4.

It's been a while since we discussed these patches, but Steven Rostedt
just tripped over the same problem and the patches work for
him, so he says "Tested-by: Steven Rostedt <rostedt@goodmis.org>".

Can we get the patches into linux-3.6 please?

	Arnd

[RFC PATCH 0/2] OMAP2+: PANDA: Provide unique-ish MAC addresses for Ethernet and WLAN interfaces

[Steven Rostedt]

On Thu, 2012-06-28 at 14:18 +0000, Arnd Bergmann wrote:

> It's been a while since we discussed these patches, but Steven Rostedt
> just tripped over the same problem and the patches work for
> him, so he says "Tested-by: Steven Rostedt <rostedt@goodmis.org>".
> 
> Can we get the patches into linux-3.6 please?

Yes please.

Right now I have my ktest.pl setup adding these patches before running
tests. I really dislike having to modify a kernel that I'm testing,
because I'm not really testing that said kernel, but a modified version
of it.

-- Steve

[RFC PATCH 0/2] OMAP2+: PANDA: Provide unique-ish MAC addresses for Ethernet and WLAN interfaces

["Andy Green (林安廸)"]

On 06/28/12 22:45, the mail apparently from Steven Rostedt included:
> On Thu, 2012-06-28 at 14:18 +0000, Arnd Bergmann wrote:
>
>> It's been a while since we discussed these patches, but Steven Rostedt
>> just tripped over the same problem and the patches work for
>> him, so he says "Tested-by: Steven Rostedt <rostedt@goodmis.org>".
>>
>> Can we get the patches into linux-3.6 please?
>
> Yes please.
>
> Right now I have my ktest.pl setup adding these patches before running
> tests. I really dislike having to modify a kernel that I'm testing,
> because I'm not really testing that said kernel, but a modified version
> of it.

Guys I am glad you're finding the patches useful; I've been using them 
in the Linaro TI Lnding Team trees ever since.

I adapted them a bit to live mainly in devices.c, tomorrow I'll send 
this version cleaned up and we can deal with any further changes needed 
hopefully quickly.

-Andy