[PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

[PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

[Andy Green]

The following series adds some code to generate legal, locally administered
MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
net/ethernet taking care of accepting device path / MAC mapping registrations
and running a notifier to enforce the requested MAC when the matching network
device turns up.

On PandaBoard / ES, two devices have no board-level MAC either assigned by
the manufacturer or stored on the board, the last patch in the series adds
these device paths and gets them set when the network device is registered.

Lastly for convenient testing, there's a little patch on omap2plus_defconfig
that will get Ethernet and WLAN up on Pandaboard.

The patches are against today's linux-omap.

Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the
helper in net/ethernet.

---

Andy Green (4):
      OMAP: add cpu id register to MAC address helper
      NET ethernet introduce mac_platform helper
      OMAP4 PANDA register ethernet and wlan for automatic mac allocation
      config test config extending omap2plus with wl12xx etc


 arch/arm/configs/omap2plus_defconfig   |   35 +++----
 arch/arm/mach-omap2/Kconfig            |    1 
 arch/arm/mach-omap2/board-omap4panda.c |   30 ++++++
 arch/arm/mach-omap2/id.c               |   39 ++++++++
 arch/arm/mach-omap2/include/mach/id.h  |    1 
 include/net/mac-platform.h             |   39 ++++++++
 net/Kconfig                            |    5 +
 net/ethernet/Makefile                  |    3 +
 net/ethernet/mac-platform.c            |  151 ++++++++++++++++++++++++++++++++
 9 files changed, 282 insertions(+), 22 deletions(-)
 create mode 100644 include/net/mac-platform.h
 create mode 100644 net/ethernet/mac-platform.c

[PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

[Andy Green]

The following series adds some code to generate legal, locally administered
MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
net/ethernet taking care of accepting device path / MAC mapping registrations
and running a notifier to enforce the requested MAC when the matching network
device turns up.

On PandaBoard / ES, two devices have no board-level MAC either assigned by
the manufacturer or stored on the board, the last patch in the series adds
these device paths and gets them set when the network device is registered.

Lastly for convenient testing, there's a little patch on omap2plus_defconfig
that will get Ethernet and WLAN up on Pandaboard.

The patches are against today's linux-omap.

Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the
helper in net/ethernet.

---

Andy Green (4):
      OMAP: add cpu id register to MAC address helper
      NET ethernet introduce mac_platform helper
      OMAP4 PANDA register ethernet and wlan for automatic mac allocation
      config test config extending omap2plus with wl12xx etc


 arch/arm/configs/omap2plus_defconfig   |   35 +++----
 arch/arm/mach-omap2/Kconfig            |    1 
 arch/arm/mach-omap2/board-omap4panda.c |   30 ++++++
 arch/arm/mach-omap2/id.c               |   39 ++++++++
 arch/arm/mach-omap2/include/mach/id.h  |    1 
 include/net/mac-platform.h             |   39 ++++++++
 net/Kconfig                            |    5 +
 net/ethernet/Makefile                  |    3 +
 net/ethernet/mac-platform.c            |  151 ++++++++++++++++++++++++++++++++
 9 files changed, 282 insertions(+), 22 deletions(-)
 create mode 100644 include/net/mac-platform.h
 create mode 100644 net/ethernet/mac-platform.c

[PATCH 4 1/4] OMAP: add cpu id register to MAC address helper

[Andy Green]

From: Andy Green <andy@warmcat.com>

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

For comparison purposes this produces a MAC address of

  2e:20:3c:ea:46:01

for the ethernet device on my PandaBoard ES.

The MAC address space has space set aside for these kind of "locally
administered" MAC addresses, analogous to IPv4 10.x.x.x range, and this
patch marks the generated MAC addresses as such.

The patch leaves two bits allowing elaborating 4 different MACs from the
generated data.

Signed-off-by: Andy Green <andy.green@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
---
 arch/arm/mach-omap2/id.c              |   39 +++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/include/mach/id.h |    1 +
 2 files changed, 40 insertions(+)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37eb95a..3ab5d4d 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -530,3 +530,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 omap_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..d6c8d63 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 omap_die_id_to_ethernet_mac(u8 *mac, int subtype);
 
 #endif

[PATCH 4 1/4] OMAP: add cpu id register to MAC address helper

[Andy Green]

From: Andy Green <andy@warmcat.com>

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

For comparison purposes this produces a MAC address of

  2e:20:3c:ea:46:01

for the ethernet device on my PandaBoard ES.

The MAC address space has space set aside for these kind of "locally
administered" MAC addresses, analogous to IPv4 10.x.x.x range, and this
patch marks the generated MAC addresses as such.

The patch leaves two bits allowing elaborating 4 different MACs from the
generated data.

Signed-off-by: Andy Green <andy.green@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
---
 arch/arm/mach-omap2/id.c              |   39 +++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/include/mach/id.h |    1 +
 2 files changed, 40 insertions(+)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37eb95a..3ab5d4d 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -530,3 +530,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 omap_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..d6c8d63 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 omap_die_id_to_ethernet_mac(u8 *mac, int subtype);
 
 #endif

[PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Andy Green]

From: Andy Green <andy@warmcat.com>

This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
and the MAC that is needed to be assigned to the device when it appears.

This allows platform code to enforce valid, consistent MAC addresses on to
devices that have not been probed at boot-time, but due to being wired on the
board are always present at the same interface.  It has been tested with USB
and SDIO probed devices.

Other parts of this series provide an OMAP API that computes a valid
locally administered MAC address from CPU ID bits that are unique for each
physical SoC, and register those against devices wired to the board.

This solves a longstanding problem in at least Panda case that there are no
reserved MACs for either onboard Ethernet nor onboard WLAN module, and without
this patch a randomized MAC is assigned to Ethernet and 00:00:00:00:00:00 or
0xdeadbeef is assigned as the WLAN MAC address.  The series provides sane,
constant locally-administered MAC addresses that have a high probability of
differing between boards.

To make use of this safely you also need to make sure that any drivers that
may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
case) are loaded in a deterministic order.

At registration it makes a copy of the incoming data, so the data may be
__initdata or otherwise transitory.  Registration can be called multiple times
so registrations from Device Tree and platform may be mixed.

Since it needs to be called quite early in boot and there is no lifecycle for
what it does, it could not be modular and is not a driver.

Via suggestions from Arnd Bergmann and Tony Lindgren (and Alan Cox for the
network notifier concept).

Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andy Green <andy.green@linaro.org>
---
 include/net/mac-platform.h  |   39 +++++++++++
 net/Kconfig                 |    5 +
 net/ethernet/Makefile       |    3 +
 net/ethernet/mac-platform.c |  151 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 197 insertions(+), 1 deletion(-)
 create mode 100644 include/net/mac-platform.h
 create mode 100644 net/ethernet/mac-platform.c

diff --git a/include/net/mac-platform.h b/include/net/mac-platform.h
new file mode 100644
index 0000000..3a59098
--- /dev/null
+++ b/include/net/mac-platform.h
@@ -0,0 +1,39 @@
+/*
+ * mac-platform.h:  Enforces platform-defined MAC for Async probed devices
+ */
+
+#ifndef __NET_MAC_PLATFORM_H__
+#define __NET_MAC_PLATFORM_H__
+
+#include <linux/if_ether.h>
+
+/**
+ * struct mac_platform - associates asynchronously probed device path with
+ *			 MAC address to be assigned to the device when it
+ *			 is created
+ *
+ * @device_path: device path name of network device
+ * @mac: MAC address to assign to network device matching device path
+ * @list: can be left uninitialized when passing from platform
+ */
+
+struct mac_platform {
+	char *device_path;
+	u8 mac[ETH_ALEN];
+	struct list_head list; /* unused in platform data usage */
+};
+
+#ifdef CONFIG_NET
+/**
+ * mac_platform_register_device_macs - add an array of device path to monitor
+ *                                  and MAC to apply when the network device
+ *                                  at the device path appears
+ * @macs: array of struct mac_platform terminated by entry with
+ *	  NULL device_path
+ */
+int mac_platform_register_device_macs(const struct mac_platform *macs);
+#else
+static inline int mac_platform_register_device_macs(macs) { return 0; }
+#endif /* !CONFIG_NET */
+
+#endif /* __NET_MAC_PLATFORM_H__ */
diff --git a/net/Kconfig b/net/Kconfig
index 245831b..487c9e6 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -335,9 +335,12 @@ source "net/caif/Kconfig"
 source "net/ceph/Kconfig"
 source "net/nfc/Kconfig"
 
-
 endif   # if NET
 
+# used by board / dt platform to enforce MACs for Async-probed devices
+config MAC_PLATFORM
+	bool
+
 # Used by archs to tell that they support BPF_JIT
 config HAVE_BPF_JIT
 	bool
diff --git a/net/ethernet/Makefile b/net/ethernet/Makefile
index 7cef1d8..475db2b 100644
--- a/net/ethernet/Makefile
+++ b/net/ethernet/Makefile
@@ -5,3 +5,6 @@
 obj-y					+= eth.o
 obj-$(subst m,y,$(CONFIG_IPX))		+= pe2.o
 obj-$(subst m,y,$(CONFIG_ATALK))	+= pe2.o
+ifneq ($(CONFIG_NET),)
+obj-$(CONFIG_MAC_PLATFORM)		+= mac-platform.o
+endif
diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
new file mode 100644
index 0000000..88e50ce
--- /dev/null
+++ b/net/ethernet/mac-platform.c
@@ -0,0 +1,151 @@
+/*
+ * Helper to allow platform code to enforce association of a locally-
+ * administered MAC address automatically on asynchronously probed devices,
+ * such as SDIO and USB based devices.
+ *
+ * Because the "device path" is used for matching, this is only useful for
+ * network assets physcally wired on the board, and also requires any
+ * different drivers that can compete for bus ordinals (eg mUSB vs ehci) to
+ * have fixed initialization ordering, eg, by having ehci in monolithic
+ * kernel
+ *
+ * Neither a driver nor a module as needs to be callable from machine file
+ * before the network devices are registered.
+ *
+ * (c) 2012 Andy Green <andy.green@linaro.org>
+ */
+
+#include <linux/netdevice.h>
+#include <net/mac-platform.h>
+
+static LIST_HEAD(mac_platform_list);
+static DEFINE_MUTEX(mac_platform_mutex);
+
+static struct mac_platform *__mac_platform_check(struct device *dev)
+{
+	const char *path;
+	const char *p;
+	const char *try;
+	int len;
+	struct device *devn;
+	struct mac_platform *tmp;
+	struct list_head *pos;
+
+	list_for_each(pos, &mac_platform_list) {
+
+		tmp = list_entry(pos, struct mac_platform, list);
+
+		try = tmp->device_path;
+
+		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 tmp;
+
+			if (devn != NULL && (p - try) < 2)
+				devn = NULL;
+
+			p--;
+			if (devn != NULL && *p != '/')
+				devn = NULL;
+		}
+	}
+
+	return NULL;
+}
+
+static int mac_platform_netdev_event(struct notifier_block *this,
+						unsigned long event, void *ptr)
+{
+	struct net_device *dev = ptr;
+	struct sockaddr sa;
+	struct mac_platform *match;
+
+	if (event != NETDEV_REGISTER)
+		return NOTIFY_DONE;
+
+	mutex_lock(&mac_platform_mutex);
+
+	match = __mac_platform_check(dev->dev.parent);
+	if (match == NULL)
+		goto bail;
+
+	sa.sa_family = dev->type;
+	memcpy(sa.sa_data, match->mac, sizeof match->mac);
+	dev->netdev_ops->ndo_set_mac_address(dev, &sa);
+
+bail:
+	mutex_unlock(&mac_platform_mutex);
+
+	return NOTIFY_DONE;
+}
+
+int mac_platform_register_device_macs(const struct mac_platform *macs)
+{
+	struct mac_platform *next;
+	int ret = 0;
+
+	mutex_lock(&mac_platform_mutex);
+
+	while (macs->device_path) {
+
+		next = kmalloc(sizeof(struct mac_platform), GFP_KERNEL);
+		if (!next) {
+			ret = -ENOMEM;
+			goto bail;
+		}
+
+		next->device_path = kmalloc(strlen(macs->device_path) + 1,
+								   GFP_KERNEL);
+		if (!next->device_path) {
+			ret = -ENOMEM;
+			goto bail;
+		}
+
+		strcpy(next->device_path, macs->device_path);
+		memcpy(next->mac, macs->mac, sizeof macs->mac);
+		list_add(&next->list, &mac_platform_list);
+
+		macs++;
+	}
+
+bail:
+	mutex_unlock(&mac_platform_mutex);
+
+	return ret;
+}
+
+static struct notifier_block mac_platform_netdev_notifier = {
+	.notifier_call = mac_platform_netdev_event,
+	.priority = 1,
+};
+
+static int __init mac_platform_init(void)
+{
+	int ret = register_netdevice_notifier(&mac_platform_netdev_notifier);
+	if (ret)
+		pr_err("mac_platform_init: Notifier registration failed\n");
+
+	return ret;
+}
+
+core_initcall(mac_platform_init);

[PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Andy Green]

From: Andy Green <andy@warmcat.com>

This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
and the MAC that is needed to be assigned to the device when it appears.

This allows platform code to enforce valid, consistent MAC addresses on to
devices that have not been probed at boot-time, but due to being wired on the
board are always present at the same interface.  It has been tested with USB
and SDIO probed devices.

Other parts of this series provide an OMAP API that computes a valid
locally administered MAC address from CPU ID bits that are unique for each
physical SoC, and register those against devices wired to the board.

This solves a longstanding problem in at least Panda case that there are no
reserved MACs for either onboard Ethernet nor onboard WLAN module, and without
this patch a randomized MAC is assigned to Ethernet and 00:00:00:00:00:00 or
0xdeadbeef is assigned as the WLAN MAC address.  The series provides sane,
constant locally-administered MAC addresses that have a high probability of
differing between boards.

To make use of this safely you also need to make sure that any drivers that
may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
case) are loaded in a deterministic order.

