linux-kernel - [PATCH 0/3] mtd: Add support for reading MTD devices via the nvmem API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu,  2 Mar 2017 20:50:20 +0100
From:   Alban <albeu@...e.fr>
To:     linux-kernel@...r.kernel.org
Cc:     devicetree@...r.kernel.org, linux-mtd@...ts.infradead.org,
        Cyrille Pitchen <cyrille.pitchen@...el.com>,
        Richard Weinberger <richard@....at>,
        Marek Vasut <marek.vasut@...il.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Brian Norris <computersforpeace@...il.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Mark Rutland <mark.rutland@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Moritz Fischer <moritz.fischer@...us.com>,
        Alban <albeu@...e.fr>
Subject: [PATCH 0/3] mtd: Add support for reading MTD devices via the nvmem API

Hi all,

this is the followup to my "device data" patch[1] that add nvmem support
to the MTD subsystem. I took a look at the work done by Moritz[2] but we
had different goals. Moritz needed access to the MTD protection
registers where I need access to the normal data. For my use-case we can
just use the normal nvmem bindings and define the nvmem cells as
children nodes of the MTD partitions. The only thing I added is the
requirement for a `nvmem-provider` property in the partition to allow
the driver to only register the required partitions.

Note that nvmem cells currently can't be defined on the raw MTD devices
as that would clash with the old partitions binding. I think it would
be better to change the nvmem binding to require putting the cells in a
dedicated subnode, like in the new partitions binding.

Otherwise I just skipped Moritz's use-case as I don't know anything
about the MTD protection registers.

Finally I included a bug fix for the case where several nvmem devices
without name are registered. Currently all devices get registered as
`nvmem0` and the second registration fails.

[1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1341549.html
[2] https://patchwork.ozlabs.org/patch/626460/

Alban (3):
  doc: bindings: Add bindings documentation for mtd nvmem
  mtd: Add support for reading MTD devices via the nvmem API
  nvmem: core: Allow allocating several anonymous nvmem devices

 .../devicetree/bindings/nvmem/mtd-nvmem.txt        |  29 +++++
 drivers/mtd/Kconfig                                |   9 ++
 drivers/mtd/Makefile                               |   1 +
 drivers/mtd/mtdnvmem.c                             | 121 +++++++++++++++++++++
 drivers/nvmem/core.c                               |   3 +-
 5 files changed, 162 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
 create mode 100644 drivers/mtd/mtdnvmem.c

-- 
2.7.4