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:	Tue, 8 Mar 2016 14:46:52 -0800
From:	Andrey Smirnov <andrew.smirnov@...il.com>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	linux-kernel@...r.kernel.org,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Trent Piepho <tpiepho@...etacorp.com>
Subject: Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver

>>
>> 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?

One is accessible via "nvmem" API and the other one isn't.

>
>> 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
> node, done.

No, it's not really "done", because if you read my previous messages,
"read the OTP, patch the DT" is exactly the problem I am trying to
solve. The overall goal is to be able to read a certain "nvmem" cell
and patch DT with that data as MAC address, however in it's current
incarnation "nvmem" doesn't have provisions to make cells that are
just combination of other cells (patch #3) and to embed certain data
in DT and then access it as "nvmem" cell (patch #2)