[RFC PATCH 0/5] OMAP2+ / Panda implementation for async platform_data

The following series uses the

 - proposed platform support for async platform data

    http://marc.info/?l=linux-kernel&m=129996915023642&w=2

 - proposed usb core and usbnet use of async platform data

    http://marc.info/?l=linux-kernel&m=129996960824035&w=2

in order to configure onboard USB <-> Ethernet bridge wired up on
Panda boards.  The same issue exists on Beagle XM boards which also
have an onboard soldered USB <-> Ethernet bridge terminating on a
normal onboard RJ45 socket.

With the above support, these patches extend platform_data led
control of onboard assets to include those probed by USB bus
asynchronously.

In the Panda case, it uses the platform data introduced to usbnet
to enforce the selection of eth%d address since the board definition
file knows it is a permaently wired onboard connection using RJ45
jack, and to define the MAC address from unique CPU DIE ID data.

---

Andy Green (5):
      USBNET: SMSC95XX: if mac set in platform data no need for random one
      OMAP2+: Set onboard Ethernet MAC address using unique CPU ID data
      OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430
      OMAP2+: add cpu id register to MAC address helper
      OMAP2+: Panda introduce async platform data definition


 drivers/net/usb/smsc95xx.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

-- 
Signature

This is part of an RFC patch series introducing asynchronous platform
data, which may be attached to discovered bus devices at probe time
based on the device path.

As part of the series, platform_data is enabled in usbnet layer.

This patch defines the usbnet platform data, allowing the panda board
definition file to assert the naming of the usbnet network interface
should be eth%d instead of usb%d.

Signed-off-by: Andy Green <redacted>
---

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

diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index e944025..7c7aa74 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c

@@ -26,6 +26,12 @@
 #include <linux/usb/otg.h>
 #include <linux/i2c/twl.h>
 #include <linux/regulator/machine.h>
+#include <linux/usb.h>
+#include <linux/skbuff.h>
+#include <linux/mii.h>
+#include <linux/netdevice.h>
+#include <linux/if_ether.h>
+#include <linux/usb/usbnet.h>
 
 #include <mach/hardware.h>
 #include <mach/omap4-common.h>

