Linaro Linux

Bug #622429
Comment #15

Comment 15 for bug 622429

Revision history for this message

warmcat (andy-warmcat) wrote on 2011-02-22:

#15

Here's a summary of a discussion of this bug status between Loic, Nicolas and myself last night.

Board-specific code can't "override the default device name" in any nice way because on Panda, the ethernet PHY is not a platform_device that we can control by sending it flags in its platform_data set in the board specific file.

Instead, it's a USB device connected to a USB host port that is discovered and enumerated independent of any board-specific code. Further, because it's a USB network device its driver support for deciding this name is in the shared usbnet.c file used by all the USB network devices like this. There's a comment in usbnet.c on this code explicitly saying that if the user wants to force the name he can do it from userspace.

The reason usbnet.c forces usb%d in this case is because we do not set any fixed MAC address for the PHY, and the EEPROM the vendor could have connected to the PHY to set the MAC is absent too. The vendor never allocated any IEEE802 MAC Namespace address for the board then. Therefore there is no choice but to use a "local namespace" MAC address which has b1 set on the first octet; all randomized MACs have this bit set so they won't conflict with any MAC address from the official namespace which has b1 clear. When usbnet.c sees b1 set it goes down the usb%d path. Because no official MAC address has been paid for with these boards, in fact there is no solution involving being able to clear b1 in the MAC address and work with the existing logic.

Currently, the new random MAC on each boot really sucks because it means a new dhcp lease every boot and then a different IP.

It would be possible to solve this entirely in userspace because udev can rename the interface and Nicolas proposed using the SD card unique ID, available at "cat /sys/bus/mmc/devices/mmc0*/serial" as the LSBs of a randomized MAC so it is consistent on each boot, something that is best done in a udev or initscript. If the udev magic can be sent to udev upstream so all distros can do it, that would be pretty OK since it can provide a good spread of MAC addresses that don't change per boot.

The two ways to approach this in kernel I can think of are 1) propose a new generic scheme for providing platform_data for independently probed / enumerated USB stuff along the lines of SPI / I2C; or 2) add support for kernel commandline tokens in usbnet.c allowing override of naming for devices found on specific bus paths, eg, usbnet.forceifname=usb,1-1.1:1.0,eth but it seems to me this may be less welcome for the USB people to hear upstream than the udev people in the userspace case.

Here's a summary of a discussion of this bug status between Loic, Nicolas and myself last night.

Instead, it's a USB device connected to a USB host port that is discovered and enumerated independent of any board-specific code.  Further, because it's a USB network device its driver support for deciding this name is in the shared usbnet.c file used by all the USB network devices like this.  There's a comment in usbnet.c on this code explicitly saying that if the user wants to force the name he can do it from userspace.

The reason usbnet.c forces usb%d in this case is because we do not set any fixed MAC address for the PHY, and the EEPROM the vendor could have connected to the PHY to set the MAC is absent too.  The vendor never allocated any IEEE802 MAC Namespace address for the board then.  Therefore there is no choice but to use a "local namespace" MAC address which has b1 set on the first octet; all randomized MACs have this bit set so they won't conflict with any MAC address from the official namespace which has b1 clear.  When usbnet.c sees b1 set it goes down the usb%d path.  Because no official MAC address has been paid for with these boards, in fact there is no solution involving being able to clear b1 in the MAC address and work with the existing logic.

Currently, the new random MAC on each boot really sucks because it means a new dhcp lease every boot and then a different IP.

It would be possible to solve this entirely in userspace because udev can rename the interface and Nicolas proposed using the SD card unique ID, available at "cat /sys/bus/mmc/devices/mmc0*/serial" as the LSBs of a randomized MAC so it is consistent on each boot, something that is best done in a udev or initscript.  If the udev magic can be sent to udev upstream so all distros can do it, that would be pretty OK since it can provide a good spread of MAC addresses that don't change per boot.

The two ways to approach this in kernel I can think of  are 1) propose a new generic scheme for providing platform_data for independently probed / enumerated USB stuff along the lines of SPI / I2C; or 2) add support for kernel commandline tokens in usbnet.c allowing override of naming for devices found on specific bus paths, eg, usbnet.forceifname=usb,1-1.1:1.0,eth  but it seems to me this may be less welcome for the USB people to hear upstream than the udev people in the userspace case.