LKML Archive on lore.kernel.org
 help / Atom feed
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Boris Brezillon <boris.brezillon@bootlin.com>, Alban <albeu@free.fr>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
	Jonathan Corbet <corbet@lwn.net>, Sekhar Nori <nsekhar@ti.com>,
	Kevin Hilman <khilman@kernel.org>,
	Russell King <linux@armlinux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	"David S . Miller" <davem@davemloft.net>,
	Naren <naren.kernel@gmail.com>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Lukas Wunner <lukas@wunner.de>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>,
	Sven Van Asbroeck <svendev@arcx.com>,
	Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh@kernel.org>,
	David Lechner <david@lechnology.com>,
	Andrew Lunn <andrew@lunn.ch>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org,
	linux-mtd@lists.infradead.org, linux-omap@vger.kernel.org,
	netdev@vger.kernel.org,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API
Date: Mon, 20 Aug 2018 11:43:34 +0100
Message-ID: <5b8c30b8-41e1-d59e-542b-fef6c6469ff0@linaro.org> (raw)
In-Reply-To: <20180819184609.6dcdbb9a@bbrezillon>

Thanks Boris, for looking into this in more detail.

On 19/08/18 17:46, Boris Brezillon wrote:
> On Sun, 19 Aug 2018 13:31:06 +0200
> Alban <albeu@free.fr> wrote:
> 
>> On Fri, 17 Aug 2018 18:27:20 +0200
>> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
>>
>>> Hi Bartosz,
>>>
>>> On Fri, 10 Aug 2018 10:05:03 +0200
>>> Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>    
>>>> From: Alban Bedel <albeu@free.fr>
>>>>
>>>> Allow drivers that use the nvmem API to read data stored on MTD devices.
>>>> For this the mtd devices are registered as read-only NVMEM providers.
>>>>
>>>> Signed-off-by: Alban Bedel <albeu@free.fr>
>>>> [Bartosz:
>>>>    - use the managed variant of nvmem_register(),
>>>>    - set the nvmem name]
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>
>>> What happened to the 2 other patches of Alban's series? I'd really
>>> like the DT case to be handled/agreed on in the same patchset, but
>>> IIRC, Alban and Srinivas disagreed on how this should be represented.
>>> I hope this time we'll come to an agreement, because the MTD <-> NVMEM
>>> glue has been floating around for quite some time...
>>
>> These other patches were to fix what I consider a fundamental flaw in
>> the generic NVMEM bindings, however we couldn't agree on this point.
>> Bartosz later contacted me to take over this series and I suggested to
>> just change the MTD NVMEM binding to use a compatible string on the
>> NVMEM cells as an alternative solution to fix the clash with the old
>> style MTD partition.
>>
>> However all this has no impact on the code needed to add NVMEM support
>> to MTD, so the above patch didn't change at all.
> 
> It does have an impact on the supported binding though.
> nvmem->dev.of_node is automatically assigned to mtd->dev.of_node, which
> means people will be able to define their NVMEM cells directly under
> the MTD device and reference them from other nodes (even if it's not
> documented), and as you said, it conflict with the old MTD partition
> bindings. So we'd better agree on this binding before merging this
> patch.
> 

Yes, I agree with you!

> I see several options:
> 
> 1/ provide a way to tell the NVMEM framework not to use parent->of_node
>     even if it's != NULL. This way we really don't support defining
>     NVMEM cells in the DT, and also don't support referencing the nvmem
>     device using a phandle.
> 
Other options look much better than this one!

> 2/ define a new binding where all nvmem-cells are placed in an
>     "nvmem" subnode (just like we have this "partitions" subnode for
>     partitions), and then add a config->of_node field so that the
>     nvmem provider can explicitly specify the DT node representing the
>     nvmem device. We'll also need to set this field to ERR_PTR(-ENOENT)
>     in case this node does not exist so that the nvmem framework knows
>     that it should not assign nvmem->dev.of_node to parent->of_node
> 
This one looks promising, One Question though..

Do we expect that there would be nvmem cells in any of the partitions?
or
nvmem cell are only valid for unpartioned area?

Am sure that the nvmem cells would be in multiple partitions, Is it okay 
to have some parts of partition to be in a separate subnode?

I would like this case to be considered too.

> 3/ only declare partitions as nvmem providers. This would solve the
>     problem we have with partitions defined in the DT since
>     defining sub-partitions in the DT is not (yet?) supported and
>     partition nodes are supposed to be leaf nodes. Still, I'm not a big
>     fan of this solution because it will prevent us from supporting
>     sub-partitions if we ever want/need to.
> 
This one is going to come back so, its better we

> 4/ Add a ->of_xlate() hook that would be called if present by the
>     framework instead of using the default parsing we have right now.
This looks much cleaner! We could hook that up under 
__nvmem_device_get() to do that translation.

> 
> 5/ Tell the nvmem framework the name of the subnode containing nvmem
>     cell definitions (if NULL that means cells are directly defined
>     under the nvmem provider node). We would set it to "nvmem-cells" (or
>     whatever you like) for the MTD case.
Option 2 looks better than this.

> 
> There are probably other options (some were proposed by Alban and
> Srinivas already), but I'd like to get this sorted out before we merge
> this patch.
> 
> Alban, Srinivas, any opinion?

Overall am still not able to clear visualize on how MTD bindings with 
nvmem cells would look in both partition and un-partition usecases?
An example DT would be nice here!!

Option 4 looks like much generic solution to me, may be we should try 
this once bindings on MTD side w.r.t nvmem cells are decided.

Thanks,
Srini

