linux-kernel - Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver

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: <20160309075958.GF30994@pengutronix.de>
Date:	Wed, 9 Mar 2016 08:59:58 +0100
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:	Andrey Smirnov <andrew.smirnov@...il.com>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	linux-kernel@...r.kernel.org, Trent Piepho <tpiepho@...etacorp.com>
Subject: Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver

On Tue, Mar 08, 2016 at 11:28:21PM +0100, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Mar 07, 2016 at 08:07:41PM -0800, Andrey Smirnov wrote:
> > >> >
> > >> > Patch itself looks simple. Before we review it further could you provide
> > >> > more details on the exact usecase or some background of this.
> > >>
> > >> The discussion on this topic originated on mailing list of Barebox
> > >> project(which borrows very heavily from Linux designs). Barebox
> > >> operates on two device tree blobs, one is used for its internal
> > >> initialization, whereas second one is passed to Linux kernel when
> > >> booting it. The problem I was trying to solve was to make possible to
> > >> specify in the first DT blob what data would be used for MAC address
> > >> fixup of the second DT blob(the one passed to Linux).
> > >>
> > >> My first approach was to implement a very limited DT code, however in
> > >> discussing it the consensus was that porting 'nvmem' subsystem from
> > >> the kernel and using for the same purpose would be a better approach.
> > >> First pass adoption of that subsystem revealed that there were two
> > >> use-cases that current design didn't allow us to handle:
> > >>
> > >> - Depending on the version i.MX SoC MAC address data stored in ROM
> > >> would have different layout so as a possible solution to that I
> > >> implemented "composite" driver(patch #3)
> > >>
> > >> - On i.MX28, part of the MAC address is hard-coded in
> > >> arch/arm/mach-mxs/mach-mxs.c and only a portion of it is read from
> > >> ROM, this patch in combination with the aforementioned one should
> > >> allow us to encode all needed info in DT.
> > >>
> > >> Ideally, since all of the above is as applicable to Linux as it is to
> > >> Barebox it would be good for BB not to invent its own custom 'nvmem'
> > >> flavor, so hence me trying to start a conversation about adding this
> > >> upstream.
> > >
> > > If the only use-case is to store the MAC address, why not using the
> > > local-mac-address property directly?
> > 
> > I don't think I understand what you mean, could you give me an example
> > of how I'd use local-mac-address property for that use case? AFAIK,
> > local-mac-address is just an array of bytes embedded into device tree,
> 
> Well, yeah, but the nvmem-blob is also just an array of bytes embedded
> into the DT, right?
> 
> > how would it get populated with data from OTP memory of SoC?
> 
> In the bootloader, or Linux, read the OTP, patch the DT to add that
> node, done.

This series is a try to put the information how the MAC address can be
found (might be board specific) into the DT to not have board specific
hacks in the kernel/bootloader.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |