In message 1defaf580707121538y65db81c9y748f14b9a62ea31b@mail.gmail.com you wrote:
When I submitted the macb ethernet driver, which works on both avr32 and at91sam926x devices, for inclusion in the LInux kernel, I was told to remove the mac address from the platform data. This was because ARM
So far this is most probably correct.
relied on u-boot initializing the mac address of all ethernet controllers before booting Linux, so AVR32 should do the same as well.
This is definitely not correct. U-Boot's position about this is very clear, and has been for a long time. This is actually a FAQ, please look it up.
So I did this and added some code to the avr32 board setup to initialize the mac address registers as a temporary measure until I could be sure that u-boot did in fact always set up the mac address on all interfaces.
It will never do that.
Now, it seems like the situation is: a) Other architectures rely on mac registers being initialized by u-boot as well. b) This is not how things are supposed to work.
b)
I'd be happy to go back to passing mac addresses through the tagged list (in fact, u-boot never stopped doing that on avr32) but this needs to be resolved on ARM before I can change the driver.
The thing is that the ARM folks don't want o see MAC addresses in ATAGs either. Don't ask me why - if they use this mechanism for passing h/w related information around that would seem the most logical approach to me, too. But they don't want it.
And we are as stubborn as them: we don't want to initialize h/w we didn't use.
<asbestos> The Right Thing (TM) would of course be to get rid of all this ATAGs stuff on ARM and use a proper device tree there, too, like the PowerPC folks have been doing for such a long time. And on MIPS and all the other systems, too. </asbestos>
[He, I'm leaving for vacation, so I won't suffer from the fires of the flame war I just started :-) ]
Best regards,
Wolfgang Denk