At registration it makes a copy of the incoming data, so the data may be
__initdata or otherwise transitory.  Registration can be called multiple times
so registrations from Device Tree and platform may be mixed.

Since it needs to be called quite early in boot and there is no lifecycle for
what it does, it could not be modular and is not a driver.

Via suggestions from Arnd Bergmann and Tony Lindgren (and Alan Cox for the
network notifier concept).

Cc: netdev at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Andy Green <andy.green@linaro.org>
---
 include/net/mac-platform.h  |   39 +++++++++++
 net/Kconfig                 |    5 +
 net/ethernet/Makefile       |    3 +
 net/ethernet/mac-platform.c |  151 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 197 insertions(+), 1 deletion(-)
 create mode 100644 include/net/mac-platform.h
 create mode 100644 net/ethernet/mac-platform.c

diff --git a/include/net/mac-platform.h b/include/net/mac-platform.h
new file mode 100644
index 0000000..3a59098
--- /dev/null
+++ b/include/net/mac-platform.h
@@ -0,0 +1,39 @@
+/*
+ * mac-platform.h:  Enforces platform-defined MAC for Async probed devices
+ */
+
+#ifndef __NET_MAC_PLATFORM_H__
+#define __NET_MAC_PLATFORM_H__
+
+#include <linux/if_ether.h>
+
+/**
+ * struct mac_platform - associates asynchronously probed device path with
+ *			 MAC address to be assigned to the device when it
+ *			 is created
+ *
+ * @device_path: device path name of network device
+ * @mac: MAC address to assign to network device matching device path
+ * @list: can be left uninitialized when passing from platform
+ */
+
+struct mac_platform {
+	char *device_path;
+	u8 mac[ETH_ALEN];
+	struct list_head list; /* unused in platform data usage */
+};
+
+#ifdef CONFIG_NET
+/**
+ * mac_platform_register_device_macs - add an array of device path to monitor
+ *                                  and MAC to apply when the network device
+ *                                  at the device path appears
+ * @macs: array of struct mac_platform terminated by entry with
+ *	  NULL device_path
+ */
+int mac_platform_register_device_macs(const struct mac_platform *macs);
+#else
+static inline int mac_platform_register_device_macs(macs) { return 0; }
+#endif /* !CONFIG_NET */
+
+#endif /* __NET_MAC_PLATFORM_H__ */
diff --git a/net/Kconfig b/net/Kconfig
index 245831b..487c9e6 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -335,9 +335,12 @@ source "net/caif/Kconfig"
 source "net/ceph/Kconfig"
 source "net/nfc/Kconfig"
 
