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

Message-ID: <CAA+hA=R8hLZMyRASRim28MNzX4jyE3nsaJ3DPzgxDtUmqtH62w@mail.gmail.com>
Date:	Tue, 20 Mar 2012 05:49:06 -0700
From:	Dong Aisheng <dongas86@...il.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Lothar Waßmann <LW@...o-electronics.de>,
	Dong Aisheng <aisheng.dong@...escale.com>,
	"vinod.koul@...ux.intel.com" <vinod.koul@...ux.intel.com>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	Guo Shawn-R65073 <r65073@...escale.com>,
	"rdunlap@...otime.net" <rdunlap@...otime.net>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>,
	"cjb@...top.org" <cjb@...top.org>,
	Dong Aisheng-B29396 <B29396@...escale.com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v1 1/5] ARM: imx28: add basic dt support

On Mon, Mar 19, 2012 at 3:02 PM, Grant Likely <grant.likely@...retlab.ca> wrote:
> On Mon, 19 Mar 2012 17:49:02 +0100, Lothar Waßmann <LW@...O-electronics.de> wrote:
>> 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.
>
> 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.
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?

>> > 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.
>
This is a backup solution to me if the above solution you suggested can not
work.

Regards
Dong Aisheng
--
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/