From: Alban <albeu@free.fr>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Moritz Fischer <moritz.fischer@ettus.com>,
devicetree@vger.kernel.org, Richard Weinberger <richard@nod.at>,
linux-kernel@vger.kernel.org, Marek Vasut <marek.vasut@gmail.com>,
Rob Herring <robh+dt@kernel.org>, Alban <albeu@free.fr>,
linux-mtd@lists.infradead.org,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Maxime Ripard <maxime.ripard@free-electrons.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Cyrille Pitchen <cyrille.pitchen@atmel.com>
Subject: Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem
Date: Wed, 8 Mar 2017 16:20:01 +0100 [thread overview]
Message-ID: <20170308162001.2b7e2304@avionic-0020> (raw)
In-Reply-To: <20170307220107.03436537@bbrezillon>
[-- Attachment #1.1: Type: text/plain, Size: 5086 bytes --]
On Tue, 7 Mar 2017 22:01:07 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> On Tue, 7 Mar 2017 09:26:03 +0100
> Alban <albeu@free.fr> wrote:
>
> > Config data for drivers, like MAC addresses, is often stored in MTD.
> > Add a binding that define how such data storage can be represented in
> > device tree.
> >
> > Signed-off-by: Alban <albeu@free.fr>
> > ---
> > Changelog:
> > v2: * Added a "Required properties" section with the nvmem-provider
> > property
> > ---
> > .../devicetree/bindings/nvmem/mtd-nvmem.txt | 33 ++++++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> >
> > diff --git a/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > new file mode 100644
> > index 0000000..8ed25e6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > @@ -0,0 +1,33 @@
> > += NVMEM in MTD =
> > +
> > +Config data for drivers, like MAC addresses, is often stored in MTD.
> > +This binding define how such data storage can be represented in device tree.
> > +
> > +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
> > +property to their node.
>
> If everyone agrees that this is actually needed, then it should
> definitely go in the nvmem binding doc, and we should patch all nvmem
> providers to define this property (even if we keep supporting nodes
> that are not defining it). I'm not fully convinced yet, but I might be
> wrong.
I really like to hear what the DT people think about this.
> I also think we should take the "nvmem under flash node without partitions"
> into account now, or at least have a clear plan on how we want to represent
> it.
>
> Something like that?
Yes, but with the following extras:
> flash {
nvmem-provider;
> partitions {
> part@X {
> nvmem {
compatible = "nvmem-cells";
> #address-cells = <1>;
> #size-cells = <1>;
>
> cell@Y {
> };
> };
> };
> };
>
> nvmem {
compatible = "nvmem-cells";
> #address-cells = <1>;
> #size-cells = <1>;
>
> cell@X {
> };
> };
> };
>
> Note that patching nvmem core to support the subnode case should be
> pretty easy (see below).
This shouldn't be needed as nothing would change for the NVMEM devices,
what could be added is a check for the "nvmem-provider" property.
To support the proposed binding we would only need a minor change to
of_nvmem_cell_get():
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 408b521ee520..6231ea27c9f4 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -444,6 +444,10 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
if (!config->dev)
return ERR_PTR(-EINVAL);
+ if (config->dev->of_node &&
+ !of_property_read_bool(config->dev->of_node, "nvmem-provider"))
+ return ERR_PTR(-ENODEV);
+
nvmem = kzalloc(sizeof(*nvmem), GFP_KERNEL);
if (!nvmem)
return ERR_PTR(-ENOMEM);
@@ -777,6 +781,15 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
if (!nvmem_np)
return ERR_PTR(-EINVAL);
+ /* handle the new cell binding */
+ if (of_device_is_compatible(nvmem_np, "nvmem-cells")) {
+ nvmem_np = of_get_next_parent(cell_np);
+ if (!nvmem_np)
+ return ERR_PTR(-EINVAL);
+ if (!of_property_read_bool(nvmem_np, "nvmem-provider"))
+ return ERR_PTR(-ENODEV);
+ }
+
nvmem = __nvmem_device_get(nvmem_np, NULL, NULL);
if (IS_ERR(nvmem))
return ERR_CAST(nvmem);
> --->8---
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 408b521ee520..507c6190505b 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -465,7 +465,7 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
> nvmem->priv = config->priv;
> nvmem->reg_read = config->reg_read;
> nvmem->reg_write = config->reg_write;
> - np = config->dev->of_node;
> + np = config->of_node ? : config->dev->of_node;
> nvmem->dev.of_node = np;
> dev_set_name(&nvmem->dev, "%s%d",
> config->name ? : "nvmem", config->id);
> diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
> index cd93416d762e..ec2f5116d62d 100644
> --- a/include/linux/nvmem-provider.h
> +++ b/include/linux/nvmem-provider.h
> @@ -21,6 +21,7 @@ typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset,
>
> struct nvmem_config {
> struct device *dev;
> + struct device_node *of_node;
> const char *name;
> int id;
> struct module *owner;
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2017-03-08 15:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-07 8:26 [PATCH v2 0/2] mtd: Add support for reading MTD devices via the nvmem API Alban
2017-03-07 8:26 ` [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem Alban
2017-03-07 21:01 ` Boris Brezillon
2017-03-08 15:20 ` Alban [this message]
2017-03-08 16:25 ` Boris Brezillon
[not found] ` <1488875164-30440-2-git-send-email-albeu-GANU6spQydw@public.gmane.org>
2017-03-10 3:17 ` Marek Vasut
[not found] ` <9f54978c-6d61-cf2c-fb2d-f5ef2af19e0f-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-03-10 4:06 ` Moritz Fischer
[not found] ` <CAAtXAHc34fG_TZbHrRp=oB_e=-o18zDesT73YSEx1Tr5ZE0oSw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-03-10 4:52 ` Marek Vasut
2017-03-10 6:38 ` Maxime Ripard
2017-03-10 7:28 ` Marek Vasut
2017-03-15 17:24 ` Rob Herring
2017-03-15 19:41 ` Alban
2017-03-18 20:58 ` Rob Herring
2017-03-19 11:16 ` Alban
2017-03-07 8:26 ` [PATCH v2 2/2] mtd: Add support for reading MTD devices via the nvmem API Alban
[not found] ` <1488875164-30440-3-git-send-email-albeu-GANU6spQydw@public.gmane.org>
2017-03-07 18:52 ` Boris Brezillon
2017-03-13 2:18 ` [lkp-robot] [mtd] 88eb23fa5e: kernel_BUG_at_fs/sysfs/file.c kernel test robot
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=20170308162001.2b7e2304@avionic-0020 \
--to=albeu@free.fr \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@atmel.com \
--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=maxime.ripard@free-electrons.com \
--cc=moritz.fischer@ettus.com \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=srinivas.kandagatla@linaro.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).