| Message ID | 20110312225047.27728.1835.stgit@otae.warmcat.com |
|---|---|
| State | New |
| Headers | show |
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
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
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?
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
> -----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 >
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@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
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
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(-)