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

From: Maxime Ripard
Date: Mon Mar 07 2016 - 03:18:53 EST


Hi,

On Wed, Mar 02, 2016 at 09:21:01AM -0800, Andrey Smirnov wrote:
> On Wed, Mar 2, 2016 at 5:58 AM, Srinivas Kandagatla
> <srinivas.kandagatla@xxxxxxxxxx> 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.

If the only use-case is to store the MAC address, why not using the
local-mac-address property directly?

Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Attachment: signature.asc
Description: Digital signature