@@ -397,6 +403,17 @@ static struct omap_board_mux board_mux[] __initdata = {
 #define board_mux	NULL
 #endif
 
+struct usbnet_platform_data panda_usbnet_platform_data_usb1_1 = {
+	.flags = USBNET_PLATDATA_FLAG__FORCE_ETH_IFNAME,
+};
+
+struct platform_async_platform_data panda_async_pdata_map[] = {
+	{
+		.device_path = "usb1/1-1/1-1.1",
+		.platform_data = &panda_usbnet_platform_data_usb1_1,
+	},
+};
+
 static void __init omap4_panda_init(void)
 {
 	int package = OMAP_PACKAGE_CBS;

@@ -405,6 +422,9 @@ static void __init omap4_panda_init(void)
 		package = OMAP_PACKAGE_CBL;
 	omap4_mux_init(board_mux, package);
 
+	platform_async_platform_data_register(panda_async_pdata_map,
+					   ARRAY_SIZE(panda_async_pdata_map));
+
 	omap4_panda_i2c_init();
 	platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
 	omap_serial_init();

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

Signed-off-by: Andy Green <redacted>
---

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

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..fc69ec5 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c

@@ -506,3 +506,16 @@ void __init omap2_set_globals_tap(struct omap_globals *omap2_globals)
 	else
 		tap_prod_id = 0x0208;
 }
+
+
+void omap2_die_id_to_mac(u8 *mac, int length)
+{
+	struct omap_die_id odi;
+
+	omap_get_die_id(&odi);
+	memcpy(mac, &odi.id_0, length);
+
+	/* 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..72e10eb 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_mac(u8 *mac, int length);
 
 #endif

This adapts the register offsets used to read the CPU DIE ID registers
when run on 44XX so they match what is in the OMAP4430 Reference Manual
page 269

Signed-off-by: Andy Green <redacted>
---

 arch/arm/mach-omap2/id.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index fc69ec5..733bb27 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c

@@ -84,6 +84,11 @@ EXPORT_SYMBOL(omap_type);
 #define OMAP_TAP_DIE_ID_2	0x0220
 #define OMAP_TAP_DIE_ID_3	0x0224
 
+#define OMAP_TAP_DIE_ID_44XX_0	0x0200
+#define OMAP_TAP_DIE_ID_44XX_1	0x0208
+#define OMAP_TAP_DIE_ID_44XX_2	0x020c
+#define OMAP_TAP_DIE_ID_44XX_3	0x0210
+
 #define read_tap_reg(reg)	__raw_readl(tap_base  + (reg))
 
 struct omap_id {

@@ -107,6 +112,14 @@ static u16 tap_prod_id;
 
 void omap_get_die_id(struct omap_die_id *odi)
 {
+	if (cpu_is_omap44xx()) {
+		odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
+		odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
+		odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
+		odi->id_3 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_3);
+
+		return;
+	}
 	odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_0);
 	odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_1);
 	odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_2);

This is part of an RFC patch series introducing asynchronous platform
data, which may be attached to discovered bus devices at probe time
based on the device path.

As part of the series, platform_data is enabled in usbnet layer.

This patch used the usbnet platform data in the panda board
definition file to set the MAC address of the USB <-> Ethernet
onboard bridge to a unique value derived from unique CPU ID
data.

Signed-off-by: Andy Green <redacted>
---

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

diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 7c7aa74..312154b 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c

@@ -35,6 +35,7 @@
 
 #include <mach/hardware.h>
 #include <mach/omap4-common.h>
+#include <mach/id.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>

@@ -404,7 +405,8 @@ static struct omap_board_mux board_mux[] __initdata = {
 #endif
 
 struct usbnet_platform_data panda_usbnet_platform_data_usb1_1 = {
-	.flags = USBNET_PLATDATA_FLAG__FORCE_ETH_IFNAME,
+	.flags = USBNET_PLATDATA_FLAG__FORCE_ETH_IFNAME |
+			USBNET_PLATDATA_FLAG__USE_MAC,
 };
 
 struct platform_async_platform_data panda_async_pdata_map[] = {

@@ -422,6 +424,8 @@ static void __init omap4_panda_init(void)
 		package = OMAP_PACKAGE_CBL;
 	omap4_mux_init(board_mux, package);
 
+	omap2_die_id_to_mac(panda_usbnet_platform_data_usb1_1.mac,
+				 sizeof(panda_usbnet_platform_data_usb1_1.mac));
 	platform_async_platform_data_register(panda_async_pdata_map,
 					   ARRAY_SIZE(panda_async_pdata_map));
 

This is part of an RFC patch series introducing asynchronous platform
data, which may be attached to discovered bus devices at probe time
based on the device path.

As part of the series, platform_data is enabled in usbnet layer.

This patch allows smsc95xx usbnet driver to understand that the MAC
setting was handled by plaform_data sent into usbnet, and that it
does not need to overwrite the already correct MAC with a random one.

Cc: Steve Glendinning <redacted>
Signed-off-by: Andy Green <redacted>
---

 drivers/net/usb/smsc95xx.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index bc86f4b..1d09cad 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c

@@ -639,6 +639,16 @@ static int smsc95xx_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
 
 static void smsc95xx_init_mac_address(struct usbnet *dev)
 {
+	struct usbnet_platform_data *pdata = dev->udev->dev.platform_data;
+
+	/*
+	 * if netdev platform data has taken responsibility for forcing
+	 * the MAC then nothing to do here
+	 */
+
+	if (pdata && pdata->flags & USBNET_PLATDATA_FLAG__USE_MAC)
+		return;
+
 	/* try reading mac address from EEPROM */
 	if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
 			dev->net->dev_addr) == 0) {

On Sat, Mar 12, 2011 at 10:50:39PM +0000, Andy Green wrote:

This is part of an RFC patch series introducing asynchronous platform
data, which may be attached to discovered bus devices at probe time
based on the device path.

As part of the series, platform_data is enabled in usbnet layer.

This patch defines the usbnet platform data, allowing the panda board
definition file to assert the naming of the usbnet network interface
should be eth%d instead of usb%d.

Why is this?  If you want to do this, it should be done in userspace
today, no need to involve the kernel in this type of thing.

So I don't see the point of this patch.

thanks,

greg k-h

* Andy Green [off-list ref] [110312 14:49]:

This adapts the register offsets used to read the CPU DIE ID registers
when run on 44XX so they match what is in the OMAP4430 Reference Manual
page 269

I'll apply only this patch, looks like the rest needs more discussion.

Regards,

Tony

On Saturday 12 March 2011, Andy Green wrote:

This is a pretty clever trick, but it's not an official globally unique MAC
address, right? Maybe we can ask TI to officially request a MAC address range
for OMAP SoCs and document an official procedure to compute it.

	Arnd

On 03/18/2011 08:34 AM, Somebody in the thread at some point said:

quoted

+void omap2_die_id_to_mac(u8 *mac, int length)
+{
+       struct omap_die_id odi;
+
+       omap_get_die_id(&odi);
+       memcpy(mac,&odi.id_0, length);
+
+       /* mark it as not multicast and outside official 80211 MAC namespace */
+
+       mac[0] = (mac[0]&  ~1) | 2;
+}

This is a pretty clever trick, but it's not an official globally unique MAC
address, right? Maybe we can ask TI to officially request a MAC address range
for OMAP SoCs and document an official procedure to compute it.

This was an idea from Loic Minier.  80211 allows local namespace MACs, 
this one is marked up as such, so it is as OK as the CPU ID bits are 
reasonably well distributed in terms of collision.

You are right though the overall correct solution from the board side is 
to have paid for two (WLAN has the same problem -- worse right now it 
comes up with 00:00:00:00:00:00) proper namespace MACs.  That's still 
not enough because there must be somewhere on the board to store it, I 
call this "board identity" storage, and there is nowhere on Panda.  If 
you put it on SD card, it has the effect that your MAC address moves 
with the SD card between boards which is less than ideal, you have to 
make sure if he rewrites his SD card somehow it knows to use the right 
mac address... it's not credible.

The problem with what you suggested is that CPU ID is just a static 
token chosen arbitrarily by TI in the factory so you can't somehow 
"compute" the MAC which is assigned by IEEE, which is also an arbitrary 
range chosen by them, from the unrelated CPU ID content.

It is interesting to use CPU ID though because it will not vary 
per-board.  So this is why the patch arrives at what it is doing using 
the legal private namespace concept.

-Andy

On 03/13/2011 12:50 AM, ext Andy Green wrote:

so here lies the answer to my question "From where do you get the MAC" :)