> 

  reply index

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-10  8:04 [PATCH v2 00/29] at24: remove at24_platform_data Bartosz Golaszewski
2018-08-10  8:04 ` [PATCH v2 01/29] nvmem: add support for cell lookups Bartosz Golaszewski
2018-08-24 15:08   ` Boris Brezillon
2018-08-24 15:27     ` Andrew Lunn
2018-08-25  6:27       ` Boris Brezillon
2018-08-27  8:56         ` Bartosz Golaszewski
2018-08-27  9:00           ` Boris Brezillon
2018-08-27 13:37             ` Bartosz Golaszewski
2018-08-27 14:01               ` Boris Brezillon
2018-08-28 10:15               ` Srinivas Kandagatla
2018-08-28 11:56                 ` Bartosz Golaszewski
2018-08-28 13:45                   ` Srinivas Kandagatla
2018-08-28 14:41                     ` Bartosz Golaszewski
2018-08-28 14:48                       ` Srinivas Kandagatla
2018-08-28 14:53                       ` Boris Brezillon
2018-08-28 15:09                         ` Srinivas Kandagatla
2018-08-10  8:04 ` [PATCH v2 02/29] Documentation: nvmem: document lookup entries Bartosz Golaszewski
2018-08-31 20:30   ` Brian Norris
2018-09-01 13:11     ` Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 03/29] nvmem: add a notifier chain Bartosz Golaszewski
2018-08-10  8:33   ` Srinivas Kandagatla
2018-08-10  8:05 ` [PATCH v2 04/29] nvmem: provide nvmem_dev_name() Bartosz Golaszewski
2018-08-10  8:10   ` Srinivas Kandagatla
2018-08-10  8:05 ` [PATCH v2 05/29] nvmem: remove the name field from struct nvmem_device Bartosz Golaszewski
2018-08-10  8:33   ` Srinivas Kandagatla
2018-08-10  8:05 ` [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API Bartosz Golaszewski
2018-08-17 16:27   ` Boris Brezillon
2018-08-19 11:31     ` Alban
2018-08-19 16:46       ` Boris Brezillon
2018-08-20 10:43         ` Srinivas Kandagatla [this message]
2018-08-20 18:20           ` Boris Brezillon
2018-08-20 18:50             ` Bartosz Golaszewski
2018-08-20 19:06               ` Boris Brezillon
2018-08-20 21:27             ` Alban
2018-08-21  5:07               ` Boris Brezillon
2018-08-21  9:50             ` Srinivas Kandagatla
2018-08-21  9:56               ` Boris Brezillon
2018-08-21 10:11                 ` Srinivas Kandagatla
2018-08-21 10:43                   ` Boris Brezillon
2018-08-21 11:39               ` Alban
2018-08-21 12:00                 ` Srinivas Kandagatla
2018-08-21 13:01                   ` Boris Brezillon
2018-08-23 10:29                     ` Alban
2018-08-24 14:39                       ` Boris Brezillon
2018-08-28 10:20                       ` Srinivas Kandagatla
2018-08-20 22:53         ` Alban
2018-08-21  5:44           ` Boris Brezillon
2018-08-21  9:38             ` Srinivas Kandagatla
2018-08-21 11:31               ` Boris Brezillon
2018-08-21 13:34                 ` Srinivas Kandagatla
2018-08-21 13:37                   ` Srinivas Kandagatla
2018-08-21 13:57                     ` Boris Brezillon
2018-08-21 12:27             ` Alban
2018-08-21 12:57               ` Boris Brezillon
2018-08-21 13:57                 ` Alban
2018-08-21 14:26                   ` Boris Brezillon
2018-08-21 14:33                     ` Srinivas Kandagatla
2018-08-10  8:05 ` [PATCH v2 07/29] ARM: davinci: dm365-evm: use nvmem lookup for mac address Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 08/29] ARM: davinci: dm644-evm: " Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 09/29] ARM: davinci: dm646x-evm: " Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 10/29] ARM: davinci: da830-evm: " Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 11/29] ARM: davinci: mityomapl138: add nvmem cells lookup entries Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 12/29] ARM: davinci: da850-evm: use nvmem lookup for mac address Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 13/29] ARM: davinci: da850-evm: remove unnecessary include Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 14/29] net: simplify eth_platform_get_mac_address() Bartosz Golaszewski
2018-08-10 14:39   ` Andy Shevchenko
2018-08-10 16:17     ` Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 15/29] net: split eth_platform_get_mac_address() into subroutines Bartosz Golaszewski
2018-08-31 19:54   ` Brian Norris
2018-08-10  8:05 ` [PATCH v2 16/29] net: add support for nvmem to eth_platform_get_mac_address() Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 17/29] net: davinci_emac: use eth_platform_get_mac_address() Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 18/29] ARM: davinci: da850-evm: remove dead MTD code Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 19/29] ARM: davinci: mityomapl138: don't read the MAC address from machine code Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 20/29] ARM: davinci: dm365-evm: use device properties for at24 eeprom Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 21/29] ARM: davinci: da830-evm: " Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 22/29] ARM: davinci: dm644x-evm: " Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 23/29] ARM: davinci: dm646x-evm: " Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 24/29] ARM: davinci: sffsdr: fix the at24 eeprom device name Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 25/29] ARM: davinci: sffsdr: use device properties for at24 eeprom Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 26/29] ARM: davinci: remove dead code related to MAC address reading Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 27/29] ARM: davinci: mityomapl138: use nvmem notifiers Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 28/29] ARM: davinci: mityomapl138: use device properties for at24 eeprom Bartosz Golaszewski
2018-08-10  8:05 ` [PATCH v2 29/29] eeprom: at24: kill at24_platform_data Bartosz Golaszewski
2018-08-10  8:41 ` [PATCH v2 00/29] at24: remove at24_platform_data Srinivas Kandagatla
2018-08-31 19:46 ` Brian Norris
2018-10-03 20:15   ` Bartosz Golaszewski
2018-10-03 20:30     ` Lukas Wunner
2018-10-03 21:04     ` Florian Fainelli
2018-10-04 11:06       ` Bartosz Golaszewski
2018-10-04 13:58         ` Arnd Bergmann
2018-10-04 14:35           ` Sowmini Varadhan
2018-10-04 14:38             ` Arnd Bergmann

Reply instructions:

You may reply publically 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=5b8c30b8-41e1-d59e-542b-fef6c6469ff0@linaro.org \
    --to=srinivas.kandagatla@linaro.org \
    --cc=akpm@linux-foundation.org \
    --cc=albeu@free.fr \
    --cc=andrew@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=bgolaszewski@baylibre.com \
    --cc=boris.brezillon@bootlin.com \
    --cc=brgl@bgdev.pl \
    --cc=computersforpeace@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dan.carpenter@oracle.com \
    --cc=davem@davemloft.net \
    --cc=david@lechnology.com \
    --cc=dwmw2@infradead.org \
    --cc=f.fainelli@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=grygorii.strashko@ti.com \
    --cc=ivan.khoronzhuk@linaro.org \
    --cc=khilman@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lukas@wunner.de \
    --cc=marek.vasut@gmail.com \
    --cc=mchehab+samsung@kernel.org \
    --cc=naren.kernel@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nsekhar@ti.com \
    --cc=pabeni@redhat.com \
    --cc=richard@nod.at \
    --cc=robh@kernel.org \
    --cc=svendev@arcx.com \
    /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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org linux-kernel@archiver.kernel.org
	public-inbox-index lkml


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox