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:	Wed, 2 Mar 2016 10:33:38 -0800
From:	Andrey Smirnov <andrew.smirnov@...il.com>
To:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
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 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";
};

and I want "more-data" to reference only one phandle, how would this be handled?

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

Powered by blists - more mailing lists