On Mon, Mar 19, 2012 at 3:02 PM, Grant Likely [off-list ref] wrote:

On Mon, 19 Mar 2012 17:49:02 +0100, Lothar Wa?mann [off-list ref] wrote:

quoted

Hi,

Grant Likely writes:

quoted

On Mon, 19 Mar 2012 07:54:33 +0100, Lothar Wa?mann [off-list ref] wrote:

quoted

Grant Likely writes:

quoted

On Fri, 16 Mar 2012 11:01:35 +0800, Dong Aisheng [off-list ref] wrote:

quoted

On Thu, Mar 15, 2012 at 07:22:04PM +0800, Lothar Wa?mann wrote:

quoted

Dong Aisheng writes:

quoted

On Thu, Mar 15, 2012 at 02:53:29PM +0800, Lothar Wa?mann wrote:

Anyway there is no definite spec how the MAC address(es) are stored
in the fuse map. Thus reading the MAC from there is more or less
platform specific.

It's just provide one more option since there are customers storing the MAC
in the fuse map.

That should be straight forward to support; have a property that
specifies the method used for fetching/calculating the MAC.

Executable code stored inside a DT blob? ;)

I know you're joking here, but I'm going to answer seriously
anyway... Absolutely not. ?What I'm suggesting is a property that
specifies the method used to determine the mac address. ?Something
like (off the top of my head):

? ? local-mac-address = [01 02 03 00 00 00];
? ? local-mac-mask = [0xff 0xff 0xff 0 0 0];
? ? mac-encoding = "append-serial-number";

That still does not specify where the remaining part of the MAC is
stored and how it should be retrieved.

I'm suggesting that you define a string that means something specific;
that hopefully can be shared by multiple platforms. ?For example,
"append-serial-number" might mean start with the values selected by
AND of local-mac-address and local-mac-mask, and OR in the board's
serial number. ?You would need to define something that worked if this
was the solution you used.

I'm intend to Grant's this suggestion.
This can be shared by all other imx platforms which stores mac address in
fuse map and this is commonly used by customer.
Then we do not need keep writing repeat code for different platforms
via platform
data.

For Lothar's question, we can add a property fuse_mac_offset to indicate
read mac from fuse map and where to read it.
For how many bytes to read, we can calculate it from the local-mac-mask.
For example, local-mac-mask = [0xff 0xff 0xff 0 0 0], we can get the size
as 3 bypes.

Then we have three properties:
local-mac-address = [01 02 03 00 00 00];
local-mac-mask = [0xff 0xff 0xff 0 0 0];
fuse_mac_offset = <1>;

In fec driver, the final mac address can be got by:
local-mac-address & local-mac-mask | (read_fuse(1) & 0xffffff)

Lathar,
Do you think if this is ok?

quoted

quoted

Okay, if so then it would be wise to have a reliable function for the
MAC driver to call to lookup it's address as determined by platform
code. ?Alternately, the platform code can write the correct mac
address into the device tree node at init time (see
prom_update_property() and prom_add_property()).

That sounds good. Didn't know about those functions. That could be
used to mimic the current behaviour of supplying the MAC via
platform_data.

I'm okay with doing this; but make sure you remove the bogus
local-mac-address from the .dts file.

This is a backup solution to me if the above solution you suggested can not
work.

Regards
Dong Aisheng