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 <[email protected]>
---
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 <[email protected]>
---
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 <[email protected]>
---
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 <[email protected]>
---
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 <[email protected]>
Signed-off-by: Andy Green <[email protected]>
---
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 <[email protected]> [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:
> 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 <[email protected]>
> ---
>
> 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 <[email protected]>
> ---
>
> 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
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: [email protected]
> [mailto:[email protected]] On Behalf Of Arnd Bergmann
> Sent: Friday, March 18, 2011 2:05 PM
> To: Andy Green
> Cc: [email protected]; [email protected];
> [email protected];
> [email protected]; [email protected]; 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 <[email protected]>
> > ---
> >
> > 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/[email protected]/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 [email protected]
> 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/[email protected]/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