linux-kernel - Re: [RESEND RFC 3/3] nvmem: Add 'nvmem-composite' 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Mar 2016 11:26:28 +0000
From:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:	Andrey Smirnov <andrew.smirnov@...il.com>
Cc:	linux-kernel@...r.kernel.org, maxime.ripard@...e-electrons.com,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Trent Piepho <tpiepho@...etacorp.com>
Subject: Re: [RESEND RFC 3/3] nvmem: Add 'nvmem-composite' driver



On 02/03/16 18:33, Andrey Smirnov wrote:
> On Wed, Mar 2, 2016 at 5:59 AM, Srinivas Kandagatla
> <srinivas.kandagatla@...aro.org> wrote:
>>
>> On 01/03/16 16:59, Andrey Smirnov wrote:
>>>
>>> Add 'nvmem-composite' driver which allows to combine multiple chunks of
>>> various NVMEM cells into a single continuous NVMEM device.
>>
>>
>> My plan on this feature was add support inside the nvmem_cell_get itself,
>> this makes the nvmem bindings more inline with bindings like pinctrl.
>> Also I still want to keep nvmem simple as it can.
>
> That's perfectly fine with me, I can change my patch to do that. My
> thinking on implementing it as a standalone module was that this seems
> to be a very niche functionality which not a lot of people would use,
> so the code would be a part of your kernel only if you directly use
> this feature.
>
>>
>> DT would look something like this.
>>
>> nvmem-provider-a {
>>          cell_a {
>>                  reg = <0 2>;
>>          };
>> };
>>
>> nvmem-provider-b {
>>          cell_b: cell_c {
>>                  reg = <0 1>;
>>          };
>> };
>>
>> nvmem-provider-c {
>>          cell_c: cell_c {
>>                  reg = <3 2>;
>>          }
>> };
>>
>> a-node {
>>          nvmem-cells = <&cell_a &cell_b &cell_c>
>>          nvmem-cell-names = "some-data";
>> };
>>
>
> It's not very clear to me, possibly to my DT ignorance, how this would
> handle the case of multiple variables. Say we have
>
> a-node {
>           nvmem-cells = <&cell_a &cell_b>, ????;
>           nvmem-cell-names = "some-data", "more-data";
> };
>
Should have replied you long back :-)
> and I want "more-data" to reference only one phandle, how would this be handled?
>
yes this would fail.

The device tree compiler would concatenate all the cells and we have no 
means to know where did "more-data" starts.

sounds like composite driver is the way forward.


--srini
> Another minor nitpick about his is that if one's goal is to just
> byteswap already defined nvmem_cell:
>    - N, where N is the length of the variable, new nvmem cells would
> have to be defined
>    - All of them would have to use absolute address within the nvmem
> provided, instead of referencing a byte relative to the position of
> pre-defined cell
>
> Thanks,
> Andrey
>