-
 endif   # if NET
 
+# used by board / dt platform to enforce MACs for Async-probed devices
+config MAC_PLATFORM
+	bool
+
 # Used by archs to tell that they support BPF_JIT
 config HAVE_BPF_JIT
 	bool
diff --git a/net/ethernet/Makefile b/net/ethernet/Makefile
index 7cef1d8..475db2b 100644
--- a/net/ethernet/Makefile
+++ b/net/ethernet/Makefile
@@ -5,3 +5,6 @@
 obj-y					+= eth.o
 obj-$(subst m,y,$(CONFIG_IPX))		+= pe2.o
 obj-$(subst m,y,$(CONFIG_ATALK))	+= pe2.o
+ifneq ($(CONFIG_NET),)
+obj-$(CONFIG_MAC_PLATFORM)		+= mac-platform.o
+endif
diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
new file mode 100644
index 0000000..88e50ce
--- /dev/null
+++ b/net/ethernet/mac-platform.c
@@ -0,0 +1,151 @@
+/*
+ * Helper to allow platform code to enforce association of a locally-
+ * administered MAC address automatically on asynchronously probed devices,
+ * such as SDIO and USB based devices.
+ *
+ * Because the "device path" is used for matching, this is only useful for
+ * network assets physcally wired on the board, and also requires any
+ * different drivers that can compete for bus ordinals (eg mUSB vs ehci) to
+ * have fixed initialization ordering, eg, by having ehci in monolithic
+ * kernel
+ *
+ * Neither a driver nor a module as needs to be callable from machine file
+ * before the network devices are registered.
+ *
+ * (c) 2012 Andy Green <andy.green@linaro.org>
+ */
+
+#include <linux/netdevice.h>
+#include <net/mac-platform.h>
+
+static LIST_HEAD(mac_platform_list);
+static DEFINE_MUTEX(mac_platform_mutex);
+
+static struct mac_platform *__mac_platform_check(struct device *dev)
+{
+	const char *path;
+	const char *p;
+	const char *try;
+	int len;
+	struct device *devn;
+	struct mac_platform *tmp;
+	struct list_head *pos;
+
+	list_for_each(pos, &mac_platform_list) {
+
+		tmp = list_entry(pos, struct mac_platform, list);
+
+		try = tmp->device_path;
+
+		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 tmp;
+
+			if (devn != NULL && (p - try) < 2)
+				devn = NULL;
+
+			p--;
+			if (devn != NULL && *p != '/')
+				devn = NULL;
+		}
+	}
+
+	return NULL;
+}
+
+static int mac_platform_netdev_event(struct notifier_block *this,
+						unsigned long event, void *ptr)
+{
+	struct net_device *dev = ptr;
+	struct sockaddr sa;
+	struct mac_platform *match;
+
+	if (event != NETDEV_REGISTER)
+		return NOTIFY_DONE;
+
+	mutex_lock(&mac_platform_mutex);
+
+	match = __mac_platform_check(dev->dev.parent);
+	if (match == NULL)
+		goto bail;
+
+	sa.sa_family = dev->type;
+	memcpy(sa.sa_data, match->mac, sizeof match->mac);
+	dev->netdev_ops->ndo_set_mac_address(dev, &sa);
+
+bail:
+	mutex_unlock(&mac_platform_mutex);
+
+	return NOTIFY_DONE;
+}
+
+int mac_platform_register_device_macs(const struct mac_platform *macs)
+{
+	struct mac_platform *next;
+	int ret = 0;
+
+	mutex_lock(&mac_platform_mutex);
+
+	while (macs->device_path) {
+
+		next = kmalloc(sizeof(struct mac_platform), GFP_KERNEL);
+		if (!next) {
+			ret = -ENOMEM;
+			goto bail;
+		}
+
+		next->device_path = kmalloc(strlen(macs->device_path) + 1,
+								   GFP_KERNEL);
+		if (!next->device_path) {
+			ret = -ENOMEM;
+			goto bail;
+		}
+
+		strcpy(next->device_path, macs->device_path);
+		memcpy(next->mac, macs->mac, sizeof macs->mac);
+		list_add(&next->list, &mac_platform_list);
+
+		macs++;
+	}
+
+bail:
+	mutex_unlock(&mac_platform_mutex);
+
+	return ret;
+}
+
+static struct notifier_block mac_platform_netdev_notifier = {
+	.notifier_call = mac_platform_netdev_event,
+	.priority = 1,
+};
+
+static int __init mac_platform_init(void)
+{
+	int ret = register_netdevice_notifier(&mac_platform_netdev_notifier);
+	if (ret)
+		pr_err("mac_platform_init: Notifier registration failed\n");
+
+	return ret;
+}
+
+core_initcall(mac_platform_init);

[PATCH 4 3/4] OMAP4 PANDA register ethernet and wlan for automatic mac allocation

[Andy Green]

From: Andy Green <andy@warmcat.com>

This provides the board-specific device paths needed to get
the panda boardfile working with the mac-platform api.

On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding randomized MAC per-boot and consequent DHCP problems,
or in the case of wlan0 a MAC set by a firmware file in the rootfs
which unless customized yields a MAC of 00:00:00:00:00:00.  No
official MAC is reserved for either network device even if you do
take the approach to customize the firmware file.

This gets sane, consistent MAC addresses on both devices which
should stand a good probability of differing between PandaBoards.

Signed-off-by: Andy Green <andy.green@linaro.org>
---
 arch/arm/mach-omap2/Kconfig            |    1 +
 arch/arm/mach-omap2/board-omap4panda.c |   30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 83fb31c..06fadf4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -358,6 +358,7 @@ config MACH_OMAP4_PANDA
 	select OMAP_PACKAGE_CBL
 	select OMAP_PACKAGE_CBS
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select MAC_PLATFORM
 
 config MACH_PCM049
 	bool "OMAP4 based phyCORE OMAP4"
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..b028141 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -32,7 +32,10 @@
 #include <linux/wl12xx.h>
 #include <linux/platform_data/omap-abe-twl6040.h>
 
+#include <net/mac-platform.h>
+
 #include <mach/hardware.h>
+#include <mach/id.h>
 #include <asm/hardware/gic.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -486,16 +489,43 @@ static void omap4_panda_init_rev(void)
 	}
 }
 
+/*
+ * These device paths represent onboard network devices which have
+ * no MAC address set at boot, and need synthetic ones assigning
+ */
+static __initdata struct mac_platform panda_mac_platform[] = {
+
+	{ /* smsc USB <-> Ethernet bridge */
+		.device_path = "usb1/1-1/1-1.1/1-1.1:1.0",
+	},
+	{ /* wlan0 module */
+		.device_path = "wl12xx",
+	},
+	{ /* terminator */
+	}
+};
+
 static void __init omap4_panda_init(void)
 {
 	int package = OMAP_PACKAGE_CBS;
 	int ret;
+	int n;
 
 	if (omap_rev() == OMAP4430_REV_ES1_0)
 		package = OMAP_PACKAGE_CBL;
 	omap4_mux_init(board_mux, NULL, package);
 
 	omap_panda_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+	/*
+	 * provide MAC addresses computed from device ID for network
+	 * devices that have no MAC address otherwise on Panda
+	 */
+	for (n = 0; n < ARRAY_SIZE(panda_mac_platform) - 1; n++)
+		omap_die_id_to_ethernet_mac(panda_mac_platform[n].mac, n);
+	if (mac_platform_register_device_macs(panda_mac_platform))
+		pr_err("Unable to register mac_platform devices\n");
+
 	ret = wl12xx_set_platform_data(&omap_panda_wlan_data);
 	if (ret)
 		pr_err("error setting wl12xx data: %d\n", ret);

[PATCH 4 3/4] OMAP4 PANDA register ethernet and wlan for automatic mac allocation

[Andy Green]

From: Andy Green <andy@warmcat.com>

This provides the board-specific device paths needed to get
the panda boardfile working with the mac-platform api.

On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding randomized MAC per-boot and consequent DHCP problems,
or in the case of wlan0 a MAC set by a firmware file in the rootfs
which unless customized yields a MAC of 00:00:00:00:00:00.  No
official MAC is reserved for either network device even if you do
take the approach to customize the firmware file.

This gets sane, consistent MAC addresses on both devices which
should stand a good probability of differing between PandaBoards.

Signed-off-by: Andy Green <andy.green@linaro.org>
---
 arch/arm/mach-omap2/Kconfig            |    1 +
 arch/arm/mach-omap2/board-omap4panda.c |   30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 83fb31c..06fadf4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -358,6 +358,7 @@ config MACH_OMAP4_PANDA
 	select OMAP_PACKAGE_CBL
 	select OMAP_PACKAGE_CBS
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select MAC_PLATFORM
 
 config MACH_PCM049
 	bool "OMAP4 based phyCORE OMAP4"
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..b028141 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -32,7 +32,10 @@
 #include <linux/wl12xx.h>
 #include <linux/platform_data/omap-abe-twl6040.h>
 
+#include <net/mac-platform.h>
+
 #include <mach/hardware.h>
+#include <mach/id.h>
 #include <asm/hardware/gic.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
@@ -486,16 +489,43 @@ static void omap4_panda_init_rev(void)
 	}
 }
 
