All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alban <albeu@free.fr>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Aban Bedel <albeu@free.fr>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-mtd@lists.infradead.org,
	Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	Richard Weinberger <richard@nod.at>,
	Marek Vasut <marek.vasut@gmail.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Moritz Fischer <moritz.fischer@ettus.com>
Subject: Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem
Date: Fri, 3 Mar 2017 13:22:13 +0100	[thread overview]
Message-ID: <20170303132213.513d82dc@tock> (raw)
In-Reply-To: <6d5ef869-a1d5-c8d2-847d-1c7aaafa74cf@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

On Fri, 3 Mar 2017 11:27:34 +0000
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> wrote:

> On 02/03/17 19:50, Alban wrote:
> > Add the binding to expose MTD partitions as nvmem providers.  
> 
> It would be nice to see more description of this patch, explaining the 
> real use case.

I'll try, writing good documentation is not my strong point :/

> >
> > Signed-off-by: Alban <albeu@free.fr>
> > ---
> >  .../devicetree/bindings/nvmem/mtd-nvmem.txt        | 29 ++++++++++++++++++++++
> >  1 file changed, 29 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..47602f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > @@ -0,0 +1,29 @@
> > += NVMEM in MTD =
> > +
> > +Config data for drivers is often stored in MTD devices. This binding
> > +define how such data can be represented in device tree.
> > +
> > +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`  
> We should prefix this property with "mtd" to make it more explicit that 
> this is specific to mtd devices.
> 
> May be we should put this under "Required Properties" section, marking 
> it as mandatory for mtd nvmem providers.

I agree it should be required, but I would not make it MTD specific. In
fact I would suggest making it mandatory for all nvmem providers. That
would be inline with 'interrupt-controller' and all the other properties
used to indicate the capabilities of devices.

Alban

[-- 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: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org,
	Moritz Fischer <moritz.fischer@ettus.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Richard Weinberger <richard@nod.at>,
	linux-kernel@vger.kernel.org, Marek Vasut <marek.vasut@gmail.com>,
	Rob Herring <robh+dt@kernel.org>, Aban Bedel <albeu@free.fr>,
	linux-mtd@lists.infradead.org,
	Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Maxime Ripard <maxime.ripard@free-electrons.com>
Subject: Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem
Date: Fri, 3 Mar 2017 13:22:13 +0100	[thread overview]
Message-ID: <20170303132213.513d82dc@tock> (raw)
In-Reply-To: <6d5ef869-a1d5-c8d2-847d-1c7aaafa74cf@linaro.org>


[-- Attachment #1.1: Type: text/plain, Size: 1686 bytes --]

On Fri, 3 Mar 2017 11:27:34 +0000
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> wrote:

> On 02/03/17 19:50, Alban wrote:
> > Add the binding to expose MTD partitions as nvmem providers.  
> 
> It would be nice to see more description of this patch, explaining the 
> real use case.

I'll try, writing good documentation is not my strong point :/

> >
> > Signed-off-by: Alban <albeu@free.fr>
> > ---
> >  .../devicetree/bindings/nvmem/mtd-nvmem.txt        | 29 ++++++++++++++++++++++
> >  1 file changed, 29 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..47602f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > @@ -0,0 +1,29 @@
> > += NVMEM in MTD =
> > +
> > +Config data for drivers is often stored in MTD devices. This binding
> > +define how such data can be represented in device tree.
> > +
> > +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`  
> We should prefix this property with "mtd" to make it more explicit that 
> this is specific to mtd devices.
> 
> May be we should put this under "Required Properties" section, marking 
> it as mandatory for mtd nvmem providers.

I agree it should be required, but I would not make it MTD specific. In
fact I would suggest making it mandatory for all nvmem providers. That
would be inline with 'interrupt-controller' and all the other properties
used to indicate the capabilities of devices.

Alban

[-- 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/

  parent reply	other threads:[~2017-03-03 12:23 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-02 19:50 [PATCH 0/3] mtd: Add support for reading MTD devices via the nvmem API Alban
2017-03-02 19:50 ` Alban
2017-03-02 19:50 ` [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem Alban
2017-03-02 19:50   ` Alban
2017-03-02 20:22   ` Boris Brezillon
2017-03-02 20:22     ` Boris Brezillon
2017-03-03 12:17     ` Alban
2017-03-03 12:17       ` Alban
2017-03-03 12:37       ` Boris Brezillon
2017-03-03 12:37         ` Boris Brezillon
2017-03-03 13:12         ` Alban
2017-03-03 11:27   ` Srinivas Kandagatla
2017-03-03 11:27     ` Srinivas Kandagatla
2017-03-03 12:19     ` Boris Brezillon
2017-03-03 12:19       ` Boris Brezillon
2017-03-03 12:22     ` Alban [this message]
2017-03-03 12:22       ` Alban
2017-03-02 19:50 ` [PATCH 2/3] mtd: Add support for reading MTD devices via the nvmem API Alban
2017-03-02 19:50   ` Alban
2017-03-02 21:18   ` Boris Brezillon
2017-03-02 21:18     ` Boris Brezillon
2017-03-03 12:36     ` Alban
2017-03-03 12:36       ` Alban
2017-03-03 13:36       ` Boris Brezillon
2017-03-03 13:36         ` Boris Brezillon
2017-03-03 13:57         ` Alban
2017-03-03 13:57           ` Alban
2017-03-03 14:11           ` Boris Brezillon
2017-03-03 14:11             ` Boris Brezillon
2017-03-03 22:21             ` Richard Weinberger
2017-03-03 22:21               ` Richard Weinberger
2017-03-06 17:21               ` Alban
2017-03-06 17:21                 ` Alban
2017-03-06 19:03                 ` Richard Weinberger
2017-03-06 19:03                   ` Richard Weinberger
2017-03-06 21:02                   ` Boris Brezillon
2017-03-06 21:02                     ` Boris Brezillon
2017-03-03 11:23   ` Srinivas Kandagatla
2017-03-03 11:23     ` Srinivas Kandagatla
2017-03-03 12:34     ` Boris Brezillon
2017-03-03 12:34       ` Boris Brezillon
2017-03-03 13:30       ` Alban
2017-03-03 14:03         ` Boris Brezillon
2017-03-03 14:03           ` Boris Brezillon
2017-03-02 19:50 ` [PATCH 3/3] nvmem: core: Allow allocating several anonymous nvmem devices Alban
2017-03-02 19:50   ` Alban
2017-03-02 20:03   ` Boris Brezillon
2017-03-02 20:03     ` Boris Brezillon
2017-03-03  1:50     ` Moritz Fischer
2017-03-03  1:50       ` Moritz Fischer
2017-03-03 10:08   ` Srinivas Kandagatla
2017-03-03 10:08     ` Srinivas Kandagatla

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=20170303132213.513d82dc@tock \
    --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.