Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver
From: Maxime Ripard
Date: Tue Mar 08 2016 - 17:28:35 EST
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
It's already what U-Boot does here for example (the source of ethaddr
being dependent of the platform):
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
Description: Digital signature