Re: [RFC PATCH 3/6] block: add new genhd flag GENHD_FL_NO_NVMEM

From: Hannes Reinecke
Date: Thu Jul 20 2023 - 10:03:30 EST


On 7/20/23 15:47, Daniel Golle wrote:
On Thu, Jul 20, 2023 at 10:24:18AM +0200, Hannes Reinecke wrote:
On 7/20/23 00:03, Daniel Golle wrote:
Add new flag to destinguish block devices which should not act as an
NVMEM provider, such as for example an emulated block device on top of
an MTD partition which already acts as an NVMEM provider itself.

Signed-off-by: Daniel Golle <daniel@xxxxxxxxxxxxxx>
---
include/linux/blkdev.h | 3 +++
1 file changed, 3 insertions(+)

diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 2f5371b8482c0..e853d1815be15 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -80,11 +80,14 @@ struct partition_meta_info {
* ``GENHD_FL_NO_PART``: partition support is disabled. The kernel will not
* scan for partitions from add_disk, and users can't add partitions manually.
*
+ * ``GENHD_FL_NO_NVMEM``: NVMEM emulation is disabled. The kernel will not
+ * emulate an NVMEM device on top of this disk.
*/
enum {
GENHD_FL_REMOVABLE = 1 << 0,
GENHD_FL_HIDDEN = 1 << 1,
GENHD_FL_NO_PART = 1 << 2,
+ GENHD_FL_NO_NVMEM = 1 << 3,
};
enum {
Please reverse this flag. Most of the devices will not have an NVMEM
partition, and we shouldn't require each and every driver to tag their
devices.
So please use GENHD_FL_NVMEM and only set this flag on devices which really
have an NVMEM partition.

The idea here was to exclude all those devices which already implement
an NVMEM provider on a lower layer themselves, such as MTD.
In this cases it would be ambigous if the OF node represents the
NVMEM device registered by the MTD framework or if blk-nvmem should be
used.

Hmm; not sure if I follow.
In the end, it doesn't really matter whether you check for
GENHD_FL_NO_NVMEM or !GENHD_FL_NVMEM.
With the difference being that in the former case you have to
tag 99% of all existing block devices, and in the latter you
have to tag 1%.

In all other cases device tree can unambigously indicate whether a
block device should serve as NVMEM provider (and right, most of them
never will).

However, reversing the logic seems fine just as well.

Thanks. Please do.

Cheers,

Hannes