Hi,

Dong Aisheng writes:

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

quoted

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.

That's not really enough. The format (big-endian vs. little-endian)
may also differ. But it's not really necessary, if the solution with
prom_update_property() works, since then platform code has full
control over the MAC.

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?

No. IMO the FEC driver itself should not read any fuses.
Reading fuses is a SoC specific thing and the FEC driver should not
depend on the idiosyncrasies of some SoC wrt. anything else but the
implementation of the FEC itself.


Lothar Waßmann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________