Hi,

Grant Likely writes:

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.

quoted

quoted

quoted

quoted

Currently I'm setting up the MAC address for our TX28 from the fuses
in the platform code passed via platform_data, but that will obviously
not work with DT.

Non-dt can also use my proposal, then you only need to pass the fixed part of
MAC via platfrom data, the left will be read by fec driver.

quoted

The correct way would probably be to pass the MAC from the bootloader
via a DT blob. But that would require all bootloaders to be updated
first to support DTS. :(

But uboot will face the same problem that can not define a valid MAC
in dts, did i undertand correctly?

quoted

An intermediate solution could be using OF_DEV_AUXDATA to pass a
platform_data struct that may contain a MAC address set up by the
platform code.

Yes, it's a way but i'm afraid will not get accepted by dt people.

The problem remains; where does the platform code get the MAC address
from?  The kernel has to devise it from *somewhere* and the best place
for that should be in the MAC driver itself.

The platform code knows how and where the MAC is stored on a specific
platform. The driver has no business in knowing platform details like
this. Thus only platform code (or the bootloader) can provide the MAC
to the driver.

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.


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 at karo-electronics.de
___________________________________________________________