On 03/25/2011 11:49 AM, Somebody in the thread at some point said:
On Thursday 24 March 2011, Andy Green wrote:
Introduce a generic helper function that can set a MAC address using
data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:40:70:f0:12:06
for the ethernet device on my Panda.
Note that this patch requires the fix patch for CPU ID register
indexes previously posted to linux-omap, otherwise the CPU ID is
misread on Panda by the existing function to do it. This patch
is already on linux-omap.
"OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430"
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=b235e007831dbf57710e59cd4a120e2f374eecb9
Signed-off-by: Andy Green<andy.green@xxxxxxxxxx>
Acked-by: Arnd Bergmann<arnd@xxxxxxxx>
Thanks.
TI folks: While this is a working solution, I still think it would
be good to get an officially sanctioned method that allows the creation
of a IEEE 802 MAC address in a range assigned to TI instead of using
an address from the locally administered range.
Is that something that can be done?
Having a proper MAC from IEEE assigned for each interface is of course
ideal.
But even if that happened today though, on Panda there is no "board
identity storage" to put the reserved MAC addresses in to bind it to the
physical board. If you try to manage them on SD Card, you have the
problem of dealing with correct MAC addresses needing putting there
again every time it is nuked. So it doesn't in itself help in the Panda
case.
David Anders mentioned yesterday that for next OMAP board, he probably
puts a general board identity EEPROM where one could stash MACs. This
kind of API can be extended to query the EEPROM at device-register-time
and fetch the MAC instead of compute it. So I think we go in a
reasonable direction even when it is possible to get assigned MACs.
-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
