linux-kernel - Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list

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]

Message-ID: <20180418153440.187ed16e@avionic-0020>
Date:   Wed, 18 Apr 2018 15:34:40 +0200
From:   Alban <albeu@...e.fr>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     Alban <albeu@...e.fr>, linux-kernel@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Richard Weinberger <richard@....at>,
        Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
        devicetree@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode
 for the cells list

On Wed, 18 Apr 2018 13:53:56 +0100
Srinivas Kandagatla <srinivas.kandagatla@...aro.org> wrote:

> On 18/04/18 13:32, Alban wrote:
> >> I was also suggesting you to use nvmem-cell subnode, but make it a
> >> proper nvmem provider device, rather than reusing its parent device.
> >>
> >> You would end up some thing like this in dt.
> >>
> >> flash@0 {
> >> 	#address-cells = <1>;
> >> 	#size-cells = <1>;
> >> 	compatible = "s25sl064a";
> >> 	reg = <0>;
> >>
> >> 	nvmem-cells {
> >> 		compatible = "mtd-nvmem";
> >> 		#address-cells = <1>;
> >> 		#size-cells = <1>;
> >>
> >> 		calibration: calib@404 {
> >> 			reg = <0x404 0x10>;
> >> 		};
> >> 	};
> >> };  
> > But the root cause is in the nvmem binding, this conflict could exists  
> No, the root cause is because of passing wrong device instance to nvmem 
> core. And trying to workaround is the actual issue.

The data is stored on the MTD, so the nvmem provider is the MTD device.
I don't think it is a good idea to have a virtual device in the DT to
accommodate the nvmem API.

> > with any device type, not just MTD. I don't understand why we would want
> > such workarounds instead of just fixing the problem once and for all.  
> AFAIU, This is not a workaround, this is how nvmem provider bindings are 
> and all providers should try to follow it.
> 
> I still do not understand what is the issue in making nvmem-cells node a 
> proper nvmem provider device?

It is doable, but beside making the code more complex, AFAIU that would
goes against DT best practice as no such device exists in the hardware.
The DT should only represent that this device contains data that can be
requested by a driver, and ideally in the same way for all kind of
storages.

Alban

Content of type "application/pgp-signature" skipped