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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20322.61501.432329.124466@ipc1.ka-ro>
Date:	Fri, 16 Mar 2012 08:48:13 +0100
From:	Lothar Waßmann <LW@...O-electronics.de>
To:	Dong Aisheng <aisheng.dong@...escale.com>
Cc:	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>,
	Grant Likely <grant.likely@...retlab.ca>,
	"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,

Dong Aisheng writes:
> On Thu, Mar 15, 2012 at 07:22:04PM +0800, Lothar Waßmann wrote:
[...]
> My proposal is only set the fixed part(first two octets) in board dts file,
> each board knows it's value, and read the left 4 octets from OCOTP dynamically.
>
The OUI part is three bytes, not two! But anyway, since there is no
definition on how the MAC has to be stored in OCOTP there is no way
for the driver to know how to interpret the data it may read from
there.

> > 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.
> 
How would the driver know, whether and how the customer has stored the
MAC address in OCOTP? E.g. on our TX28 modules the FULL MAC is stored
in the CUSTOM registers in OCOTP.

> > 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.
> 
Reading the MAC from fuses is platform sepcific. The driver cannot
know how the MAC is stored there and needs to rely on platform
specific code to do this.

> > 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?
> 
That's why I said "would require all bootloaders to be updated first
to support DTS".


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/