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

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

[Andy Green]

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

[RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition

[Andy Green]

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 <andy.green@linaro.org>
---

 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();

Re: [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition

[Greg KH]

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

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

[Andy Green]

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

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

 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

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

[Arnd Bergmann]

On Saturday 12 March 2011, Andy Green wrote:
> 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 <andy.green@linaro.org>
> ---
> 
>  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;
> +}

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

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

[Andy Green]

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

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

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

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Arnd Bergmann
> Sent: Friday, March 18, 2011 2:05 PM
> To: Andy Green
> Cc: linux-kernel@vger.kernel.org; linux-usb@vger.kernel.org; 
> linux-omap@vger.kernel.org; 
> linux-arm-kernel@lists.infradead.org; patches@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:
> > 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 <andy.green@linaro.org>
> > ---
> > 
> >  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;
> > +}
> 
> 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@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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Andy Green]

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-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Roger Quadros]

On 03/13/2011 12:50 AM, ext Andy Green wrote:
> 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 <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> 
>  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 {
>  };

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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Andy Green]

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

>> +	/* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 3/5] OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430

[Andy Green]

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 <andy.green@linaro.org>
---

 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);

Re: [RFC PATCH 3/5] OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430

[Tony Lindgren]

* Andy Green <andy@warmcat.com> [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

[RFC PATCH 4/5] OMAP2+: Set onboard Ethernet MAC address using unique CPU ID data

[Andy Green]

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 <andy.green@linaro.org>
---

 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));
 

[RFC PATCH 5/5] USBNET: SMSC95XX: if mac set in platform data no need for random one

[Andy Green]

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 <steve.glendinning-sdUf+H5yV5I@public.gmane.org>
Signed-off-by: Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---

 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) {

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