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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20327.25470.723875.916422@ipc1.ka-ro>
Date:	Mon, 19 Mar 2012 17:49:02 +0100
From:	Lothar Waßmann <LW@...O-electronics.de>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Dong Aisheng <aisheng.dong@...escale.com>,
	Dong Aisheng-B29396 <B29396@...escale.com>,
	"s.hauer\@pengutronix.de" <s.hauer@...gutronix.de>,
	Guo Shawn-R65073 <r65073@...escale.com>,
	"vinod.koul\@linux.intel.com" <vinod.koul@...ux.intel.com>,
	"devicetree-discuss\@lists.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-mmc\@vger.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"rob.herring\@calxeda.com" <rob.herring@...xeda.com>,
	"rdunlap\@xenotime.net" <rdunlap@...otime.net>,
	"kernel\@pengutronix.de" <kernel@...gutronix.de>,
	"cjb\@laptop.org" <cjb@...top.org>,
	"linux-arm-kernel\@lists.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v1 1/5] ARM: imx28: add basic dt support

Hi,

Grant Likely writes:
> On Mon, 19 Mar 2012 07:54:33 +0100, Lothar Waßmann <LW@...O-electronics.de> wrote:
> > Grant Likely writes:
> > > On Fri, 16 Mar 2012 11:01:35 +0800, Dong Aisheng <aisheng.dong@...escale.com> wrote:
> > > > On Thu, Mar 15, 2012 at 07:22:04PM +0800, Lothar Waßmann wrote:
> > > > > Dong Aisheng writes:
> > > > > > 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.

> > > > > 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.
> > > > 
> > > > > 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?
> > > > 
> > > > > 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@...o-electronics.de
___________________________________________________________
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/