Platform devices and device trees

Posted Jun 23, 2011 22:37 UTC (Thu) by glikely (subscriber, #39601)
In reply to: Platform devices and device trees by krisis
Parent article: Platform devices and device trees

Wouldn't that just set the MAC address to a fixed value for all of my boards? The hack is that I'm getting a unique MAC address for each of the boards by using the unique-per-cpu die ID, which I pull during board setup.

The model pretty much assumes that the DT data is complete and accurate by the time it is passed to the kernel. If you need to do machine-specific hacks, there is little recourse but but to have machine specific setup code. DT doesn't change the situation in that regard. If really necessary, there is a way to attach supplemental platform_data to devices registered from the DT, but it is discouraged.

However, the DT can be dynamically modified to squirt in the mac address either by the boot loader (U-Boot) or when the .dtb is installed on the board. You don't need to have a separate .dts for each board with a different MAC address.

(The code for this hack is in arch/arm/mach-omap2/board-devkit8000.c if anyone wants to have a look. It's the omap_dm9000_init function)

Nice. I have a devkit8000, but I could never get a modern kernel to boot on the thing.

Platform devices and device trees

Posted Jun 24, 2011 0:28 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

this is a common enough issue that it may be worth defining a 'magic' MAC address (all 0's??) and if you see that going through a list of steps to create a MAC address (ending with generate something random). Ideally each step on this list could fail cleanly so all such checks could be gathered into one 'I have no real MAC address, generate one' routine.

Platform devices and device trees

Posted Jun 24, 2011 18:47 UTC (Fri) by broonie (subscriber, #7078) [Link] (1 responses)

It's extremely common and the kernel is already doing stuff to handle the case where it can't get a MAC address at all. The issue here is not that there's no MAC address, it's that the MAC is being shipped in a non-standard location (eg, a bootloader variable) and we need a way to hand that value to the chip. Once the kernel has the data there's not much problem.

Platform devices and device trees

Posted Jun 24, 2011 22:17 UTC (Fri) by dlang (guest, #313) [Link]

in reading the post, it sounded to me like he had special code in the driver so that if there was no eeprom with the MAC address, he would generate it from the cpuid.

yes, it would be nice for the code to look in the device tree to see if there is a MAC address provided.

but if there isn't, he shouldn't have special case code in that one driver to calculate the MAC, he should call the general case code to handle the case where there is no MAC (and come to think of it, that general case code should probably be what is taught to look in the device tree for the MAC)