Thread (4 messages) 4 messages, 4 authors, 2012-03-21

Re: [PATCH v1 1/5] ARM: imx28: add basic dt support

From: Grant Likely <hidden>
Date: 2012-03-19 22:02:24
Also in: linux-arm-kernel, linux-mmc

On Mon, 19 Mar 2012 17:49:02 +0100, Lothar Wa��mann [off-list ref] wrote:
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.
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.

g.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help