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]

Date:	Wed, 2 Mar 2016 09:21:01 -0800
From:	Andrey Smirnov <andrew.smirnov@...il.com>
To:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:	linux-kernel@...r.kernel.org, maxime.ripard@...e-electrons.com,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Trent Piepho <tpiepho@...etacorp.com>
Subject: Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver

On Wed, Mar 2, 2016 at 5:58 AM, Srinivas Kandagatla
<srinivas.kandagatla@...aro.org> wrote:
>
>
> On 01/03/16 16:59, Andrey Smirnov wrote:
>>
>> Add 'nvmem-blob' driver, which allows to access device tree embedded
>> data via NVMEM subsystem API.
>
>
> 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.

Hope this clarifies things a bit.

>
>
> Incase you resend the patches, could you split the dt bindings into separate
> patch and add dt guys in to the loop, They would have different opinion on
> adding dummy stuff into DT itself.

Will do.

Thanks,
Andrey