Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values

Introduce a generic helper function that can generate a valid MAC address using data from the OMAP unique CPU ID register.

arch/arm/mach-omap2/id.c +29 -0

@@ -530,3 +530,42 @@ void __init omap2_set_globals_tap(struct omap_globals *omap2_globals)
 	else
 		tap_prod_id = 0x0208;
 }
+
+/*
+ * this uses the unique per-cpu info from the cpu fuses set at factory to
+ * generate a 6-byte MAC address.  Two bits in the generated code are used
+ * to elaborate the generated address into four, so it can be used on multiple
+ * network interfaces.
+ */
+
+void omap2_die_id_to_ethernet_mac(u8 *mac, int subtype)
+{
+	struct omap_die_id odi;
+	u32 tap = 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;

Quoted 3 lines

Introduce a generic helper function that can generate a valid MAC address using data from the OMAP unique CPU ID register.

...

Quoted 40 lines

arch/arm/mach-omap2/id.c +34 -0

@@ -530,3 +530,42 @@ void __init omap2_set_globals_tap(struct omap_globals *omap2_globals)
  	else
  		tap_prod_id = 0x0208;
  }
+
+/*
+ * this uses the unique per-cpu info from the cpu fuses set at factory to
+ * generate a 6-byte MAC address.  Two bits in the generated code are used
+ * to elaborate the generated address into four, so it can be used on multiple
+ * network interfaces.
+ */
+
+void omap2_die_id_to_ethernet_mac(u8 *mac, int subtype)
+{
+	struct omap_die_id odi;
+	u32 tap = 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);

arch/arm/mach-omap2/id.c void __init omap2_set_globals_tap(struct omap_globals *omap2_globals) · line 571

Quoted 5 lines

arch/arm/mach-omap2/id.c +5 -0

+
+	/* mark it as not multicast, and outside official 80211 MAC namespace */
+
+	mac[0] = (mac[0] & ~1) | 2;
+}

Let's just make this omap_die_id_to_ethernet_mac, no need to keep the omap2 naming there as this should not conflict with any omap1 stuff.

arch/arm/mach-omap2/devices.c +23 -0

+static int omap_panda_netdev_event(struct notifier_block *this,
+                                               unsigned long event, void *ptr)
+{
+       struct net_device *dev = ptr;
+       struct sockaddr sa;
+       int n;
+
+       if (event != NETDEV_REGISTER)
+               return NOTIFY_DONE;
+
+       n = omap_device_path_need_mac(dev->dev.parent);
+       if (n < 0)
+               return NOTIFY_DONE;
+
+       sa.sa_family = dev->type;
+       omap2_die_id_to_ethernet_mac(sa.sa_data, n);
+       dev->netdev_ops->ndo_set_mac_address(dev, &sa);
+
+       return NOTIFY_DONE;
+}
+
+static struct notifier_block omap_panda_netdev_notifier = {
+       .notifier_call = omap_panda_netdev_event,

Quoted 29 lines

arch/arm/mach-omap2/devices.c +29 -0

+static int omap_panda_netdev_event(struct notifier_block *this,
+                                               unsigned long event, void *ptr)
+{
+       struct net_device *dev = ptr;
+       struct sockaddr sa;
+       int n;
+
+       if (event != NETDEV_REGISTER)
+               return NOTIFY_DONE;
+
+       n = omap_device_path_need_mac(dev->dev.parent);
+       if (n < 0)
+               return NOTIFY_DONE;
+
+       sa.sa_family = dev->type;
+       omap2_die_id_to_ethernet_mac(sa.sa_data, n);
+       dev->netdev_ops->ndo_set_mac_address(dev, &sa);
+
+       return NOTIFY_DONE;
+}
+
+static struct notifier_block omap_panda_netdev_notifier = {
+       .notifier_call = omap_panda_netdev_event,
+       .priority = 1,
+};
+
+int omap_register_mac_device_fixup_paths(const char * const *paths, int count)
+{
+       mac_device_fixup_paths = paths;

arch/arm/mach-omap2/devices.c static void omap_init_vout(void) · line 717

Quoted 4 lines

arch/arm/mach-omap2/devices.c +4 -0

+       count_mac_device_fixup_paths = count;
+
+       return register_netdevice_notifier(&omap_panda_netdev_notifier);
+}

The omap_panda_netdev_event and omap_panda_netdev_notifier symbols should probably lose the "panda_" part of their names, because they are now located in a common file and are not panda specific any more.

From: Andy Green <[email protected]>

This exposes a new API in devices.c that lets a board register a list of device paths representing network devices that have no arrangements for their MAC address to be set by the board.

It watches network device registrations via a notifier and gives the devices requiring them a synthetic - but constant for a given board - MAC address immediately.

arch/arm/mach-omap2/devices.c +35 -0

+	const char *path;
+	int count = count_mac_device_fixup_paths;
+	const char *p;
+	int len;
+	struct device *devn;
+
+	while (count--) {
+
+		p = *try + strlen(*try);
+		devn = dev;
+
+		while (devn) {
+
+			path = dev_name(devn);
+			len = strlen(path);
+
+			if ((p - *try) < len) {
+				devn = NULL;
+				continue;
+			}
+
+			p -= len;
+
+			if (strncmp(path, p, len)) {
+				devn = NULL;
+				continue;
+			}
+
+			devn = devn->parent;
+			if (p == *try)
+				return count;
+
+			if (devn != NULL && (p - *try) < 2)
+				devn = NULL;
+

arch/arm/mach-omap2/devices.c +15 -0

+static int omap_panda_netdev_event(struct notifier_block *this,
+						unsigned long event, void *ptr)
+{
+	struct net_device *dev = ptr;
+	struct sockaddr sa;
+	int n;
+
+	if (event != NETDEV_REGISTER)
+		return NOTIFY_DONE;
+
+	n = omap_device_path_need_mac(dev->dev.parent);
+	if (n < 0)
+		return NOTIFY_DONE;
+
+	sa.sa_family = dev->type;

Quoted 9 lines

From: Andy Green <[email protected]>

This exposes a new API in devices.c that lets a board register a list of device paths representing network devices that have no arrangements for their MAC address to be set by the board.

It watches network device registrations via a notifier and gives the devices requiring them a synthetic - but constant for a given board - MAC address immediately.

...

arch/arm/mach-omap2/devices.c line 46

Quoted 8 lines

arch/arm/mach-omap2/devices.c +2 -0

@@ -39,6 +42,9 @@
  #define L3_MODULES_MAX_LEN 12
  #define L3_MODULES 3
 
+static const char * const *mac_device_fixup_paths;
+int count_mac_device_fixup_paths;

This too should be static it seems to me. Or just make the paths array NULL terminated to get rid of the count.

Quoted 7 lines

arch/arm/mach-omap2/devices.c +0 -0

  static int __init omap3_l3_init(void)
  {
  	struct omap_hwmod *oh;

@@ -627,6 +633,89 @@ static void omap_init_vout(void)
  static inline void omap_init_vout(void) {}
  #endif
 

arch/arm/mach-omap2/devices.c static void omap_init_vout(void) · line 638

Quoted 3 lines

arch/arm/mach-omap2/devices.c +3 -0

+static int omap_device_path_need_mac(struct device *dev)
+{
+	const char **try = (const char **)mac_device_fixup_paths;

This cast you should be able to remove by setting the types right to start with?

Quoted 41 lines

arch/arm/mach-omap2/devices.c +41 -0

+	const char *path;
+	int count = count_mac_device_fixup_paths;
+	const char *p;
+	int len;
+	struct device *devn;
+
+	while (count--) {
+
+		p = *try + strlen(*try);
+		devn = dev;
+
+		while (devn) {
+
+			path = dev_name(devn);
+			len = strlen(path);
+
+			if ((p - *try) < len) {
+				devn = NULL;
+				continue;
+			}
+
+			p -= len;
+
+			if (strncmp(path, p, len)) {
+				devn = NULL;
+				continue;
+			}
+
+			devn = devn->parent;
+			if (p == *try)
+				return count;
+
+			if (devn != NULL && (p - *try) < 2)
+				devn = NULL;
+
+			p--;
+			if (devn != NULL && *p != '/')
+				devn = NULL;
+		}
+
+		try++;

arch/arm/mach-omap2/devices.c static void omap_init_vout(void) · line 683

Quoted 4 lines

arch/arm/mach-omap2/devices.c +4 -0

+	}
+
+	return -ENOENT;
+}

I don't quite like having this device parsing code here. This should probably be a generic helper function somewhere under drivers. I would assume other SoCs could use it too?

Quoted 15 lines

arch/arm/mach-omap2/devices.c +15 -0

+static int omap_panda_netdev_event(struct notifier_block *this,
+						unsigned long event, void *ptr)
+{
+	struct net_device *dev = ptr;
+	struct sockaddr sa;
+	int n;
+
+	if (event != NETDEV_REGISTER)
+		return NOTIFY_DONE;
+
+	n = omap_device_path_need_mac(dev->dev.parent);
+	if (n < 0)
+		return NOTIFY_DONE;
+
+	sa.sa_family = dev->type;

arch/arm/mach-omap2/devices.c static void omap_init_vout(void) · line 709

Quoted 10 lines

arch/arm/mach-omap2/devices.c +10 -0

+	omap2_die_id_to_ethernet_mac(sa.sa_data, n);
+	dev->netdev_ops->ndo_set_mac_address(dev, &sa);
+
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block omap_panda_netdev_notifier = {
+	.notifier_call = omap_panda_netdev_event,
+	.priority = 1,
+};

This is a bit similar to platform data callback functions that we are trying to get rid of. And as the question "how do we replace platform data callback functions" is still open for things like this, few questions come to mind that should be discussed:

1. How is this a better solution to passing the generated mac address in platform data to the driver?

2. Is this really how we want to pass the board generated mac addresses and other dynamically generated data to the drivers that are device tree based?

3. What about mac address in board-generic.c when booting panda with device tree?

Also, what happens if the user has set the mac address and you replugs the cable or device? Do we now overwrite it? Might be worth checking that this follows the standard behaviour..

On 06/29/12 17:40, the mail apparently from Tony Lindgren included:

Quoted 6 lines

This is a bit similar to platform data callback functions that we are trying to get rid of. And as the question "how do we replace platform data callback functions" is still open for things like this, few questions come to mind that should be discussed:

Quoted 2 lines

1. How is this a better solution to passing the generated mac address in platform data to the driver?

Well, I initially did this over a year ago as a generic way to pass platform data to devices that are appearing through deferred or async probing, like USB bus and SDIO bus. It was not understood what the goal was by the people looking after those subsystems.

Quoted 3 lines

2. Is this really how we want to pass the board generated mac addresses and other dynamically generated data to the drivers that are device tree based?

The issue is that both these busses have an async probe, in the case of USB stack the maintainer was not interested last year in adding platform data. Maybe it changed but that's my understanding.

Quoted 2 lines

3. What about mac address in board-generic.c when booting panda with device tree?

I don't mind adapting it for that case.

Quoted 3 lines

Also, what happens if the user has set the mac address and you replugs the cable or device? Do we now overwrite it? Might be worth checking that this follows the standard behaviour..

This is only useful for devices that are soldered on your board, and have deterministic "device paths" as is the case with Panda Ethernet and Wlan module that both benefit from this treatment. If you mean pulling the RJ45 cable, it doesn't change anything about the MAC I can confirm.

Quoted 7 lines · Andy Green

Quoted 3 lines

2. Is this really how we want to pass the board generated mac addresses and other dynamically generated data to the drivers that are device tree based?

The issue is that both these busses have an async probe, in the case of USB stack the maintainer was not interested last year in adding platform data. Maybe it changed but that's my understanding.

OK, I'd like to hear Arnds comments on the #2 above too as this is a more generic issue.

Quoted 4 lines

Quoted 2 lines

3. What about mac address in board-generic.c when booting panda with device tree?

I don't mind adapting it for that case.

Just to try to think about some alternatives, how about something like
this: This all could be a driver called soft-mac or something that does what your patches are doing. Except then it would be completely generic and would be able to take device names and mac addresses from platform data or from devicetree.

Quoted 9 lines · Tony Lindgren

Quoted 7 lines · Andy Green

Quoted 3 lines

2. Is this really how we want to pass the board generated mac addresses and other dynamically generated data to the drivers that are device tree based?

The issue is that both these busses have an async probe, in the case of USB stack the maintainer was not interested last year in adding platform data. Maybe it changed but that's my understanding.

Quoted 2 lines

OK, I'd like to hear Arnds comments on the #2 above too as this is a more generic issue.

In case we have a device tree, we should just be using the USB binding to find the specific device node, and add the property there. Then the device driver can use of_get_mac_address() on the usb device itself.

I'm not sure what it takes to add the link for the device node in the usb probing code, but my feeling is that it's not too hard.

Right now, USB is probed entirely without DT, so the patch is about the best we can do.

Quoted 10 lines

Quoted 4 lines

Quoted 2 lines

3. What about mac address in board-generic.c when booting panda with device tree?

I don't mind adapting it for that case.

Just to try to think about some alternatives, how about something like
this: This all could be a driver called soft-mac or something that does what your patches are doing. Except then it would be completely generic and would be able to take device names and mac addresses from platform data or from devicetree.

That driver would be completely generic to all platforms, but be very specific to finding the mac address of a device, as opposed to other properties.

I suspect that if we do that, we will still need a way to bind a device_node to a usb device for the purpose of finding other properties, such as external regulators or clocks that are connected to a hardwired USB device.

Normally USB tends to just work because the device is expected to be hot-pluggable anyway. If the USB device is soldered to the board, the hardware designers can take some shortcuts

Quoted 10 lines · Tony Lindgren

Quoted 9 lines · Andy Green

Quoted 7 lines

Quoted 3 lines

2. Is this really how we want to pass the board generated mac addresses and other dynamically generated data to the drivers that are device tree based?

The issue is that both these busses have an async probe, in the case of USB stack the maintainer was not interested last year in adding platform data. Maybe it changed but that's my understanding.

Quoted 6 lines

Quoted 2 lines

OK, I'd like to hear Arnds comments on the #2 above too as this is a more generic issue.

In case we have a device tree, we should just be using the USB binding to find the specific device node, and add the property there. Then the device driver can use of_get_mac_address() on the usb device itself.

But would you generate the mac address then in the bootloader already?

Quoted 5 lines

I'm not sure what it takes to add the link for the device node in the usb probing code, but my feeling is that it's not too hard.

Right now, USB is probed entirely without DT, so the patch is about the best we can do.

Right, but that still assumes a static mac from the bootloader unless we do a generic driver as below? Or do you have some other ideas?

Quoted 10 lines · Arnd Bergmann

Quoted 9 lines · Tony Lindgren

Quoted 7 lines · Andy Green

Quoted 3 lines

2. Is this really how we want to pass the board generated mac addresses and other dynamically generated data to the drivers that are device tree based?

The issue is that both these busses have an async probe, in the case of USB stack the maintainer was not interested last year in adding platform data. Maybe it changed but that's my understanding.

Quoted 6 lines

Quoted 2 lines

OK, I'd like to hear Arnds comments on the #2 above too as this is a more generic issue.

In case we have a device tree, we should just be using the USB binding to find the specific device node, and add the property there. Then the device driver can use of_get_mac_address() on the usb device itself.

But would you generate the mac address then in the bootloader already?

Quoted 5 lines

I'm not sure what it takes to add the link for the device node in the usb probing code, but my feeling is that it's not too hard.

Right now, USB is probed entirely without DT, so the patch is about the best we can do.

Right, but that still assumes a static mac from the bootloader unless we do a generic driver as below? Or do you have some other ideas?

Quoted 3 lines

Normally USB tends to just work because the device is expected to be hot-pluggable anyway. If the USB device is soldered to the board, the hardware designers can take some shortcuts

But that too still depends on the order of loading of the multiple host controller modules. Beagle has both EHCI and musb.

Quoted 11 lines · Tony Lindgren

Quoted 10 lines · Arnd Bergmann

Quoted 9 lines · Tony Lindgren

Quoted 7 lines · Andy Green

Quoted 3 lines

2. Is this really how we want to pass the board generated mac addresses and other dynamically generated data to the drivers that are device tree based?

The issue is that both these busses have an async probe, in the case of USB stack the maintainer was not interested last year in adding platform data. Maybe it changed but that's my understanding.

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

OK, I'd like to hear Arnds comments on the #2 above too as this is a more generic issue.

In case we have a device tree, we should just be using the USB binding to find the specific device node, and add the property there. Then the device driver can use of_get_mac_address() on the usb device itself.

But would you generate the mac address then in the bootloader already?

Good question. I think we definitely want to have the option of overiding the mac address from the boot loader or a predefined device tree blob.

IMHO the precedence should be

a) mac-address property from DT if set
b) hardcoded address from device EEPROM if present
c) platform-provided address, if supported by platform
d) random_ether_addr()

A lot of devices already provide the mac address in the device tree, wherever that comes from. Ideally that would always be possible but never necessary.

Quoted 6 lines

Quoted 5 lines

I'm not sure what it takes to add the link for the device node in the usb probing code, but my feeling is that it's not too hard.

Right now, USB is probed entirely without DT, so the patch is about the best we can do.

Quoted 2 lines

Right, but that still assumes a static mac from the bootloader unless we do a generic driver as below? Or do you have some other ideas?

The boot loader could theoretically have the same algorithm that Andy's patch implements, unless it is configured to something else by the user. In many cases, you don't want the boot loader to be that smart, but sometimes it is the right solution.

Quoted 6 lines

Quoted 3 lines

Normally USB tends to just work because the device is expected to be hot-pluggable anyway. If the USB device is soldered to the board, the hardware designers can take some shortcuts

But that too still depends on the order of loading of the multiple host controller modules. Beagle has both EHCI and musb.

In the device tree, we can uniquely identify the USB hosts, that is not a problem here. The problem exists only if you base your path on the linux specific name for the devices.
It's definitely ugly to rely on that, but I think we can actually guarantee that it's stable as long as we enforce in the Kconfig/Kbuild that the controller that has the ethernet device is always built-in on Panda and comes before the other one if

both are built-in. I would much prefer not to have to rely on those things, but I believe it is actually guaranteed at the moment for the cases that matter. While you could have both controllers as loadable modules and load them in reverse order that would also imply that you cannot actually boot from the network, so you know that you have a file system on which you can set the mac address of the device using udev, before you start using networking.

Quoted 13 lines

A lot of devices already provide the mac address in the device tree, wherever that comes from. Ideally that would always be possible but never necessary.

Quoted 8 lines

Quoted 5 lines

I'm not sure what it takes to add the link for the device node in the usb probing code, but my feeling is that it's not too hard.

Right now, USB is probed entirely without DT, so the patch is about the best we can do.

Right, but that still assumes a static mac from the bootloader unless we do a generic driver as below? Or do you have some other ideas?

Quoted 4 lines

The boot loader could theoretically have the same algorithm that Andy's patch implements, unless it is configured to something else by the user. In many cases, you don't want the boot loader to be that smart, but sometimes it is the right solution.

OK that would mean bootloader modifying the .dtb then.

Quoted 7 lines

In the device tree, we can uniquely identify the USB hosts, that is not a problem here. The problem exists only if you base your path on the linux specific name for the devices.
It's definitely ugly to rely on that, but I think we can actually guarantee that it's stable as long as we enforce in the Kconfig/Kbuild that the controller that has the ethernet device is always built-in on Panda and comes before the other one if

Quoted 8 lines

both are built-in. I would much prefer not to have to rely on those things, but I believe it is actually guaranteed at the moment for the cases that matter. While you could have both controllers as loadable modules and load them in reverse order that would also imply that you cannot actually boot from the network, so you know that you have a file system on which you can set the mac address of the device using udev, before you start using networking.

OK. So how about we do the following:

1. Make Andy's notifier part into a generic mac notifier driver that can take platform data for the driver name mac address pair. Devicetree binding could be added as needed.

2. Pass the Panda mac information as platform data to this driver for now with a comment on the usb path naming being potentially wrong in the loadable modules case.

3. Add devicetree support to the driver once the USB binding is available.

That will make my life much easier as then I'm not stuck with more legacy code to deal with ;) Also writing the driver part should be trivial as all the code is there already.

Quoted 7 lines · Tony Lindgren

OK. So how about we do the following:

1. Make Andy's notifier part into a generic mac notifier driver that can take platform data for the driver name mac address pair. Devicetree binding could be added as needed.

I don't think the devicetree bindign should be part of that driver but instead should go into the individual network device drivers, otherwise it sounds ok to me. Obviously, this still needs buy-in from the networking people.

Quoted 3 lines

2. Pass the Panda mac information as platform data to this driver for now with a comment on the usb path naming being potentially wrong in the loadable modules case.

IMHO code outside of the platform driver world would be more appropriate here. It's not actually a platform device because it's more of an abstract concept to define a mac address than physical hardware.

A new file with a single global function in net/ethernet/ that you can use to register a callback sounds like the easiest approach to me.

Quoted 2 lines

3. Add devicetree support to the driver once the USB binding is available.

Here you mean the smsc95xx driver, not the new code, right?

Quoted 8 lines

Quoted 3 lines

2. Pass the Panda mac information as platform data to this driver for now with a comment on the usb path naming being potentially wrong in the loadable modules case.

IMHO code outside of the platform driver world would be more appropriate here. It's not actually a platform device because it's more of an abstract concept to define a mac address than physical hardware.

Well we still need to also pass the mac address generated by the SoC specific kernel init code. It seems that platform data would be the obvious way to pass that. Or do you have some other way in mind for that?

Quoted 9 lines · Tony Lindgren

Quoted 8 lines

Quoted 3 lines

2. Pass the Panda mac information as platform data to this driver for now with a comment on the usb path naming being potentially wrong in the loadable modules case.

IMHO code outside of the platform driver world would be more appropriate here. It's not actually a platform device because it's more of an abstract concept to define a mac address than physical hardware.

Quoted 4 lines

Well we still need to also pass the mac address generated by the SoC specific kernel init code. It seems that platform data would be the obvious way to pass that. Or do you have some other way in mind for that?

My point is that for platform data you need a platform device of some sort, but this new piece of infrastructure does not look like it should be a device.

I think a reasonable interface would be something as simple as

void register_eth_mac_fixup(const char *path, const u8 *mac);

Instead of registering a device from the platform, we just call this function, and leave the code built-in.

Quoted 11 lines · Andy Green

Quoted 7 lines

Quoted 3 lines

2. Is this really how we want to pass the board generated mac addresses and other dynamically generated data to the drivers that are device tree based?

The issue is that both these busses have an async probe, in the case of USB stack the maintainer was not interested last year in adding platform data. Maybe it changed but that's my understanding.

OK, I'd like to hear Arnds comments on the #2 above too as this is a more generic issue.

In case we have a device tree, we should just be using the USB binding to find the specific device node, and add the property there. Then the device driver can use of_get_mac_address() on the usb device itself.

I'm not sure what it takes to add the link for the device node in the usb probing code, but my feeling is that it's not too hard.

Right now, USB is probed entirely without DT, so the patch is about the best we can do.

Quoted 10 lines

Quoted 4 lines

Quoted 2 lines

3. What about mac address in board-generic.c when booting panda with device tree?

I don't mind adapting it for that case.

Just to try to think about some alternatives, how about something like
this: This all could be a driver called soft-mac or something that does what your patches are doing. Except then it would be completely generic and would be able to take device names and mac addresses from platform data or from devicetree.

That driver would be completely generic to all platforms, but be very specific to finding the mac address of a device, as opposed to other properties.

I suspect that if we do that, we will still need a way to bind a device_node to a usb device for the purpose of finding other properties, such as external regulators or clocks that are connected to a hardwired USB device.

Normally USB tends to just work because the device is expected to be hot-pluggable anyway. If the USB device is soldered to the board, the hardware designers can take some shortcuts

On 06/29/12 21:45, the mail apparently from Arnd Bergmann included:

Quoted 8 lines · Tony Lindgren

In case we have a device tree, we should just be using the USB binding to find the specific device node, and add the property there. Then the device driver can use of_get_mac_address() on the usb device itself.

I'm not sure what it takes to add the link for the device node in the usb probing code, but my feeling is that it's not too hard.

Quoted 2 lines

Right now, USB is probed entirely without DT, so the patch is about the best we can do.

Yes none of this was really hard the problem with more generic approach was getting comprehension and not auto-reject at the other subsystems. To be fair USB is USB and DT is Arm-specific issue.

Quoted 15 lines

Quoted 10 lines

Quoted 4 lines

Quoted 2 lines

3. What about mac address in board-generic.c when booting panda with device tree?

I don't mind adapting it for that case.

Just to try to think about some alternatives, how about something like
this: This all could be a driver called soft-mac or something that does what your patches are doing. Except then it would be completely generic and would be able to take device names and mac addresses from platform data or from devicetree.

That driver would be completely generic to all platforms, but be very specific to finding the mac address of a device, as opposed to other properties.

Quoted 4 lines

I suspect that if we do that, we will still need a way to bind a device_node to a usb device for the purpose of finding other properties, such as external regulators or clocks that are connected to a hardwired USB device.

There's no standardized exposure of logical regulators over USB afaik so you won't be able to 'find' them without a VID:PID -bound specific driver that already knew about them.

Quoted 3 lines

Normally USB tends to just work because the device is expected to be hot-pluggable anyway. If the USB device is soldered to the board, the hardware designers can take some shortcuts

Tony's point about modularized host drivers coming in random order seems to be a fair one. We don't build ehci modular so we don't care about it but from maintainer pov it's a legit issue.

arch/arm/mach-omap2/board-omap4panda.c +0 -0

@@ -486,6 +486,15 @@ static void omap4_panda_init_rev(void)
 	}

The following series adds some code to generate legal, locally administered MAC addresses from OMAP4 CPU Die ID fuse data, and then adds an api to devices.c allowing board files to register device paths for network devices that wish to use them.

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.

The patches are against today's linux-omap.