All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alban <albeu@free.fr>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Alban <albeu@free.fr>,
	linux-kernel@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
	Moritz Fischer <moritz.fischer@ettus.com>,
	devicetree@vger.kernel.org, Richard Weinberger <richard@nod.at>,
	Marek Vasut <marek.vasut@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	linux-mtd@lists.infradead.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: 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
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/

  reply	other threads:[~2017-03-08 15:21 UTC|newest]

Thread overview: 32+ 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 ` Alban
2017-03-07  8:26 ` [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem Alban
2017-03-07  8:26   ` Alban
2017-03-07 21:01   ` Boris Brezillon
2017-03-07 21:01     ` Boris Brezillon
2017-03-08 15:20     ` Alban [this message]
2017-03-08 15:20       ` Alban
2017-03-08 16:25       ` Boris Brezillon
2017-03-08 16:25         ` Boris Brezillon
2017-03-10  3:17   ` Marek Vasut
2017-03-10  3:17     ` Marek Vasut
2017-03-10  4:06     ` Moritz Fischer
2017-03-10  4:06       ` Moritz Fischer
2017-03-10  4:52       ` Marek Vasut
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-15 19:41       ` Alban
2017-03-18 20:58       ` Rob Herring
2017-03-18 20:58         ` Rob Herring
2017-03-19 11:16         ` Alban
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
2017-03-07  8:26   ` Alban
2017-03-07 18:52   ` Boris Brezillon
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
2017-03-13  2:18     ` kernel test robot
2017-03-13  2:18     ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.