Linux-mmc Archive mirror
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Jens Axboe" <axboe@kernel.dk>,
	"Daniel Golle" <daniel@makrotopia.org>,
	"Dave Chinner" <dchinner@redhat.com>, "Jan Kara" <jack@suse.cz>,
	"Thomas Weißschuh" <linux@weissschuh.net>,
	"Christian Brauner" <brauner@kernel.org>,
	"Li Lingfeng" <lilingfeng3@huawei.com>,
	"Damien Le Moal" <dlemoal@kernel.org>,
	"Min Li" <min15.li@samsung.com>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	"Hannes Reinecke" <hare@suse.de>,
	"Christian Loehle" <CLoehle@hyperstone.com>,
	"Avri Altman" <avri.altman@wdc.com>,
	"Bean Huo" <beanhuo@micron.com>, "Yeqi Fu" <asuk4.q@gmail.com>,
	"Victor Shih" <victor.shih@genesyslogic.com.tw>,
	"Christophe JAILLET" <christophe.jaillet@wanadoo.fr>,
	"Ricardo B. Marliere" <ricardo@marliere.net>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mmc@vger.kernel.org, linux-block@vger.kernel.org
Cc: Diping Zhang <diping.zhang@gl-inet.com>,
	Jianhui Zhao <zhaojh329@gmail.com>,
	Jieying Zeng <jieying.zeng@gl-inet.com>,
	Chad Monroe <chad.monroe@adtran.com>,
	Adam Fox <adam.fox@adtran.com>, John Crispin <john@phrozen.org>
Subject: [RFC PATCH v2 0/8] nvmem: add block device NVMEM provider
Date: Tue, 5 Mar 2024 20:23:07 +0000	[thread overview]
Message-ID: <cover.1709667858.git.daniel@makrotopia.org> (raw)

On embedded devices using an eMMC it is common that one or more (hw/sw)
partitions on the eMMC are used to store MAC addresses and Wi-Fi
calibration EEPROM data.

Implement an NVMEM provider backed by block devices as typically the
NVMEM framework is used to have kernel drivers read and use binary data
from EEPROMs, efuses, flash memory (MTD), ...

In order to be able to reference hardware partitions on an eMMC, add code
to bind each hardware partition to a specific firmware subnode.

This series is meant to open the discussion on how exactly the device
tree schema for block devices and partitions may look like, and even
if using the block layer to back the NVMEM device is at all the way to
go -- to me it seemed to be a good solution because it will be reuable
e.g. for (normal, software GPT or MBR) partitions of an NVMe SSD.

This series has previously been submitted on July 19th 2023[1] and most of
the basic idea did not change since.

However, the recent introduction of bdev_file_open_by_dev() allow to
get rid of most use of block layer internals which supposedly was the
main objection raised by Christoph Hellwig back then.

Most of the other comments received for in the first RFC have also
been addressed, however, what remains is the use of class_interface
(lacking an alternative way to get notifications about addition or
removal of block devices from the system). As this has been criticized
in the past I'm specifically interested in suggestions on how to solve
this in another way -- ideally without having to implement a whole new
way for in-kernel notifications of appearing or disappearing block
devices...

And, in a way just like in case of MTD and UBI, I believe acting as an
NVMEM provider *is* a functionality which belongs to the block layer
itself and, other than e.g. filesystems, is inconvenient to implement
elsewhere.

[1]: https://patchwork.kernel.org/project/linux-block/list/?series=767565

Daniel Golle (8):
  dt-bindings: block: add basic bindings for block devices
  block: partitions: populate fwnode
  block: add new genhd flag GENHD_FL_NVMEM
  block: implement NVMEM provider
  dt-bindings: mmc: mmc-card: add block device nodes
  mmc: core: set card fwnode_handle
  mmc: block: set fwnode of disk devices
  mmc: block: set GENHD_FL_NVMEM

 .../bindings/block/block-device.yaml          |  22 +++
 .../devicetree/bindings/block/partition.yaml  |  51 +++++
 .../devicetree/bindings/block/partitions.yaml |  20 ++
 .../devicetree/bindings/mmc/mmc-card.yaml     |  45 +++++
 block/Kconfig                                 |   9 +
 block/Makefile                                |   1 +
 block/blk-nvmem.c                             | 175 ++++++++++++++++++
 block/partitions/core.c                       |  41 ++++
 drivers/mmc/core/block.c                      |   8 +
 drivers/mmc/core/bus.c                        |   2 +
 include/linux/blkdev.h                        |   2 +
 11 files changed, 376 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/block/block-device.yaml
 create mode 100644 Documentation/devicetree/bindings/block/partition.yaml
 create mode 100644 Documentation/devicetree/bindings/block/partitions.yaml
 create mode 100644 block/blk-nvmem.c

-- 
2.44.0

             reply	other threads:[~2024-03-05 20:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-05 20:23 Daniel Golle [this message]
2024-03-05 20:23 ` [RFC PATCH v2 1/8] dt-bindings: block: add basic bindings for block devices Daniel Golle
2024-03-06  7:22   ` Sascha Hauer
2024-03-06  7:32     ` Sascha Hauer
2024-03-07 14:51   ` Rob Herring
2024-03-11 19:40     ` [EXTERNAL] " Chad Monroe
2024-03-05 20:23 ` [RFC PATCH v2 2/8] block: partitions: populate fwnode Daniel Golle
2024-03-05 20:23 ` [RFC PATCH v2 3/8] block: add new genhd flag GENHD_FL_NVMEM Daniel Golle
2024-03-05 20:23 ` [RFC PATCH v2 4/8] block: implement NVMEM provider Daniel Golle
2024-03-06 12:00   ` Ricardo B. Marliere
2024-03-05 20:24 ` [RFC PATCH v2 5/8] dt-bindings: mmc: mmc-card: add block device nodes Daniel Golle
2024-03-05 20:24 ` [RFC PATCH v2 6/8] mmc: core: set card fwnode_handle Daniel Golle
2024-03-08  8:04   ` Avri Altman
2024-03-08 14:55     ` Daniel Golle
2024-03-05 20:24 ` [RFC PATCH v2 7/8] mmc: block: set fwnode of disk devices Daniel Golle
2024-03-05 20:24 ` [RFC PATCH v2 8/8] mmc: block: set GENHD_FL_NVMEM Daniel Golle
2024-03-12 12:22 ` [RFC PATCH v2 0/8] nvmem: add block device NVMEM provider Ulf Hansson
2024-03-12 12:30   ` Daniel Golle
2024-03-12 12:57     ` Ulf Hansson
2024-03-12 13:12       ` Daniel Golle
2024-03-13 10:19         ` Ulf Hansson

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=cover.1709667858.git.daniel@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=CLoehle@hyperstone.com \
    --cc=adam.fox@adtran.com \
    --cc=adrian.hunter@intel.com \
    --cc=asuk4.q@gmail.com \
    --cc=avri.altman@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=beanhuo@micron.com \
    --cc=brauner@kernel.org \
    --cc=chad.monroe@adtran.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=conor+dt@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=diping.zhang@gl-inet.com \
    --cc=dlemoal@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hare@suse.de \
    --cc=jack@suse.cz \
    --cc=jieying.zeng@gl-inet.com \
    --cc=john@phrozen.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lilingfeng3@huawei.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=min15.li@samsung.com \
    --cc=ricardo@marliere.net \
    --cc=robh@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=victor.shih@genesyslogic.com.tw \
    --cc=zhaojh329@gmail.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
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 read-only IMAP folder(s) and NNTP newsgroup(s).