[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8c4b48ad-e99e-030a-a4ee-b6df0fa59c79@linaro.org>
Date: Tue, 17 Apr 2018 16:44:01 +0100
From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To: Alban <albeu@...e.fr>
Cc: 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
Thanks for explaining,
On 17/04/18 15:54, Alban wrote:
> This will not only allow reading the calibration data from nvmem, but
> will also create a partition on the MTD device, which is not acceptable.
> With my proposed binding this would become:
>
> flash@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "s25sl064a";
> reg = <0>;
>
> nvmem-cells {
> compatible = "nvmem-cells";
> #address-cells = <1>;
> #address-cells = <1>;
>
> calibration: calib@404 {
> reg = <0x404 0x10>;
> };
> };
Why can't we make nvmem-cells node a nvmem provider in this case?
Which should work!
--srini
> };
>
> Which would work fine as the MTD code will ignore the nvmem-cells
> subnode thanks to its compatible string.
Powered by blists - more mailing lists