Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1352608

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

Show all headers | View raw

>> >
>> > 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,
how would it get populated with data from OTP memory of SoC?

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-03-07 09:20 +0100
  Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Andrey Smirnov <andrew.smirnov@gmail.com> - 2016-03-08 05:10 +0100
    Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-03-08 23:30 +0100
      Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Andrey Smirnov <andrew.smirnov@gmail.com> - 2016-03-08 23:50 +0100
        Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Trent Piepho <tpiepho@kymetacorp.com> - 2016-03-09 00:40 +0100
          Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-03-09 11:20 +0100
            Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Trent Piepho <tpiepho@kymetacorp.com> - 2016-03-09 21:00 +0100
        Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-03-09 11:00 +0100
          Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Andrey Smirnov <andrew.smirnov@gmail.com> - 2016-03-09 18:10 +0100
      Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver Sascha Hauer <s.hauer@pengutronix.de> - 2016-03-09 09:10 +0100

csiph-web