From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Alban <albeu@free.fr>, linux-kernel@vger.kernel.org
Cc: 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 2/3] mtd: Add support for reading MTD devices via the nvmem API
Date: Fri, 3 Mar 2017 11:23:16 +0000 [thread overview]
Message-ID: <b2df74bb-dd86-bac1-ab8b-cbff6ca29b6f@linaro.org> (raw)
In-Reply-To: <1488484223-844-3-git-send-email-albeu@free.fr>
On 02/03/17 19:50, Alban wrote:
> Allow drivers that use the nvmem API to read data stored on MTD devices.
> This add a simple mtd user that register itself as a read-only nvmem
> device.
>
Good stuff!! and useful for MAC addresses.
Am not going to repeat the same comments as Boris, but I totally agree
with his comments.
> Signed-off-by: Alban <albeu@free.fr>
> ---
> drivers/mtd/Kconfig | 9 ++++
> drivers/mtd/Makefile | 1 +
> drivers/mtd/mtdnvmem.c | 121 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 131 insertions(+)
> create mode 100644 drivers/mtd/mtdnvmem.c
May be we should move this driver to drivers/nvmem/
>
> diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
> index e83a279..9cad86c 100644
> --- a/drivers/mtd/Kconfig
> +++ b/drivers/mtd/Kconfig
> @@ -322,6 +322,15 @@ config MTD_PARTITIONED_MASTER
> the parent of the partition device be the master device, rather than
> what lies behind the master.
>
> +config MTD_NVMEM
> + tristate "Read config data from MTD devices"
May be..
"Read config data from MTD devices via NVMEM API".
Or
"MTD NVMEM Provider"
> + default y
Do you really want it be ON by default?
> + depends on NVMEM
Adding COMPILE_TEST would give us good test coverage.
> + help
> + Provides support for reading config data from MTD devices. This can
> + be used by drivers to read device specific data such as MAC addresses
> + or calibration results.
> +
> source "drivers/mtd/chips/Kconfig"
>
> source "drivers/mtd/maps/Kconfig"
> diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
> index 99bb9a1..f62f50b 100644
> --- a/drivers/mtd/Makefile
> +++ b/drivers/mtd/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_SSFDC) += ssfdc.o
> obj-$(CONFIG_SM_FTL) += sm_ftl.o
> obj-$(CONFIG_MTD_OOPS) += mtdoops.o
> obj-$(CONFIG_MTD_SWAP) += mtdswap.o
> +obj-$(CONFIG_MTD_NVMEM) += mtdnvmem.o
>
> nftl-objs := nftlcore.o nftlmount.o
> inftl-objs := inftlcore.o inftlmount.o
> diff --git a/drivers/mtd/mtdnvmem.c b/drivers/mtd/mtdnvmem.c
> new file mode 100644
> index 0000000..6eb4216
> --- /dev/null
> +++ b/drivers/mtd/mtdnvmem.c
> @@ -0,0 +1,121 @@
> +/*
> + * Copyright (C) 2017 Alban Bedel <albeu@free.fr>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/nvmem-provider.h>
> +#include <linux/nvmem-consumer.h>
??
> +#include <linux/slab.h>
> +#include <linux/of.h>
> +
> +struct mtd_nvmem {
> + struct list_head list;
> + struct mtd_info *mtd;
> + struct nvmem_device *nvmem;
> +};
> +
> +static DEFINE_MUTEX(mtd_nvmem_list_lock);
> +static LIST_HEAD(mtd_nvmem_list);
> +
> +static int mtd_nvmem_reg_read(void *priv, unsigned int offset,
> + void *val, size_t bytes)
> +{
> + struct mtd_info *mtd = priv;
> + size_t retlen;
> + int err;
> +
> + err = mtd_read(mtd, offset, bytes, &retlen, val);
> + if (err && err != -EUCLEAN)
> + return err;
> +
> + return retlen == bytes ? 0 : -EIO;
> +}
> +
> +static void mtd_nvmem_add(struct mtd_info *mtd)
> +{
> + struct device *dev = &mtd->dev;
> + struct device_node *np = dev_of_node(dev);
> + struct nvmem_config config = {};
> + struct mtd_nvmem *mtd_nvmem;
> +
> + /* OF devices have to provide the nvmem node */
> + if (np && !of_property_read_bool(np, "nvmem-provider"))
> + return;
we should prefix the property with mtd to make to more explicit that
this is very much specific to MTD.
> +
> + config.dev = dev;
> + config.owner = THIS_MODULE;
> + config.reg_read = mtd_nvmem_reg_read;
> + config.size = mtd->size;
> + config.word_size = 1;
> + config.stride = 1;
> + config.read_only = true;
> + config.priv = mtd;
> +
> + /* Alloc our struct to keep track of the MTD NVMEM devices */
> + mtd_nvmem = kzalloc(sizeof(*mtd_nvmem), GFP_KERNEL);
> + if (!mtd_nvmem)
> + return;
> +
> + mtd_nvmem->mtd = mtd;
> + mtd_nvmem->nvmem = nvmem_register(&config);
> + if (IS_ERR(mtd_nvmem->nvmem)) {
> + dev_err(dev, "Failed to register NVMEM device\n");
> + kfree(mtd_nvmem);
> + return;
> + }
> +
> + mutex_lock(&mtd_nvmem_list_lock);
> + list_add_tail(&mtd_nvmem->list, &mtd_nvmem_list);
> + mutex_unlock(&mtd_nvmem_list_lock);
> +}
> +
> +static void mtd_nvmem_remove(struct mtd_info *mtd)
> +{
> + struct mtd_nvmem *mtd_nvmem;
> + bool found = false;
> +
May be we can use of_nvmem_find() directly here and avoid all this list
and lock thingy. It should make the driver much simpler.
Am sure we can add exception to make of_nvmem_find() symbol public if
its helping providers like this.
> + mutex_lock(&mtd_nvmem_list_lock);
> + list_for_each_entry(mtd_nvmem, &mtd_nvmem_list, list) {
> + if (mtd_nvmem->mtd == mtd) {
> + list_del(&mtd_nvmem->list);
> + found = true;
> + break;
> + }
> + }
> + mutex_unlock(&mtd_nvmem_list_lock);
> +
> + if (found) {
> + if (nvmem_unregister(mtd_nvmem->nvmem))
> + dev_err(&mtd->dev,
> + "Failed to unregister NVMEM device\n");
I will be nice to feedback error to top layer, as it does not make sense
to remove providers if there are active consumers using it.
del_mtd_device(), unregister_mtd_user() have return values, I see no
reason why notifiers should not return errors.
May be if we should fix the remove() call backs to handle and return errors.
> + kfree(mtd_nvmem);
> + }
> +}
> +
> +static struct mtd_notifier mtd_nvmem_notifier = {
> + .add = mtd_nvmem_add,
> + .remove = mtd_nvmem_remove,
> +};
> +
> +static int __init mtd_nvmem_init(void)
> +{
> + register_mtd_user(&mtd_nvmem_notifier);
> + return 0;
> +}
> +module_init(mtd_nvmem_init);
> +
> +static void __exit mtd_nvmem_exit(void)
> +{
> + unregister_mtd_user(&mtd_nvmem_notifier);
> +}
> +module_exit(mtd_nvmem_exit);
> +
> +MODULE_LICENSE("GPL");
GPL V2 ??
Thanks,
srini
> +MODULE_AUTHOR("Alban Bedel <albeu@free.fr>");
> +MODULE_DESCRIPTION("Driver to read config data from MTD devices");
>
next prev parent reply other threads:[~2017-03-03 11:24 UTC|newest]
Thread overview: 27+ 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 ` [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem Alban
2017-03-02 20:22 ` Boris Brezillon
2017-03-03 12:17 ` Alban
2017-03-03 12:37 ` Boris Brezillon
2017-03-03 13:12 ` Alban
2017-03-03 11:27 ` Srinivas Kandagatla
2017-03-03 12:19 ` Boris Brezillon
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 21:18 ` Boris Brezillon
2017-03-03 12:36 ` Alban
2017-03-03 13:36 ` Boris Brezillon
2017-03-03 13:57 ` Alban
2017-03-03 14:11 ` Boris Brezillon
2017-03-03 22:21 ` Richard Weinberger
2017-03-06 17:21 ` Alban
2017-03-06 19:03 ` Richard Weinberger
2017-03-06 21:02 ` Boris Brezillon
2017-03-03 11:23 ` Srinivas Kandagatla [this message]
2017-03-03 12:34 ` Boris Brezillon
2017-03-03 13:30 ` Alban
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 20:03 ` Boris Brezillon
2017-03-03 1:50 ` Moritz Fischer
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=b2df74bb-dd86-bac1-ab8b-cbff6ca29b6f@linaro.org \
--to=srinivas.kandagatla@linaro.org \
--cc=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 \
/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).