+/*
+ * These device paths represent onboard network devices which have
+ * no MAC address set at boot, and need synthetic ones assigning
+ */
+static __initdata struct mac_platform panda_mac_platform[] = {
+
+	{ /* smsc USB <-> Ethernet bridge */
+		.device_path = "usb1/1-1/1-1.1/1-1.1:1.0",
+	},
+	{ /* wlan0 module */
+		.device_path = "wl12xx",
+	},
+	{ /* terminator */
+	}
+};
+
 static void __init omap4_panda_init(void)
 {
 	int package = OMAP_PACKAGE_CBS;
 	int ret;
+	int n;
 
 	if (omap_rev() == OMAP4430_REV_ES1_0)
 		package = OMAP_PACKAGE_CBL;
 	omap4_mux_init(board_mux, NULL, package);
 
 	omap_panda_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+	/*
+	 * provide MAC addresses computed from device ID for network
+	 * devices that have no MAC address otherwise on Panda
+	 */
+	for (n = 0; n < ARRAY_SIZE(panda_mac_platform) - 1; n++)
+		omap_die_id_to_ethernet_mac(panda_mac_platform[n].mac, n);
+	if (mac_platform_register_device_macs(panda_mac_platform))
+		pr_err("Unable to register mac_platform devices\n");
+
 	ret = wl12xx_set_platform_data(&omap_panda_wlan_data);
 	if (ret)
 		pr_err("error setting wl12xx data: %d\n", ret);

[PATCH 4 4/4] config test config extending omap2plus with wl12xx etc

[Andy Green]

From: Andy Green <andy@warmcat.com>

This is just provided for testing convenience, it has enough config
options to get Ethernet and WL12xx driver on PandaBoard / ES up

You should be able to reproduce something like this, with different
MAC addresses.

# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 2e:20:3c:ea:46:01
          inet addr:10.42.0.98  Bcast:10.42.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1647 (1.6 KB)  TX bytes:5534 (5.5 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:100 (100.0 B)  TX bytes:100 (100.0 B)

wlan0     Link encap:Ethernet  HWaddr 2e:60:3c:ea:46:01
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Signed-off-by: Andy Green <andy.green@linaro.org>
---
 arch/arm/configs/omap2plus_defconfig |   35 ++++++++++++++--------------------
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index f3087cb..7dcd384 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -2,13 +2,13 @@ CONFIG_EXPERIMENTAL=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
 CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=16
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
-# CONFIG_SYSCTL_SYSCALL is not set
-CONFIG_KALLSYMS_EXTRA_PASS=y
 CONFIG_SLAB=y
 CONFIG_PROFILING=y
 CONFIG_OPROFILE=y
@@ -20,13 +20,12 @@ CONFIG_MODULE_FORCE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 # CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARCH_OMAP=y
 CONFIG_OMAP_RESET_CLOCKS=y
 CONFIG_OMAP_MUX_DEBUG=y
 CONFIG_ARM_THUMBEE=y
 CONFIG_ARM_ERRATA_411920=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=2
 CONFIG_LEDS=y
@@ -60,6 +59,7 @@ CONFIG_BT_HCIUART_LL=y
 CONFIG_BT_HCIBCM203X=m
 CONFIG_BT_HCIBPA10X=m
 CONFIG_CFG80211=m
+CONFIG_LIB80211=m
 CONFIG_MAC80211=m
 CONFIG_MAC80211_RC_PID=y
 CONFIG_MAC80211_RC_DEFAULT_PID=y
@@ -87,22 +87,20 @@ CONFIG_SCSI_MULTI_LUN=y
 CONFIG_SCSI_SCAN_ASYNC=y
 CONFIG_MD=y
 CONFIG_NETDEVICES=y
-CONFIG_SMSC_PHY=y
-CONFIG_NET_ETHERNET=y
-CONFIG_SMC91X=y
-CONFIG_SMSC911X=y
 CONFIG_KS8851=y
 CONFIG_KS8851_MLL=y
-CONFIG_LIBERTAS=m
-CONFIG_LIBERTAS_USB=m
-CONFIG_LIBERTAS_SDIO=m
-CONFIG_LIBERTAS_DEBUG=y
+CONFIG_SMC91X=y
+CONFIG_SMSC911X=y
+CONFIG_SMSC_PHY=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC95XX=y
 CONFIG_USB_ALI_M5632=y
 CONFIG_USB_AN2720=y
 CONFIG_USB_EPSON2888=y
 CONFIG_USB_KC2190=y
+CONFIG_WL_TI=y
+CONFIG_WL12XX=m
+CONFIG_WLCORE_SDIO=m
 CONFIG_INPUT_JOYDEV=y
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
@@ -131,14 +129,14 @@ CONFIG_POWER_SUPPLY=y
 CONFIG_WATCHDOG=y
 CONFIG_OMAP_WATCHDOG=y
 CONFIG_TWL4030_WATCHDOG=y
-CONFIG_REGULATOR_TWL4030=y
+CONFIG_MFD_WL1273_CORE=y
 CONFIG_REGULATOR_TPS65023=y
 CONFIG_REGULATOR_TPS6507X=y
+CONFIG_REGULATOR_TWL4030=y
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_TILEBLITTING=y
-CONFIG_FB_OMAP_LCD_VGA=y
 CONFIG_OMAP2_DSS=m
 CONFIG_OMAP2_DSS_RFBI=y
 CONFIG_OMAP2_DSS_SDI=y
@@ -153,7 +151,6 @@ CONFIG_PANEL_ACX565AKM=m
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=y
-CONFIG_DISPLAY_SUPPORT=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_FONTS=y
@@ -173,7 +170,6 @@ CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 CONFIG_USB=y
 CONFIG_USB_DEBUG=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
-CONFIG_USB_DEVICEFS=y
 CONFIG_USB_SUSPEND=y
 CONFIG_USB_MON=y
 CONFIG_USB_EHCI_HCD=y
@@ -212,23 +208,20 @@ CONFIG_JFFS2_RUBIN=y
 CONFIG_UBIFS_FS=y
 CONFIG_CRAMFS=y
 CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
 CONFIG_NFS_V3_ACL=y
 CONFIG_NFS_V4=y
 CONFIG_ROOT_NFS=y
-CONFIG_PARTITION_ADVANCED=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
 CONFIG_SCHEDSTATS=y
 CONFIG_TIMER_STATS=y
 CONFIG_PROVE_LOCKING=y
-CONFIG_DEBUG_SPINLOCK_SLEEP=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
 CONFIG_SECURITY=y
 CONFIG_CRYPTO_MICHAEL_MIC=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set

[PATCH 4 4/4] config test config extending omap2plus with wl12xx etc

[Andy Green]

From: Andy Green <andy@warmcat.com>

This is just provided for testing convenience, it has enough config
options to get Ethernet and WL12xx driver on PandaBoard / ES up

You should be able to reproduce something like this, with different
MAC addresses.

# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 2e:20:3c:ea:46:01
          inet addr:10.42.0.98  Bcast:10.42.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:13 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1647 (1.6 KB)  TX bytes:5534 (5.5 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:100 (100.0 B)  TX bytes:100 (100.0 B)

wlan0     Link encap:Ethernet  HWaddr 2e:60:3c:ea:46:01
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Signed-off-by: Andy Green <andy.green@linaro.org>
---
 arch/arm/configs/omap2plus_defconfig |   35 ++++++++++++++--------------------
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index f3087cb..7dcd384 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -2,13 +2,13 @@ CONFIG_EXPERIMENTAL=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
 CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=16
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
-# CONFIG_SYSCTL_SYSCALL is not set
-CONFIG_KALLSYMS_EXTRA_PASS=y
 CONFIG_SLAB=y
 CONFIG_PROFILING=y
 CONFIG_OPROFILE=y
@@ -20,13 +20,12 @@ CONFIG_MODULE_FORCE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 # CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARCH_OMAP=y
 CONFIG_OMAP_RESET_CLOCKS=y
 CONFIG_OMAP_MUX_DEBUG=y
 CONFIG_ARM_THUMBEE=y
 CONFIG_ARM_ERRATA_411920=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=2
 CONFIG_LEDS=y
@@ -60,6 +59,7 @@ CONFIG_BT_HCIUART_LL=y
 CONFIG_BT_HCIBCM203X=m
 CONFIG_BT_HCIBPA10X=m
 CONFIG_CFG80211=m
+CONFIG_LIB80211=m
 CONFIG_MAC80211=m
 CONFIG_MAC80211_RC_PID=y
 CONFIG_MAC80211_RC_DEFAULT_PID=y
@@ -87,22 +87,20 @@ CONFIG_SCSI_MULTI_LUN=y
 CONFIG_SCSI_SCAN_ASYNC=y
 CONFIG_MD=y
 CONFIG_NETDEVICES=y
-CONFIG_SMSC_PHY=y
-CONFIG_NET_ETHERNET=y
-CONFIG_SMC91X=y
-CONFIG_SMSC911X=y
 CONFIG_KS8851=y
 CONFIG_KS8851_MLL=y
-CONFIG_LIBERTAS=m
-CONFIG_LIBERTAS_USB=m
-CONFIG_LIBERTAS_SDIO=m
-CONFIG_LIBERTAS_DEBUG=y
+CONFIG_SMC91X=y
+CONFIG_SMSC911X=y
+CONFIG_SMSC_PHY=y
 CONFIG_USB_USBNET=y
 CONFIG_USB_NET_SMSC95XX=y
 CONFIG_USB_ALI_M5632=y
 CONFIG_USB_AN2720=y
 CONFIG_USB_EPSON2888=y
 CONFIG_USB_KC2190=y
+CONFIG_WL_TI=y
+CONFIG_WL12XX=m
+CONFIG_WLCORE_SDIO=m
 CONFIG_INPUT_JOYDEV=y
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
@@ -131,14 +129,14 @@ CONFIG_POWER_SUPPLY=y
 CONFIG_WATCHDOG=y
 CONFIG_OMAP_WATCHDOG=y
 CONFIG_TWL4030_WATCHDOG=y
-CONFIG_REGULATOR_TWL4030=y
+CONFIG_MFD_WL1273_CORE=y
 CONFIG_REGULATOR_TPS65023=y
 CONFIG_REGULATOR_TPS6507X=y
+CONFIG_REGULATOR_TWL4030=y
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_TILEBLITTING=y
-CONFIG_FB_OMAP_LCD_VGA=y
 CONFIG_OMAP2_DSS=m
 CONFIG_OMAP2_DSS_RFBI=y
 CONFIG_OMAP2_DSS_SDI=y
@@ -153,7 +151,6 @@ CONFIG_PANEL_ACX565AKM=m
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=y
-CONFIG_DISPLAY_SUPPORT=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_FONTS=y
@@ -173,7 +170,6 @@ CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 CONFIG_USB=y
 CONFIG_USB_DEBUG=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
-CONFIG_USB_DEVICEFS=y
 CONFIG_USB_SUSPEND=y
 CONFIG_USB_MON=y
 CONFIG_USB_EHCI_HCD=y
@@ -212,23 +208,20 @@ CONFIG_JFFS2_RUBIN=y
 CONFIG_UBIFS_FS=y
 CONFIG_CRAMFS=y
 CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
 CONFIG_NFS_V3_ACL=y
 CONFIG_NFS_V4=y
 CONFIG_ROOT_NFS=y
-CONFIG_PARTITION_ADVANCED=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
 CONFIG_SCHEDSTATS=y
 CONFIG_TIMER_STATS=y
 CONFIG_PROVE_LOCKING=y
-CONFIG_DEBUG_SPINLOCK_SLEEP=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_DEBUG_LL=y
+CONFIG_EARLY_PRINTK=y
 CONFIG_SECURITY=y
 CONFIG_CRYPTO_MICHAEL_MIC=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set

Re: [PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Joe Perches]

On Thu, 2012-07-05 at 10:44 +0800, Andy Green wrote:
> From: Andy Green <andy@warmcat.com>
> 
> This introduces a small helper in net/ethernet, which registers a network
> notifier at core_initcall time, and accepts registrations mapping expected
> asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
> and the MAC that is needed to be assigned to the device when it appears.

The mac prefix is poor.  I think eth_mac is better.

[]

> diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
[]
> +static int mac_platform_netdev_event(struct notifier_block *this,
> +						unsigned long event, void *ptr)

alignment to parenthesis please.

[]

> +int mac_platform_register_device_macs(const struct mac_platform *macs)
> +{
[]
> +		next = kmalloc(sizeof(struct mac_platform), GFP_KERNEL);
> +		if (!next) {
> +			ret = -ENOMEM;
> +			goto bail;
> +		}
> +
> +		next->device_path = kmalloc(strlen(macs->device_path) + 1,
> +								   GFP_KERNEL);
> +		if (!next->device_path) {
> +			ret = -ENOMEM;
> +			goto bail;
> +		}
> +
> +		strcpy(next->device_path, macs->device_path);
> +		memcpy(next->mac, macs->mac, sizeof macs->mac);

kmemdup and kstrdup()

> +		list_add(&next->list, &mac_platform_list);
> +
> +		macs++;
> +	}
> +
> +bail:
> +	mutex_unlock(&mac_platform_mutex);
> +
> +	return ret;
> +}

leaking memory on failures.

[PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Joe Perches]

On Thu, 2012-07-05 at 10:44 +0800, Andy Green wrote:
> From: Andy Green <andy@warmcat.com>
> 
> This introduces a small helper in net/ethernet, which registers a network
> notifier at core_initcall time, and accepts registrations mapping expected
> asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
> and the MAC that is needed to be assigned to the device when it appears.

The mac prefix is poor.  I think eth_mac is better.

[]

> diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
[]
> +static int mac_platform_netdev_event(struct notifier_block *this,
> +						unsigned long event, void *ptr)

alignment to parenthesis please.

[]

> +int mac_platform_register_device_macs(const struct mac_platform *macs)
> +{
[]
> +		next = kmalloc(sizeof(struct mac_platform), GFP_KERNEL);
> +		if (!next) {
> +			ret = -ENOMEM;
> +			goto bail;
> +		}
> +
> +		next->device_path = kmalloc(strlen(macs->device_path) + 1,
> +								   GFP_KERNEL);
> +		if (!next->device_path) {
> +			ret = -ENOMEM;
> +			goto bail;
> +		}
> +
> +		strcpy(next->device_path, macs->device_path);
> +		memcpy(next->mac, macs->mac, sizeof macs->mac);

kmemdup and kstrdup()

> +		list_add(&next->list, &mac_platform_list);
> +
> +		macs++;
> +	}
> +
> +bail:
> +	mutex_unlock(&mac_platform_mutex);
> +
> +	return ret;
> +}

leaking memory on failures.

Re: [PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Andy Green]

On 05/07/12 11:12, the mail apparently from Joe Perches included:

Thanks for the comments.

>> This introduces a small helper in net/ethernet, which registers a network
>> notifier at core_initcall time, and accepts registrations mapping expected
>> asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
>> and the MAC that is needed to be assigned to the device when it appears.
>
> The mac prefix is poor.  I think eth_mac is better.

OK.

>> diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
> []
>> +static int mac_platform_netdev_event(struct notifier_block *this,
>> +						unsigned long event, void *ptr)
>
> alignment to parenthesis please.

OK.  Although different places in the kernel seem to have different 
expectations about that.

>> +int mac_platform_register_device_macs(const struct mac_platform *macs)
>> +{
> []
>> +		next = kmalloc(sizeof(struct mac_platform), GFP_KERNEL);
>> +		if (!next) {
>> +			ret = -ENOMEM;
>> +			goto bail;
>> +		}
>> +
>> +		next->device_path = kmalloc(strlen(macs->device_path) + 1,
>> +								   GFP_KERNEL);
>> +		if (!next->device_path) {
>> +			ret = -ENOMEM;
>> +			goto bail;
>> +		}
>> +
>> +		strcpy(next->device_path, macs->device_path);
>> +		memcpy(next->mac, macs->mac, sizeof macs->mac);
>
> kmemdup and kstrdup()

OK

>> +		list_add(&next->list, &mac_platform_list);
>> +
>> +		macs++;
>> +	}
>> +
>> +bail:
>> +	mutex_unlock(&mac_platform_mutex);
>> +
>> +	return ret;
>> +}
>
> leaking memory on failures.