Is there a guarantee that this MAC will work in all Ethernet setups?

-- 
regards,
-roger

On 03/18/2011 08:52 AM, Somebody in the thread at some point said:

quoted

+	/* mark it as not multicast and outside official 80211 MAC namespace */
+
+	mac[0] = (mac[0]&  ~1) | 2;

so here lies the answer to my question "From where do you get the MAC" :)

Is there a guarantee that this MAC will work in all Ethernet setups?

Yeah it's in 80211 spec.  You have to buy the spec, I can't point you to 
it directly, but here is the wikipedia article showing the structure

http://en.wikipedia.org/wiki/MAC_address#Address_details

the random mac addresses generated by the kernel also use this scheme.

-Andy

-----Original Message-----
From: linux-omap-owner at vger.kernel.org 
[mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Arnd Bergmann
Sent: Friday, March 18, 2011 2:05 PM
To: Andy Green
Cc: linux-kernel at vger.kernel.org; linux-usb at vger.kernel.org; 
linux-omap at vger.kernel.org; 
linux-arm-kernel at lists.infradead.org; patches at linaro.org; Andy Green
Subject: Re: [RFC PATCH 2/5] OMAP2+: add cpu id register to 
MAC address helper

On Saturday 12 March 2011, Andy Green wrote:

quoted

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

Signed-off-by: Andy Green <redacted>
---

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

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..fc69ec5 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c

@@ -506,3 +506,16 @@ void __init 

omap2_set_globals_tap(struct omap_globals *omap2_globals)

quoted

        else
                tap_prod_id = 0x0208;
 }
+
+
+void omap2_die_id_to_mac(u8 *mac, int length)
+{
+       struct omap_die_id odi;
+
+       omap_get_die_id(&odi);
+       memcpy(mac, &odi.id_0, length);
+
+       /* mark it as not multicast and outside official 

80211 MAC namespace */

quoted

+
+       mac[0] = (mac[0] & ~1) | 2;
+}

This is a pretty clever trick, but it's not an official 
globally unique MAC
address, right?

[sp] This 'trick' has been tried earlier in u-boot. See:
     http://www.mail-archive.com/u-boot at lists.denx.de/msg19915.html

     I am also not sure whether DIE_ID would really be unique.

~sanjeev

Maybe we can ask TI to officially request a 
MAC address range
for OMAP SoCs and document an official procedure to compute it.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe 
linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 03/18/2011 02:37 PM, Somebody in the thread at some point said:

Hi -

[sp] This 'trick' has been tried earlier in u-boot. See:
      http://www.mail-archive.com/u-boot at lists.denx.de/msg19915.html

      I am also not sure whether DIE_ID would really be unique.

It doesn't actually need all the bits to be unique for this, just have a 
low probability of collision with a reasonable number of devices sharing 
the same network.

If there is not enough variation as it stands in the first 6 bytes of 
it, all the 128 bit ID can be xor'd together, use the other registers 
about die revision, hawkeye also xored in, etc.

I'll ask about what can be expected from this at TI.

-Andy