* [RFC PATCH 0/5] OMAP2+ / Panda implementation for async platform_data
@ 2011-03-12 22:50 Andy Green
2011-03-12 22:50 ` [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition Andy Green
` (4 more replies)
0 siblings, 5 replies; 14+ messages in thread
From: Andy Green @ 2011-03-12 22:50 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition
2011-03-12 22:50 [RFC PATCH 0/5] OMAP2+ / Panda implementation for async platform_data Andy Green
@ 2011-03-12 22:50 ` Andy Green
2011-03-13 1:05 ` Greg KH
2011-03-12 22:50 ` [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper Andy Green
` (3 subsequent siblings)
4 siblings, 1 reply; 14+ messages in thread
From: Andy Green @ 2011-03-12 22:50 UTC (permalink / raw)
To: linux-arm-kernel
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();
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper
2011-03-12 22:50 [RFC PATCH 0/5] OMAP2+ / Panda implementation for async platform_data Andy Green
2011-03-12 22:50 ` [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition Andy Green
@ 2011-03-12 22:50 ` Andy Green
2011-03-18 8:34 ` Arnd Bergmann
2011-03-18 8:52 ` Roger Quadros
2011-03-12 22:50 ` [RFC PATCH 3/5] OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430 Andy Green
` (2 subsequent siblings)
4 siblings, 2 replies; 14+ messages in thread
From: Andy Green @ 2011-03-12 22:50 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [RFC PATCH 3/5] OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430
2011-03-12 22:50 [RFC PATCH 0/5] OMAP2+ / Panda implementation for async platform_data Andy Green
2011-03-12 22:50 ` [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition Andy Green
2011-03-12 22:50 ` [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper Andy Green
@ 2011-03-12 22:50 ` Andy Green
2011-03-14 18:12 ` Tony Lindgren
2011-03-12 22:51 ` [RFC PATCH 4/5] OMAP2+: Set onboard Ethernet MAC address using unique CPU ID data Andy Green
2011-03-12 22:51 ` [RFC PATCH 5/5] USBNET: SMSC95XX: if mac set in platform data no need for random one Andy Green
4 siblings, 1 reply; 14+ messages in thread
From: Andy Green @ 2011-03-12 22:50 UTC (permalink / raw)
To: linux-arm-kernel
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);
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [RFC PATCH 4/5] OMAP2+: Set onboard Ethernet MAC address using unique CPU ID data
2011-03-12 22:50 [RFC PATCH 0/5] OMAP2+ / Panda implementation for async platform_data Andy Green
` (2 preceding siblings ...)
2011-03-12 22:50 ` [RFC PATCH 3/5] OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430 Andy Green
@ 2011-03-12 22:51 ` Andy Green
2011-03-12 22:51 ` [RFC PATCH 5/5] USBNET: SMSC95XX: if mac set in platform data no need for random one Andy Green
4 siblings, 0 replies; 14+ messages in thread
From: Andy Green @ 2011-03-12 22:51 UTC (permalink / raw)
To: linux-arm-kernel
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));
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [RFC PATCH 5/5] USBNET: SMSC95XX: if mac set in platform data no need for random one
2011-03-12 22:50 [RFC PATCH 0/5] OMAP2+ / Panda implementation for async platform_data Andy Green
` (3 preceding siblings ...)
2011-03-12 22:51 ` [RFC PATCH 4/5] OMAP2+: Set onboard Ethernet MAC address using unique CPU ID data Andy Green
@ 2011-03-12 22:51 ` Andy Green
4 siblings, 0 replies; 14+ messages in thread
From: Andy Green @ 2011-03-12 22:51 UTC (permalink / raw)
To: linux-arm-kernel
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@smsc.com>
Signed-off-by: Andy Green <andy.green@linaro.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) {
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition
2011-03-12 22:50 ` [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition Andy Green
@ 2011-03-13 1:05 ` Greg KH
0 siblings, 0 replies; 14+ messages in thread
From: Greg KH @ 2011-03-13 1:05 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH 3/5] OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430
2011-03-12 22:50 ` [RFC PATCH 3/5] OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430 Andy Green
@ 2011-03-14 18:12 ` Tony Lindgren
0 siblings, 0 replies; 14+ messages in thread
From: Tony Lindgren @ 2011-03-14 18:12 UTC (permalink / raw)
To: linux-arm-kernel
* 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper
2011-03-12 22:50 ` [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper Andy Green
@ 2011-03-18 8:34 ` Arnd Bergmann
2011-03-18 8:49 ` Andy Green
2011-03-18 14:37 ` Premi, Sanjeev
2011-03-18 8:52 ` Roger Quadros
1 sibling, 2 replies; 14+ messages in thread
From: Arnd Bergmann @ 2011-03-18 8:34 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper
2011-03-18 8:34 ` Arnd Bergmann
@ 2011-03-18 8:49 ` Andy Green
2011-03-18 14:37 ` Premi, Sanjeev
1 sibling, 0 replies; 14+ messages in thread
From: Andy Green @ 2011-03-18 8:49 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper
2011-03-12 22:50 ` [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper Andy Green
2011-03-18 8:34 ` Arnd Bergmann
@ 2011-03-18 8:52 ` Roger Quadros
2011-03-18 9:13 ` Andy Green
1 sibling, 1 reply; 14+ messages in thread
From: Roger Quadros @ 2011-03-18 8:52 UTC (permalink / raw)
To: linux-arm-kernel
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@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 {
> };
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper
2011-03-18 8:52 ` Roger Quadros
@ 2011-03-18 9:13 ` Andy Green
0 siblings, 0 replies; 14+ messages in thread
From: Andy Green @ 2011-03-18 9:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper
2011-03-18 8:34 ` Arnd Bergmann
2011-03-18 8:49 ` Andy Green
@ 2011-03-18 14:37 ` Premi, Sanjeev
2011-03-18 14:47 ` Andy Green
1 sibling, 1 reply; 14+ messages in thread
From: Premi, Sanjeev @ 2011-03-18 14:37 UTC (permalink / raw)
To: linux-arm-kernel
> -----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:
> > 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 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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper
2011-03-18 14:37 ` Premi, Sanjeev
@ 2011-03-18 14:47 ` Andy Green
0 siblings, 0 replies; 14+ messages in thread
From: Andy Green @ 2011-03-18 14:47 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-03-18 14:47 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-12 22:50 [RFC PATCH 0/5] OMAP2+ / Panda implementation for async platform_data Andy Green
2011-03-12 22:50 ` [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition Andy Green
2011-03-13 1:05 ` Greg KH
2011-03-12 22:50 ` [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper Andy Green
2011-03-18 8:34 ` Arnd Bergmann
2011-03-18 8:49 ` Andy Green
2011-03-18 14:37 ` Premi, Sanjeev
2011-03-18 14:47 ` Andy Green
2011-03-18 8:52 ` Roger Quadros
2011-03-18 9:13 ` Andy Green
2011-03-12 22:50 ` [RFC PATCH 3/5] OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430 Andy Green
2011-03-14 18:12 ` Tony Lindgren
2011-03-12 22:51 ` [RFC PATCH 4/5] OMAP2+: Set onboard Ethernet MAC address using unique CPU ID data Andy Green
2011-03-12 22:51 ` [RFC PATCH 5/5] USBNET: SMSC95XX: if mac set in platform data no need for random one Andy Green
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).