Right... I'll fix these and wait for more comments.

Thanks again for the review.

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

[PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Andy Green]

On 05/07/12 11:12, the mail apparently from Joe Perches included:

Thanks for the comments.

>> This introduces a small helper in net/ethernet, which registers a network
>> notifier at core_initcall time, and accepts registrations mapping expected
>> asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
>> and the MAC that is needed to be assigned to the device when it appears.
>
> The mac prefix is poor.  I think eth_mac is better.

OK.

>> diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
> []
>> +static int mac_platform_netdev_event(struct notifier_block *this,
>> +						unsigned long event, void *ptr)
>
> alignment to parenthesis please.

OK.  Although different places in the kernel seem to have different 
expectations about that.

>> +int mac_platform_register_device_macs(const struct mac_platform *macs)
>> +{
> []
>> +		next = kmalloc(sizeof(struct mac_platform), GFP_KERNEL);
>> +		if (!next) {
>> +			ret = -ENOMEM;
>> +			goto bail;
>> +		}
>> +
>> +		next->device_path = kmalloc(strlen(macs->device_path) + 1,
>> +								   GFP_KERNEL);
>> +		if (!next->device_path) {
>> +			ret = -ENOMEM;
>> +			goto bail;
>> +		}
>> +
>> +		strcpy(next->device_path, macs->device_path);
>> +		memcpy(next->mac, macs->mac, sizeof macs->mac);
>
> kmemdup and kstrdup()

OK

>> +		list_add(&next->list, &mac_platform_list);
>> +
>> +		macs++;
>> +	}
>> +
>> +bail:
>> +	mutex_unlock(&mac_platform_mutex);
>> +
>> +	return ret;
>> +}
>
> leaking memory on failures.

