From: Andy Green <hidden> Date: 2012-07-05 02:55:14
The following series adds some code to generate legal, locally administered
MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
net/ethernet taking care of accepting device path / MAC mapping registrations
and running a notifier to enforce the requested MAC when the matching network
device turns up.
On PandaBoard / ES, two devices have no board-level MAC either assigned by
the manufacturer or stored on the board, the last patch in the series adds
these device paths and gets them set when the network device is registered.
Lastly for convenient testing, there's a little patch on omap2plus_defconfig
that will get Ethernet and WLAN up on Pandaboard.
The patches are against today's linux-omap.
Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the
helper in net/ethernet.
---
Andy Green (4):
OMAP: add cpu id register to MAC address helper
NET ethernet introduce mac_platform helper
OMAP4 PANDA register ethernet and wlan for automatic mac allocation
config test config extending omap2plus with wl12xx etc
arch/arm/configs/omap2plus_defconfig | 35 +++----
arch/arm/mach-omap2/Kconfig | 1
arch/arm/mach-omap2/board-omap4panda.c | 30 ++++++
arch/arm/mach-omap2/id.c | 39 ++++++++
arch/arm/mach-omap2/include/mach/id.h | 1
include/net/mac-platform.h | 39 ++++++++
net/Kconfig | 5 +
net/ethernet/Makefile | 3 +
net/ethernet/mac-platform.c | 151 ++++++++++++++++++++++++++++++++
9 files changed, 282 insertions(+), 22 deletions(-)
create mode 100644 include/net/mac-platform.h
create mode 100644 net/ethernet/mac-platform.c
From: Andy Green <hidden> Date: 2012-07-05 02:55:16
From: Andy Green <redacted>
This provides the board-specific device paths needed to get
the panda boardfile working with the mac-platform api.
On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding randomized MAC per-boot and consequent DHCP problems,
or in the case of wlan0 a MAC set by a firmware file in the rootfs
which unless customized yields a MAC of 00:00:00:00:00:00. No
official MAC is reserved for either network device even if you do
take the approach to customize the firmware file.
This gets sane, consistent MAC addresses on both devices which
should stand a good probability of differing between PandaBoards.
Signed-off-by: Andy Green <redacted>
---
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/board-omap4panda.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 31 insertions(+)
From: Andy Green <hidden> Date: 2012-07-05 02:55:18
From: Andy Green <redacted>
This is just provided for testing convenience, it has enough config
options to get Ethernet and WL12xx driver on PandaBoard / ES up
You should be able to reproduce something like this, with different
MAC addresses.
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 2e:20:3c:ea:46:01
inet addr:10.42.0.98 Bcast:10.42.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:31 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1647 (1.6 KB) TX bytes:5534 (5.5 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:100 (100.0 B) TX bytes:100 (100.0 B)
wlan0 Link encap:Ethernet HWaddr 2e:60:3c:ea:46:01
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Signed-off-by: Andy Green <redacted>
---
arch/arm/configs/omap2plus_defconfig | 35 ++++++++++++++--------------------
1 file changed, 14 insertions(+), 21 deletions(-)
@@ -212,23 +208,20 @@ CONFIG_JFFS2_RUBIN=y CONFIG_UBIFS_FS=y CONFIG_CRAMFS=y CONFIG_NFS_FS=y-CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y-CONFIG_PARTITION_ADVANCED=y CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_PRINTK_TIME=y CONFIG_MAGIC_SYSRQ=y-CONFIG_DEBUG_KERNEL=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_PROVE_LOCKING=y-CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y-# CONFIG_RCU_CPU_STALL_DETECTOR is not set+CONFIG_DEBUG_LL=y+CONFIG_EARLY_PRINTK=y CONFIG_SECURITY=y CONFIG_CRYPTO_MICHAEL_MIC=y # CONFIG_CRYPTO_ANSI_CPRNG is not set
From: Andy Green <hidden> Date: 2012-07-05 02:55:23
From: Andy Green <redacted>
This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
and the MAC that is needed to be assigned to the device when it appears.
This allows platform code to enforce valid, consistent MAC addresses on to
devices that have not been probed at boot-time, but due to being wired on the
board are always present at the same interface. It has been tested with USB
and SDIO probed devices.
Other parts of this series provide an OMAP API that computes a valid
locally administered MAC address from CPU ID bits that are unique for each
physical SoC, and register those against devices wired to the board.
This solves a longstanding problem in at least Panda case that there are no
reserved MACs for either onboard Ethernet nor onboard WLAN module, and without
this patch a randomized MAC is assigned to Ethernet and 00:00:00:00:00:00 or
0xdeadbeef is assigned as the WLAN MAC address. The series provides sane,
constant locally-administered MAC addresses that have a high probability of
differing between boards.
To make use of this safely you also need to make sure that any drivers that
may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
case) are loaded in a deterministic order.
At registration it makes a copy of the incoming data, so the data may be
__initdata or otherwise transitory. Registration can be called multiple times
so registrations from Device Tree and platform may be mixed.
Since it needs to be called quite early in boot and there is no lifecycle for
what it does, it could not be modular and is not a driver.
Via suggestions from Arnd Bergmann and Tony Lindgren (and Alan Cox for the
network notifier concept).
Cc: netdev at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Andy Green <redacted>
---
include/net/mac-platform.h | 39 +++++++++++
net/Kconfig | 5 +
net/ethernet/Makefile | 3 +
net/ethernet/mac-platform.c | 151 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 197 insertions(+), 1 deletion(-)
create mode 100644 include/net/mac-platform.h
create mode 100644 net/ethernet/mac-platform.c
@@ -335,9 +335,12 @@ source "net/caif/Kconfig"source"net/ceph/Kconfig"source"net/nfc/Kconfig"-endif# if NET+# used by board / dt platform to enforce MACs for Async-probed devices+configMAC_PLATFORM+bool+# Used by archs to tell that they support BPF_JITconfigHAVE_BPF_JITbool
From: Andy Green <hidden> Date: 2012-07-05 02:55:25
From: Andy Green <redacted>
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:20:3c:ea:46:01
for the ethernet device on my PandaBoard ES.
The MAC address space has space set aside for these kind of "locally
administered" MAC addresses, analogous to IPv4 10.x.x.x range, and this
patch marks the generated MAC addresses as such.
The patch leaves two bits allowing elaborating 4 different MACs from the
generated data.
Signed-off-by: Andy Green <redacted>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nicolas Pitre <redacted>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
---
arch/arm/mach-omap2/id.c | 39 +++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/include/mach/id.h | 1 +
2 files changed, 40 insertions(+)
@@ -530,3 +530,42 @@ void __init omap2_set_globals_tap(struct omap_globals *omap2_globals)elsetap_prod_id=0x0208;}++/*+*thisusestheuniqueper-cpuinfofromthecpufusessetatfactoryto+*generatea6-byteMACaddress.Twobitsinthegeneratedcodeareused+*toelaboratethegeneratedaddressintofour,soitcanbeusedonmultiple+*networkinterfaces.+*/++voidomap_die_id_to_ethernet_mac(u8*mac,intsubtype)+{+structomap_die_idodi;+u32tap=read_tap_reg(OMAP_TAP_IDCODE);++omap_get_die_id(&odi);++mac[0]=odi.id_2;+mac[1]=odi.id_2>>8;+mac[2]=odi.id_1;+mac[3]=odi.id_1>>8;+mac[4]=odi.id_1>>16;+mac[5]=odi.id_1>>24;++/* XOR other chip-specific data with ID */++tap^=odi.id_3;++mac[0]^=tap;+mac[1]^=tap>>8;+mac[2]^=tap>>16;+mac[3]^=tap>>24;++/* allow four MACs from this same basic data */++mac[1]=(mac[1]&~0xc0)|((subtype&3)<<6);++/* mark it as not multicast, and outside official 80211 MAC namespace */++mac[0]=(mac[0]&~1)|2;+}
From: Joe Perches <joe@perches.com> Date: 2012-07-05 03:12:47
On Thu, 2012-07-05 at 10:44 +0800, Andy Green wrote:
From: Andy Green <redacted>
This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
and the MAC that is needed to be assigned to the device when it appears.
The mac prefix is poor. I think eth_mac is better.
[]
From: Andy Green <hidden> Date: 2012-07-05 03:20:58
On 05/07/12 11:12, the mail apparently from Joe Perches included:
Thanks for the comments.
quoted
This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, "usb1/1-1/1-1.1/1-1.1:1.0")
and the MAC that is needed to be assigned to the device when it appears.
The mac prefix is poor. I think eth_mac is better.
From: Ben Hutchings <hidden> Date: 2012-07-06 22:40:38
On Thu, 2012-07-05 at 10:44 +0800, Andy Green wrote:
[...]
To make use of this safely you also need to make sure that any drivers that
may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
case) are loaded in a deterministic order.
[...]
This seems very restrictive... would it be practical to also allow a
driver name as a path component?
[...]
A kernel-doc summary is strictly limited to one line. The longer
explanation can go in a paragraph under the field descriptions.
+ * @device_path: device path name of network device
+ * @mac: MAC address to assign to network device matching device path
+ * @list: can be left uninitialized when passing from platform
+ */
+
+struct mac_platform {
+ char *device_path;
+ u8 mac[ETH_ALEN];
+ struct list_head list; /* unused in platform data usage */
+};
[...]
There are so many blank lines here, it's hard to see much code at once.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
Hi,
Le jeudi 05 juillet 2012 04:44:33, Andy Green a ?crit :
The following series adds some code to generate legal, locally administered
MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
net/ethernet taking care of accepting device path / MAC mapping
registrations and running a notifier to enforce the requested MAC when the
matching network device turns up.
This looks like something you can solve by user-space entirely. Expose the
OMAP4 CPU Die ID using a sysfs attribute, and let user-space manage the MAC
address pool.
If you tell me you want to use this for nfsroot booting, what prevents you
from using an initramfs, assign a valid MAC to your interface and switch over
your nfsroot once the interface setup is done?
On PandaBoard / ES, two devices have no board-level MAC either assigned by
the manufacturer or stored on the board, the last patch in the series adds
these device paths and gets them set when the network device is registered.
Lastly for convenient testing, there's a little patch on
omap2plus_defconfig that will get Ethernet and WLAN up on Pandaboard.
The patches are against today's linux-omap.
Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the
helper in net/ethernet.
---
Andy Green (4):
OMAP: add cpu id register to MAC address helper
NET ethernet introduce mac_platform helper
OMAP4 PANDA register ethernet and wlan for automatic mac allocation
config test config extending omap2plus with wl12xx etc
arch/arm/configs/omap2plus_defconfig | 35 +++----
arch/arm/mach-omap2/Kconfig | 1
arch/arm/mach-omap2/board-omap4panda.c | 30 ++++++
arch/arm/mach-omap2/id.c | 39 ++++++++
arch/arm/mach-omap2/include/mach/id.h | 1
include/net/mac-platform.h | 39 ++++++++
net/Kconfig | 5 +
net/ethernet/Makefile | 3 +
net/ethernet/mac-platform.c | 151
++++++++++++++++++++++++++++++++ 9 files changed, 282 insertions(+), 22
deletions(-)
create mode 100644 include/net/mac-platform.h
create mode 100644 net/ethernet/mac-platform.c
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andy Green (林安廸) <hidden> Date: 2012-07-10 12:59:12
On 10/07/12 20:37, the mail apparently from Florian Fainelli included:
Hi -
Le jeudi 05 juillet 2012 04:44:33, Andy Green a ?crit :
quoted
The following series adds some code to generate legal, locally administered
MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
net/ethernet taking care of accepting device path / MAC mapping
registrations and running a notifier to enforce the requested MAC when the
matching network device turns up.
This looks like something you can solve by user-space entirely. Expose the
That might seem so from a openwrt perspective, where you custom cook the
whole userland thing per-device, but it ain't so from a generic rootfs
perspective.
Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific
workarounds? And Panda is not the only device with this issue.
-Andy
From: Steven Rostedt <rostedt@goodmis.org> Date: 2012-07-10 13:08:53
On Tue, 2012-07-10 at 20:58 +0800, "Andy Green (???)" wrote:
On 10/07/12 20:37, the mail apparently from Florian Fainelli included:
Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific
workarounds? And Panda is not the only device with this issue.
Actually I think you just answered your own question ;-)
Anyway, I don't think an initrd solution is the best. Yeah, it's fine
for a work around, but then I need to go and screw with the initrd if it
doesn't have support for the board. If the network card already has a
MAC address, why should the kernel give it another *random* one?
This isn't a complex patch set, where the complexity should be put into
userspace. And it makes it very convenient for people that just want the
board to boot so they can test it. I'm not developing any SoC or BSP,
I'm just using it to make sure my kernel changes can also be implemented
for ARM.
-- Steve
Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific
workarounds? And Panda is not the only device with this issue.
Why should we crap all over the kernel for all these board specific
problems ? Userspace code is at least pageable and generally less
security critical.
So your argument from that point of view is bunk. There are tons and tons
of boards doing tons of horrible hacks. If we mangled the generic code
for all of them the result would be a complete unmanagable pile of turd.
The use of locally administered MAC addressing is policy. The helper
belongs in userspace as it's clearly part of what udev is supposed to be
doing via device notifications, instead of your custom mini kernel-udev
hack which is what you've basically created.
We've said no to lots of people (several a year). We've done so for good
reasons. Most of them had more taste than your hack too (ok except the Pi
which was even more broken)
You need a udev rule, one single tiddly udev rule, and perhaps to expose a
sysfs node somewhere if the required generation data is on the board.
Hardly stinking up the userspace is it.
That would also then fix any races with userspace trying to set the MAC,
it would remove the need for the helper. It will avoid encoding
ultra-crappy assumptions like
"To make use of this safely you also need to make sure that any drivers
that may compete for the bus ordinal you are using (eg, mUSB and ehci in
Panda case) are loaded in a deterministic order."
What are you going to do when speeding up booting by parallelising
more probes breaks this kind of garbage assumption ?
To be honest if Fedora needs to deal with an army of craptastic devices
whose vendors can't get a MAC address on the board then they probably
need a single common change to ifup so that if you ifup an interface that
has no MAC it generates a local one. Thats about 6 lines of userspace
code in the config scripts. It's also probably a good default end user
behaviour.
And if you have a real MAC but it's not loaded into the device you can
just shove it into the platform device.
End of problem.
Alan