[RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0

[andy@warmcat.com (Andy Green)]

On 03/25/2011 08:13 PM, Somebody in the thread at some point said:

Hi -

> I very much like this approach.  I believed the ability to use the die
> ID to get a unique code was reasonable approach and that is why I
> didn't get an EEPROM put onto the BeagleBoard, though Gerald is
> looking at adding one on a future revision because the lack of one
> wasn't well received.  Minor questions below.

Great.  FWIW I think it'd be a lost opportunity to wire the EEPROM 
direct to the network device.  It's more flexible and powerful to regard 
the EEPROM as general "board identity storage", a way to bind 
information to the physical board.  Then you can stick any kind of 
information that you need to bind to the board in the same 25c device 
and in-kernel code can take care of discovering that data when needed on 
any subsystem that takes an interest.

> The use of the OMAP die id below makes this OMAP specific and the list
> referenced below of the devices to be referenced makes it Panda
> specific.  Is there a way to make the list board specific, but to make
> these functions that will be used across many OMAP platforms reusable?
>   I believe that this current code will result in a lot of
> cut-and-paste.  My preference is that this is accepted and that we
> make this more general when we add this to other OMAP platforms, but
> it'd be great to capture your suggestions on how to do so before those
> cut-and-paste patch sets start coming in.

Sure, I would be happy to put this stuff at OMAP platform layer for 
example if it makes sense to OMAP guys more generally.

> I just want to make sure I understand how this works.  When a new
> network device is added, if the device name matches one of the above
> listed device paths, then the die id based MAC id is applied.  This
> must be done via a device registration notifier as the registration is
> triggered when the device is detected.

That's right.  Arguably it would be better if there was a core API to 
register your board-specific uniqueness / entropy, and the drivers were 
able to use that instead of "random" ethernet address all in network 
layer.   But after wasting two weeks getting pointlessly beaten up on 
lkml largely on the question of how generic this issue is, I would 
rather restart somewhere specific where everyone can see the obvious 
benefit and if it's seen as more useful migrate it.

-Andy