Right... I'll fix these and wait for more comments.

Thanks again for the review.

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org ? Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

Re: [PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Joe Perches]

On Thu, 2012-07-05 at 11:20 +0800, Andy Green wrote:
> On 05/07/12 11:12, the mail apparently from Joe Perches included:
[]
> >> diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
> > []
> >> +static int mac_platform_netdev_event(struct notifier_block *this,
> >> +						unsigned long event, void *ptr)
> >
> > alignment to parenthesis please.
> 
> OK.  Although different places in the kernel seem to have different 
> expectations about that.

net and drivers/net is pretty consistent.
Most of the exceptions are old code.
Some of those exceptions are being slowly updated too.

cheers, Joe

[PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Joe Perches]

On Thu, 2012-07-05 at 11:20 +0800, Andy Green wrote:
> On 05/07/12 11:12, the mail apparently from Joe Perches included:
[]
> >> diff --git a/net/ethernet/mac-platform.c b/net/ethernet/mac-platform.c
> > []
> >> +static int mac_platform_netdev_event(struct notifier_block *this,
> >> +						unsigned long event, void *ptr)
> >
> > alignment to parenthesis please.
> 
> OK.  Although different places in the kernel seem to have different 
> expectations about that.

net and drivers/net is pretty consistent.
Most of the exceptions are old code.
Some of those exceptions are being slowly updated too.

cheers, Joe

Re: [PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Ben Hutchings]

On Thu, 2012-07-05 at 10:44 +0800, Andy Green wrote:
[...]
> To make use of this safely you also need to make sure that any drivers that
> may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
> case) are loaded in a deterministic order.
[...]

This seems very restrictive... would it be practical to also allow a
driver name as a path component?

