From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Alban <albeu@free.fr>
Cc: linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Marek Vasut <marek.vasut@gmail.com>,
Richard Weinberger <richard@nod.at>,
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
devicetree@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list
Date: Tue, 1 May 2018 17:49:03 +0100 [thread overview]
Message-ID: <d30656d6-f17e-6ed0-251f-2b59d02cd202@linaro.org> (raw)
In-Reply-To: <20180418153440.187ed16e@avionic-0020>
On 18/04/18 14:34, Alban wrote:
> On Wed, 18 Apr 2018 13:53:56 +0100
> Srinivas Kandagatla <srinivas.kandagatla@linaro.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.
>
Yep, I agree! this is same issue if we make nvmem-cells a child of nvmem
provider too.
However, I would like to see this moving forward.
I can think of one possible solution here, which is, adding
"nvmem-mtd-cell" or "nvmem-cell" compatible string to each cell. The
problem you mentioned regarding #address-cells and #size-cells with
provider need to be addressed in nvmem core.
Currently nvmem core only support offsets of 32 bits, if you are
expecting a 64 bit offsets then we should add that as a feature to nvmem
core.
nvmem core as it is today should work fine with 32 bit offsets for mtd
cases.
what do you think?
thanks,
srini
next prev parent reply other threads:[~2018-05-01 16:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-24 23:24 [PATCH v3 0/3] mtd: Add support for reading MTD devices via the nvmem API Alban Bedel
2018-03-24 23:24 ` [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list Alban Bedel
2018-04-16 21:04 ` Rob Herring
2018-04-17 12:31 ` Alban
2018-04-17 12:54 ` Srinivas Kandagatla
2018-04-17 14:54 ` Alban
2018-04-17 15:44 ` Srinivas Kandagatla
2018-04-17 16:00 ` Alban
2018-04-18 11:41 ` Alban
2018-04-18 12:12 ` Srinivas Kandagatla
2018-04-18 12:32 ` Alban
2018-04-18 12:53 ` Srinivas Kandagatla
2018-04-18 13:34 ` Alban
2018-05-01 16:49 ` Srinivas Kandagatla [this message]
2018-06-07 16:41 ` Alban
2018-06-07 17:03 ` Srinivas Kandagatla
2018-06-08 10:59 ` Alban
2018-06-08 11:34 ` Srinivas Kandagatla
2018-06-08 17:07 ` Alban
2018-06-10 10:32 ` Srinivas Kandagatla
2018-06-10 11:36 ` Alban
2018-06-10 13:28 ` Srinivas Kandagatla
2018-03-24 23:24 ` [PATCH v3 2/3] doc: bindings: Add bindings documentation for mtd nvmem Alban Bedel
2018-04-16 21:08 ` Rob Herring
2018-04-17 12:44 ` Alban
2018-03-24 23:24 ` [PATCH v3 3/3] mtd: Add support for reading MTD devices via the nvmem API Alban Bedel
2019-04-18 13:36 ` Reading MAC addresses with NVMEM under MTD partition [Was: Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list] Petr Štetiar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d30656d6-f17e-6ed0-251f-2b59d02cd202@linaro.org \
--to=srinivas.kandagatla@linaro.org \
--cc=albeu@free.fr \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@wedev4u.fr \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=mark.rutland@arm.com \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).