Messages in this thread | | | Date | Wed, 2 Mar 2016 09:21:01 -0800 | Subject | Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver | From | Andrey Smirnov <> |
| |
On Wed, Mar 2, 2016 at 5:58 AM, Srinivas Kandagatla <srinivas.kandagatla@linaro.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
| |