[...]
> --- /dev/null
> +++ b/include/net/mac-platform.h
> @@ -0,0 +1,39 @@
> +/*
> + * mac-platform.h:  Enforces platform-defined MAC for Async probed devices
> + */
> +
> +#ifndef __NET_MAC_PLATFORM_H__
> +#define __NET_MAC_PLATFORM_H__
> +
> +#include <linux/if_ether.h>
> +
> +/**
> + * struct mac_platform - associates asynchronously probed device path with
> + *			 MAC address to be assigned to the device when it
> + *			 is created

A kernel-doc summary is strictly limited to one line.  The longer
explanation can go in a paragraph under the field descriptions.

> + * @device_path: device path name of network device
> + * @mac: MAC address to assign to network device matching device path
> + * @list: can be left uninitialized when passing from platform
> + */
> +
> +struct mac_platform {
> +	char *device_path;
> +	u8 mac[ETH_ALEN];
> +	struct list_head list; /* unused in platform data usage */
> +};
[...]
> --- /dev/null
> +++ b/net/ethernet/mac-platform.c
[...]
> +static struct mac_platform *__mac_platform_check(struct device *dev)
> +{
> +	const char *path;
> +	const char *p;
> +	const char *try;
> +	int len;
> +	struct device *devn;
> +	struct mac_platform *tmp;
> +	struct list_head *pos;
> +
> +	list_for_each(pos, &mac_platform_list) {
> +
> +		tmp = list_entry(pos, struct mac_platform, list);
> +
> +		try = tmp->device_path;
> +
> +		p = try + strlen(try);
> +		devn = dev;
> +
> +		while (devn) {
> +
> +			path = dev_name(devn);
> +			len = strlen(path);
> +
> +			if ((p - try) < len) {
> +				devn = NULL;
> +				continue;
> +			}
> +
> +			p -= len;
[...]

There are so many blank lines here, it's hard to see much code at once.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Ben Hutchings]

On Thu, 2012-07-05 at 10:44 +0800, Andy Green wrote:
[...]
> To make use of this safely you also need to make sure that any drivers that
> may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
> case) are loaded in a deterministic order.
[...]

This seems very restrictive... would it be practical to also allow a
driver name as a path component?

[...]
> --- /dev/null
> +++ b/include/net/mac-platform.h
> @@ -0,0 +1,39 @@
> +/*
> + * mac-platform.h:  Enforces platform-defined MAC for Async probed devices
> + */
> +
> +#ifndef __NET_MAC_PLATFORM_H__
> +#define __NET_MAC_PLATFORM_H__
> +
> +#include <linux/if_ether.h>
> +
> +/**
> + * struct mac_platform - associates asynchronously probed device path with
> + *			 MAC address to be assigned to the device when it
> + *			 is created

A kernel-doc summary is strictly limited to one line.  The longer
explanation can go in a paragraph under the field descriptions.

> + * @device_path: device path name of network device
> + * @mac: MAC address to assign to network device matching device path
> + * @list: can be left uninitialized when passing from platform
> + */
> +
> +struct mac_platform {
> +	char *device_path;
> +	u8 mac[ETH_ALEN];
> +	struct list_head list; /* unused in platform data usage */
> +};
[...]
> --- /dev/null
> +++ b/net/ethernet/mac-platform.c
[...]
> +static struct mac_platform *__mac_platform_check(struct device *dev)
> +{
> +	const char *path;
> +	const char *p;
> +	const char *try;
> +	int len;
> +	struct device *devn;
> +	struct mac_platform *tmp;
> +	struct list_head *pos;
> +
> +	list_for_each(pos, &mac_platform_list) {
> +
> +		tmp = list_entry(pos, struct mac_platform, list);
> +
> +		try = tmp->device_path;
> +
> +		p = try + strlen(try);
> +		devn = dev;
> +
> +		while (devn) {
> +
> +			path = dev_name(devn);
> +			len = strlen(path);
> +
> +			if ((p - try) < len) {
> +				devn = NULL;
> +				continue;
> +			}
> +
> +			p -= len;
[...]

There are so many blank lines here, it's hard to see much code at once.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

[PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Ben Hutchings]

On Thu, 2012-07-05 at 10:44 +0800, Andy Green wrote:
[...]
> To make use of this safely you also need to make sure that any drivers that
> may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
> case) are loaded in a deterministic order.
[...]

This seems very restrictive... would it be practical to also allow a
driver name as a path component?

[...]
> --- /dev/null
> +++ b/include/net/mac-platform.h
> @@ -0,0 +1,39 @@
> +/*
> + * mac-platform.h:  Enforces platform-defined MAC for Async probed devices
> + */
> +
> +#ifndef __NET_MAC_PLATFORM_H__
> +#define __NET_MAC_PLATFORM_H__
> +
> +#include <linux/if_ether.h>
> +
> +/**
> + * struct mac_platform - associates asynchronously probed device path with
> + *			 MAC address to be assigned to the device when it
> + *			 is created

A kernel-doc summary is strictly limited to one line.  The longer
explanation can go in a paragraph under the field descriptions.

> + * @device_path: device path name of network device
> + * @mac: MAC address to assign to network device matching device path
> + * @list: can be left uninitialized when passing from platform
> + */
> +
> +struct mac_platform {
> +	char *device_path;
> +	u8 mac[ETH_ALEN];
> +	struct list_head list; /* unused in platform data usage */
> +};
[...]
> --- /dev/null
> +++ b/net/ethernet/mac-platform.c
[...]
> +static struct mac_platform *__mac_platform_check(struct device *dev)
> +{
> +	const char *path;
> +	const char *p;
> +	const char *try;
> +	int len;
> +	struct device *devn;
> +	struct mac_platform *tmp;
> +	struct list_head *pos;
> +
> +	list_for_each(pos, &mac_platform_list) {
> +
> +		tmp = list_entry(pos, struct mac_platform, list);
> +
> +		try = tmp->device_path;
> +
> +		p = try + strlen(try);
> +		devn = dev;
> +
> +		while (devn) {
> +
> +			path = dev_name(devn);
> +			len = strlen(path);
> +
> +			if ((p - try) < len) {
> +				devn = NULL;
> +				continue;
> +			}
> +
> +			p -= len;
[...]

There are so many blank lines here, it's hard to see much code at once.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

[Florian Fainelli]

Hi,

Le jeudi 05 juillet 2012 04:44:33, Andy Green a écrit :
> The following series adds some code to generate legal, locally administered
> MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
> net/ethernet taking care of accepting device path / MAC mapping
> registrations and running a notifier to enforce the requested MAC when the
> matching network device turns up.

This looks like something you can solve by user-space entirely. Expose the 
OMAP4 CPU Die ID using a sysfs attribute, and let user-space manage the MAC 
address pool.

If you tell me you want to use this for nfsroot booting, what prevents you 
from using an initramfs, assign a valid MAC to your interface and switch over 
your nfsroot once the interface setup is done?

> 
> On PandaBoard / ES, two devices have no board-level MAC either assigned by
> the manufacturer or stored on the board, the last patch in the series adds
> these device paths and gets them set when the network device is registered.
> 
> Lastly for convenient testing, there's a little patch on
> omap2plus_defconfig that will get Ethernet and WLAN up on Pandaboard.
> 
> The patches are against today's linux-omap.
> 
> Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the
> helper in net/ethernet.
> 
> ---
> 
> Andy Green (4):
>       OMAP: add cpu id register to MAC address helper
>       NET ethernet introduce mac_platform helper
>       OMAP4 PANDA register ethernet and wlan for automatic mac allocation
>       config test config extending omap2plus with wl12xx etc
> 
> 
>  arch/arm/configs/omap2plus_defconfig   |   35 +++----
>  arch/arm/mach-omap2/Kconfig            |    1
>  arch/arm/mach-omap2/board-omap4panda.c |   30 ++++++
>  arch/arm/mach-omap2/id.c               |   39 ++++++++
>  arch/arm/mach-omap2/include/mach/id.h  |    1
>  include/net/mac-platform.h             |   39 ++++++++
>  net/Kconfig                            |    5 +
>  net/ethernet/Makefile                  |    3 +
>  net/ethernet/mac-platform.c            |  151
> ++++++++++++++++++++++++++++++++ 9 files changed, 282 insertions(+), 22
> deletions(-)
>  create mode 100644 include/net/mac-platform.h
>  create mode 100644 net/ethernet/mac-platform.c
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Florian

[PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

[Florian Fainelli]

Hi,

Le jeudi 05 juillet 2012 04:44:33, Andy Green a ?crit :
> The following series adds some code to generate legal, locally administered
> MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
> net/ethernet taking care of accepting device path / MAC mapping
> registrations and running a notifier to enforce the requested MAC when the
> matching network device turns up.

This looks like something you can solve by user-space entirely. Expose the 
OMAP4 CPU Die ID using a sysfs attribute, and let user-space manage the MAC 
address pool.

If you tell me you want to use this for nfsroot booting, what prevents you 
from using an initramfs, assign a valid MAC to your interface and switch over 
your nfsroot once the interface setup is done?

> 
> On PandaBoard / ES, two devices have no board-level MAC either assigned by
> the manufacturer or stored on the board, the last patch in the series adds
> these device paths and gets them set when the network device is registered.
> 
> Lastly for convenient testing, there's a little patch on
> omap2plus_defconfig that will get Ethernet and WLAN up on Pandaboard.
> 
> The patches are against today's linux-omap.
> 
> Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the
> helper in net/ethernet.
> 
> ---
> 
> Andy Green (4):
>       OMAP: add cpu id register to MAC address helper
>       NET ethernet introduce mac_platform helper
>       OMAP4 PANDA register ethernet and wlan for automatic mac allocation
>       config test config extending omap2plus with wl12xx etc
> 
> 
>  arch/arm/configs/omap2plus_defconfig   |   35 +++----
>  arch/arm/mach-omap2/Kconfig            |    1
>  arch/arm/mach-omap2/board-omap4panda.c |   30 ++++++
>  arch/arm/mach-omap2/id.c               |   39 ++++++++
>  arch/arm/mach-omap2/include/mach/id.h  |    1
>  include/net/mac-platform.h             |   39 ++++++++
>  net/Kconfig                            |    5 +
>  net/ethernet/Makefile                  |    3 +
>  net/ethernet/mac-platform.c            |  151
> ++++++++++++++++++++++++++++++++ 9 files changed, 282 insertions(+), 22
> deletions(-)
>  create mode 100644 include/net/mac-platform.h
>  create mode 100644 net/ethernet/mac-platform.c
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Florian

Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

["Andy Green (林安廸)"]

On 10/07/12 20:37, the mail apparently from Florian Fainelli included:

Hi -

> Le jeudi 05 juillet 2012 04:44:33, Andy Green a écrit :
>> The following series adds some code to generate legal, locally administered
>> MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
>> net/ethernet taking care of accepting device path / MAC mapping
>> registrations and running a notifier to enforce the requested MAC when the
>> matching network device turns up.
>
> This looks like something you can solve by user-space entirely. Expose the

That might seem so from a openwrt perspective, where you custom cook the 
whole userland thing per-device, but it ain't so from a generic rootfs 
perspective.

Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
workarounds?  And Panda is not the only device with this issue.

-Andy

[PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

["Andy Green (林安廸)"]

On 10/07/12 20:37, the mail apparently from Florian Fainelli included:

Hi -

> Le jeudi 05 juillet 2012 04:44:33, Andy Green a ?crit :
>> The following series adds some code to generate legal, locally administered
>> MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
>> net/ethernet taking care of accepting device path / MAC mapping
>> registrations and running a notifier to enforce the requested MAC when the
>> matching network device turns up.
>
> This looks like something you can solve by user-space entirely. Expose the

That might seem so from a openwrt perspective, where you custom cook the 
whole userland thing per-device, but it ain't so from a generic rootfs 
perspective.

Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
workarounds?  And Panda is not the only device with this issue.

-Andy

Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

[Steven Rostedt]

On Tue, 2012-07-10 at 20:58 +0800, "Andy Green (林安廸)" wrote:
> On 10/07/12 20:37, the mail apparently from Florian Fainelli included:
> 

> Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
> workarounds?  And Panda is not the only device with this issue.

Actually I think you just answered your own question ;-)

Anyway, I don't think an initrd solution is the best. Yeah, it's fine
for a work around, but then I need to go and screw with the initrd if it
doesn't have support for the board. If the network card already has a
MAC address, why should the kernel give it another *random* one?

This isn't a complex patch set, where the complexity should be put into
userspace. And it makes it very convenient for people that just want the
board to boot so they can test it. I'm not developing any SoC or BSP,
I'm just using it to make sure my kernel changes can also be implemented
for ARM.

-- Steve

[PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

[Steven Rostedt]

On Tue, 2012-07-10 at 20:58 +0800, "Andy Green (???)" wrote:
> On 10/07/12 20:37, the mail apparently from Florian Fainelli included:
> 

> Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
> workarounds?  And Panda is not the only device with this issue.

Actually I think you just answered your own question ;-)

Anyway, I don't think an initrd solution is the best. Yeah, it's fine
for a work around, but then I need to go and screw with the initrd if it
doesn't have support for the board. If the network card already has a
MAC address, why should the kernel give it another *random* one?

This isn't a complex patch set, where the complexity should be put into
userspace. And it makes it very convenient for people that just want the
board to boot so they can test it. I'm not developing any SoC or BSP,
I'm just using it to make sure my kernel changes can also be implemented
for ARM.

-- Steve

Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

[Alan Cox]

> Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
> workarounds?  And Panda is not the only device with this issue.

Why should we crap all over the kernel for all these board specific
problems ? Userspace code is at least pageable and generally less
security critical.

So your argument from that point of view is bunk. There are tons and tons
of boards doing tons of horrible hacks. If we mangled the generic code
for all of them the result would be a complete unmanagable pile of turd.

The use of locally administered MAC addressing is policy. The helper
belongs in userspace as it's clearly part of what udev is supposed to be
doing via device notifications, instead of your custom mini kernel-udev
hack which is what you've basically created.

We've said no to lots of people (several a year). We've done so for good
reasons. Most of them had more taste than your hack too (ok except the Pi
which was even more broken)

You need a udev rule, one single tiddly udev rule, and perhaps to expose a
sysfs node somewhere if the required generation data is on the board.
Hardly stinking up the userspace is it.

That would also then fix any races with userspace trying to set the MAC,
it would remove the need for the helper. It will avoid encoding
ultra-crappy assumptions like

"To make use of this safely you also need to make sure that any drivers
that may compete for the bus ordinal you are using (eg, mUSB and ehci in
Panda case) are loaded in a deterministic order."

What are you going to do when speeding up booting by parallelising
more probes breaks this kind of garbage assumption ?

To be honest if Fedora needs to deal with an army of craptastic devices
whose vendors can't get a MAC address on the board then they probably
need a single common change to ifup so that if you ifup an interface that
has no MAC it generates a local one. Thats about 6 lines of userspace
code in the config scripts. It's also probably a good default end user
behaviour.

And if you have a real MAC but it's not loaded into the device you can
just shove it into the platform device.

End of problem.

Alan

[PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

[Alan Cox]

> Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
> workarounds?  And Panda is not the only device with this issue.

Why should we crap all over the kernel for all these board specific
problems ? Userspace code is at least pageable and generally less
security critical.

So your argument from that point of view is bunk. There are tons and tons
of boards doing tons of horrible hacks. If we mangled the generic code
for all of them the result would be a complete unmanagable pile of turd.

The use of locally administered MAC addressing is policy. The helper
belongs in userspace as it's clearly part of what udev is supposed to be
doing via device notifications, instead of your custom mini kernel-udev
hack which is what you've basically created.

We've said no to lots of people (several a year). We've done so for good
reasons. Most of them had more taste than your hack too (ok except the Pi
which was even more broken)

You need a udev rule, one single tiddly udev rule, and perhaps to expose a
sysfs node somewhere if the required generation data is on the board.
Hardly stinking up the userspace is it.

That would also then fix any races with userspace trying to set the MAC,
it would remove the need for the helper. It will avoid encoding
ultra-crappy assumptions like

"To make use of this safely you also need to make sure that any drivers
that may compete for the bus ordinal you are using (eg, mUSB and ehci in
Panda case) are loaded in a deterministic order."

What are you going to do when speeding up booting by parallelising
more probes breaks this kind of garbage assumption ?

To be honest if Fedora needs to deal with an army of craptastic devices
whose vendors can't get a MAC address on the board then they probably
need a single common change to ifup so that if you ifup an interface that
has no MAC it generates a local one. Thats about 6 lines of userspace
code in the config scripts. It's also probably a good default end user
behaviour.

And if you have a real MAC but it's not loaded into the device you can
just shove it into the platform device.

End of problem.

Alan

arm interrupt handling

[Qipeng Zha]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2062 bytes --]

Hi
When I study the interrupt handling code in 2.6.39 for omap soc, found don't clear CPSR.I to enable irq till each ISR finished.
Is this true? Or I miss something, since this will be wired that the core will not service any other irq before complete before irq handling.


Best wishes
Qipeng


-----Original Message-----
From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of "Andy Green (林安廸)"
Sent: 2012年7月10日 20:59
To: Florian Fainelli
Cc: s-jan@ti.com; arnd@arndb.de; patches@linaro.org; tony@atomide.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; rostedt@goodmis.org; linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

On 10/07/12 20:37, the mail apparently from Florian Fainelli included:

Hi -

> Le jeudi 05 juillet 2012 04:44:33, Andy Green a écrit :
>> The following series adds some code to generate legal, locally administered
>> MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
>> net/ethernet taking care of accepting device path / MAC mapping
>> registrations and running a notifier to enforce the requested MAC when the
>> matching network device turns up.
>
> This looks like something you can solve by user-space entirely. Expose the

That might seem so from a openwrt perspective, where you custom cook the 
whole userland thing per-device, but it ain't so from a generic rootfs 
perspective.

Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
workarounds?  And Panda is not the only device with this issue.

-Andy

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

arm interrupt handling

[Qipeng Zha]

Hi
When I study the interrupt handling code in 2.6.39 for omap soc, found don't clear CPSR.I to enable irq till each ISR finished.
Is this true? Or I miss something, since this will be wired that the core will not service any other irq before complete before irq handling.


Best wishes
Qipeng


-----Original Message-----
From: linux-arm-kernel-bounces@lists.infradead.org [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of "Andy Green (林安廸)"
Sent: 2012年7月10日 20:59
To: Florian Fainelli
Cc: s-jan@ti.com; arnd@arndb.de; patches@linaro.org; tony@atomide.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; rostedt@goodmis.org; linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

On 10/07/12 20:37, the mail apparently from Florian Fainelli included:

Hi -

> Le jeudi 05 juillet 2012 04:44:33, Andy Green a écrit :
>> The following series adds some code to generate legal, locally administered
>> MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
>> net/ethernet taking care of accepting device path / MAC mapping
>> registrations and running a notifier to enforce the requested MAC when the
>> matching network device turns up.
>
> This looks like something you can solve by user-space entirely. Expose the

That might seem so from a openwrt perspective, where you custom cook the 
whole userland thing per-device, but it ain't so from a generic rootfs 
perspective.

Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
workarounds?  And Panda is not the only device with this issue.

-Andy

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel