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

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):
      OMAP2+: add cpu id register to MAC address helper
      net ethernet introduce mac_la_ap 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-la-ap.h                |   28 +++++
 net/Kconfig                            |   14 +++
 net/ethernet/Makefile                  |    2 
 net/ethernet/mac-la-ap.c               |  165 ++++++++++++++++++++++++++++++++
 9 files changed, 294 insertions(+), 21 deletions(-)
 create mode 100644 include/net/mac-la-ap.h
 create mode 100644 net/ethernet/mac-la-ap.c

From: Andy Green <redacted>

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 <redacted>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nicolas Pitre <redacted>
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 00486a8..2a44c42 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 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

From: Andy Green <redacted>

This introduces a small helper in net/ethernet, which registers a
network notifier on init, and accepts registrations of 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.

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.

Signed-off-by: Andy Green <redacted>
---
 include/net/mac-la-ap.h  |   28 ++++++++
 net/Kconfig              |   14 ++++
 net/ethernet/Makefile    |    2 +
 net/ethernet/mac-la-ap.c |  165 ++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 209 insertions(+)
 create mode 100644 include/net/mac-la-ap.h
 create mode 100644 net/ethernet/mac-la-ap.c

diff --git a/include/net/mac-la-ap.h b/include/net/mac-la-ap.h
new file mode 100644
index 0000000..d5189b5
--- /dev/null
+++ b/include/net/mac-la-ap.h

@@ -0,0 +1,28 @@
+/*
+ * mac-la-ap.h:  Locally Administered MAC address for Async probed devices
+ */
+
+/**
+ * struct mac_la_ap - 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_la_ap {
+	char *device_path;
+	u8 mac[6];
+	struct list_head list; /* unused in platform data usage */
+};
+
+/**
+ * mac_la_ap_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_la_ap terminated by entry with NULL device_path
+ */
+int mac_la_ap_register_device_macs(const struct mac_la_ap *macs);
+

diff --git a/net/Kconfig b/net/Kconfig
index 245831b..76ba70e 100644
--- a/net/Kconfig
+++ b/net/Kconfig

@@ -335,6 +335,20 @@ source "net/caif/Kconfig"
 source "net/ceph/Kconfig"
 source "net/nfc/Kconfig"
 
+config MAC_LA_AP
+	bool "Locally Administered MAC for Aysnchronously Probed devices"
+	---help---
+	This helper allows platforms to mandate a locally-administered
+	sythesized MAC address for network devices that are on asynchronously-
+	probed buses like USB or SDIO.  This is necessary when the board has
+	these network assets but no arrangements for storing or setting the
+	MAC address of the network asset (nor any official MAC address
+	reserved for the device).  In that case, seen in Panda and other
+	boards, the platform can synthesize a constant locally-administered
+	MAC address from SoC UID bits that has a good probability of differing
+	between boards but will be constant on any give board.  This helper
+	will take care of watching for the network devices to appear and
+	force the MAC to the synthesized one when they do.
 
 endif   # if NET
 

diff --git a/net/ethernet/Makefile b/net/ethernet/Makefile
index 7cef1d8..94ee883 100644
--- a/net/ethernet/Makefile
+++ b/net/ethernet/Makefile

@@ -5,3 +5,5 @@
 obj-y					+= eth.o
 obj-$(subst m,y,$(CONFIG_IPX))		+= pe2.o
 obj-$(subst m,y,$(CONFIG_ATALK))	+= pe2.o
+obj-$(CONFIG_MAC_LA_AP)			+= mac-la-ap.o
+

diff --git a/net/ethernet/mac-la-ap.c b/net/ethernet/mac-la-ap.c
new file mode 100644
index 0000000..4216c41
--- /dev/null
+++ b/net/ethernet/mac-la-ap.c

@@ -0,0 +1,165 @@
+/*
+ * Helper to allow setting locally-administered MAC addresses 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 <linux/if_ether.h>
+#include <net/mac-la-ap.h>
+
+static struct mac_la_ap mac_la_ap_list;
+DEFINE_MUTEX(mac_la_ap_mutex);
+bool mac_la_ap_started;
+
+static struct mac_la_ap *__mac_la_ap_check(struct device *dev)
+{
+	const char *path;
+	const char *p;
+	const char *try;
+	int len;
+	struct device *devn;
+	struct mac_la_ap *tmp;
+	struct list_head *pos;
+
+	list_for_each(pos, &mac_la_ap_list.list) {
+
+		tmp = list_entry(pos, struct mac_la_ap, 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;
+		}
+
+		try++;
+	}
+
+	return NULL;
+}
+
+static int mac_la_ap_netdev_event(struct notifier_block *this,
+						unsigned long event, void *ptr)
+{
+	struct net_device *dev = ptr;
+	struct sockaddr sa;
+	struct mac_la_ap *match;
+
+	if (event != NETDEV_REGISTER)
+		return NOTIFY_DONE;
+
+	mutex_lock(&mac_la_ap_mutex);
+
+	match = __mac_la_ap_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_la_ap_mutex);
+
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block mac_la_ap_netdev_notifier = {
+	.notifier_call = mac_la_ap_netdev_event,
+	.priority = 1,
+};
+
+static int mac_la_ap_init(void)
+{
+	int ret;
+
+	INIT_LIST_HEAD(&mac_la_ap_list.list);
+	mutex_init(&mac_la_ap_mutex);
+	ret = register_netdevice_notifier(&mac_la_ap_netdev_notifier);
+	if (!ret)
+		mac_la_ap_started = 1;
+	else
+		pr_err("mac_la_ap_init: Notifier registration failed\n");
+
+	return ret;
+}
+
+int mac_la_ap_register_device_macs(const struct mac_la_ap *macs)
+{
+	struct mac_la_ap *next;
+	int ret = 0;
+
+	if (!mac_la_ap_started) {
+		ret = mac_la_ap_init();
+		if (ret)
+			return ret;
+	}
+
+	mutex_lock(&mac_la_ap_mutex);
+
+	while (macs->device_path) {
+
+		next = kmalloc(sizeof(struct mac_la_ap), 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_la_ap_list.list);
+
+		macs++;
+	}
+
+bail:
+	mutex_unlock(&mac_la_ap_mutex);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(mac_la_ap_register_device_macs);

From: Andy Green <redacted>

This provides the board-specific device paths needed to get
the panda boardfile working with the mac-la-ap 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 <redacted>
---
 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 5e95aa6..d968e7f 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig

@@ -348,6 +348,7 @@ config MACH_OMAP4_PANDA
 	select OMAP_PACKAGE_CBL
 	select OMAP_PACKAGE_CBS
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select MAC_LA_AP
 
 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..8f4984b 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-la-ap.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_la_ap panda_mac_la_ap[] = {
+
+	{ /* 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_la_ap) - 1; n++)
+		omap2_die_id_to_ethernet_mac(panda_mac_la_ap[n].mac, n);
+	if (mac_la_ap_register_device_macs(panda_mac_la_ap))
+		pr_err("Unable to register mac_la_ap devices\n");
+
 	ret = wl12xx_set_platform_data(&omap_panda_wlan_data);
 	if (ret)
 		pr_err("error setting wl12xx data: %d\n", ret);

From: Andy Green <redacted>

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

On Monday 02 July 2012, Andy Green wrote:

From: Andy Green <redacted>

This introduces a small helper in net/ethernet, which registers a
network notifier on init, and accepts registrations of 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.

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.

Signed-off-by: Andy Green <redacted>

Yes, looks good to me in principle. It needs to get sent to the linux-kernel
and netdev mailing lists for review though. A few small comments.

I find the name a bit non-obvious, not sure if we can come up with the
perfect one.

How about mac-platform?

This one needs to be either a silent option (only selected by the
platforms that want it) or the header file has to provide a
static-inline fallback that does nothing, so we don't get
a build failure on platforms that need it if the option gets
disabled.

I'd prefer making it a silent option because then we don't bloat
the kernel if someone accidentally enables it on a platform that
does not use it.

+static struct mac_la_ap mac_la_ap_list;

The normal way to do this is to have just a list head that the
entries get added to:

static LIST_HEAD(mac_la_ap_list);

That also takes care of the initialization.

+DEFINE_MUTEX(mac_la_ap_mutex);
+bool mac_la_ap_started;

These should all be static.

+static int mac_la_ap_init(void)
+{
+	int ret;
+
+	INIT_LIST_HEAD(&mac_la_ap_list.list);
+	mutex_init(&mac_la_ap_mutex);
+	ret = register_netdevice_notifier(&mac_la_ap_netdev_notifier);
+	if (!ret)
+		mac_la_ap_started = 1;
+	else
+		pr_err("mac_la_ap_init: Notifier registration failed\n");
+
+	return ret;
+}

The mutex is already initialized, and the list head too if you do the
change above.

I think it would be simpler to register the notifier from an
initcall and drop the mac_la_ap_started variable.

+int mac_la_ap_register_device_macs(const struct mac_la_ap *macs)
+{

+}
+EXPORT_SYMBOL_GPL(mac_la_ap_register_device_macs);

I'm not sure if there is any point in exporting this function, my feeling
is that it would only ever be called from built-in code. If we can call it
from a module, we should probably also allow this file to be a loadable
module as well.

	Arnd

On Mon, 2012-07-02 at 16:12 +0000, Arnd Bergmann wrote:

quoted

 include/net/mac-la-ap.h  |   28 ++++++++
 net/Kconfig              |   14 ++++
 net/ethernet/Makefile    |    2 +
 net/ethernet/mac-la-ap.c |  165 ++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 209 insertions(+)
 create mode 100644 include/net/mac-la-ap.h
 create mode 100644 net/ethernet/mac-la-ap.c

diff --git a/include/net/mac-la-ap.h b/include/net/mac-la-ap.h
new file mode 100644
index 0000000..d5189b5
--- /dev/null
+++ b/include/net/mac-la-ap.h

@@ -0,0 +1,28 @@
+/*
+ * mac-la-ap.h:  Locally Administered MAC address for Async probed devices
+ */

I find the name a bit non-obvious, not sure if we can come up with the
perfect one.

How about mac-platform?

I really find it unfortunate that 'mac' for ethernet has the same name
as the Apple box as well. 'mac' in other contexts can usually
differentiate these two, but saying 'mac-platform' just screams of
forbidden fruit.

mac-probe.h ?

-- Steve

On 07/03/12 00:12, the mail apparently from Arnd Bergmann included:

On Monday 02 July 2012, Andy Green wrote:

quoted

From: Andy Green <redacted>

This introduces a small helper in net/ethernet, which registers a
network notifier on init, and accepts registrations of expected asynchronously-

Yes, looks good to me in principle. It needs to get sent to the linux-kernel
and netdev mailing lists for review though. A few small comments.

I wanted to hear that it had actually converged with what was being 
talked about first.  I just sent out a v3 with the relevant patch also 
cc-d to those lists but stg mail didn't seem to send it to them.  I'll 
wait for any further comments here and resend the whole thing including 
those lists.

I find the name a bit non-obvious, not sure if we can come up with the
perfect one.	

How about mac-platform?

Done.

quoted

  endif   # if NET

This one needs to be either a silent option (only selected by the
platforms that want it) or the header file has to provide a
static-inline fallback that does nothing, so we don't get
a build failure on platforms that need it if the option gets
disabled.

I'd prefer making it a silent option because then we don't bloat
the kernel if someone accidentally enables it on a platform that
does not use it.

Done.  It's already added as a select on the Panda board config.

I also moved it out of the "if NET" clause and took care about the case 
that CONFIG_NET is off but we still have mac-platform references.

quoted

+static struct mac_la_ap mac_la_ap_list;

The normal way to do this is to have just a list head that the
entries get added to:

static LIST_HEAD(mac_la_ap_list);

That also takes care of the initialization.

Thanks for normalizing it, done.

quoted

+DEFINE_MUTEX(mac_la_ap_mutex);
+bool mac_la_ap_started;

These should all be static.

Right, done.

I think it would be simpler to register the notifier from an
initcall and drop the mac_la_ap_started variable.

That was my first approach, to structure it as a real driver.  I had 
tried a few likely-looking initcall levels but the init of the helper 
was coming after the init of the network code.

I found this time that core_initcall works, so I used that, dropped the 
flag.  But isn't it a bit tricky with these to know if the prerequisite 
you're trying to ensure is already initialized might not actually be at 
the same initcall level and you're working by accident?

quoted

+int mac_la_ap_register_device_macs(const struct mac_la_ap *macs)
+{

quoted

+}
+EXPORT_SYMBOL_GPL(mac_la_ap_register_device_macs);

I'm not sure if there is any point in exporting this function, my feeling
is that it would only ever be called from built-in code. If we can call it
from a module, we should probably also allow this file to be a loadable
module as well.

Being a modular API for platform code to call doesn't make sense, I got 
rid of the export.

-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

On Tuesday 03 July 2012, Andy Green wrote:

quoted

I think it would be simpler to register the notifier from an
initcall and drop the mac_la_ap_started variable.

That was my first approach, to structure it as a real driver.  I had 
tried a few likely-looking initcall levels but the init of the helper 
was coming after the init of the network code.

I found this time that core_initcall works, so I used that, dropped the 
flag.  But isn't it a bit tricky with these to know if the prerequisite 
you're trying to ensure is already initialized might not actually be at 
the same initcall level and you're working by accident?

Well, you would only need to ensure that it's called before any of the
network devices are added, which should all happen very late in the
boot cycle compared to the platform init code.

I think core_initcall is fine here.

	Arnd

On Mon, 2012-07-02 at 12:35 -0400, Steven Rostedt wrote:

On Mon, 2012-07-02 at 16:12 +0000, Arnd Bergmann wrote:

quoted

quoted

 include/net/mac-la-ap.h  |   28 ++++++++
 net/Kconfig              |   14 ++++
 net/ethernet/Makefile    |    2 +
 net/ethernet/mac-la-ap.c |  165 ++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 209 insertions(+)
 create mode 100644 include/net/mac-la-ap.h
 create mode 100644 net/ethernet/mac-la-ap.c

diff --git a/include/net/mac-la-ap.h b/include/net/mac-la-ap.h
new file mode 100644
index 0000000..d5189b5
--- /dev/null
+++ b/include/net/mac-la-ap.h

@@ -0,0 +1,28 @@
+/*
+ * mac-la-ap.h:  Locally Administered MAC address for Async probed devices
+ */

I find the name a bit non-obvious, not sure if we can come up with the
perfect one.

How about mac-platform?

I really find it unfortunate that 'mac' for ethernet has the same name
as the Apple box as well. 'mac' in other contexts can usually
differentiate these two, but saying 'mac-platform' just screams of
forbidden fruit.

mac-probe.h ?

Maybe eth_mac_addr.h?

underscore filenames outnumber dash filenames ~2:1

$ git ls-files "*_*" | while read file ; do basename $file; done | grep "_" | wc -l
11185
$ git ls-files "*-*" | while read file ; do basename $file; done | grep "-" | wc -l
6624