Skip to contentSkip to conversation

mtd: ubi: allow UBI volumes to provide NVMEM

PATCH Superseded Daniel Golle 1 participant 7 messages Aug 5, 2023

Subsystems (2)

v2 of 8 Superseded Latest is v8 →

lore
Share & tools
lore
#0 lore raw

v2 cover mtd: ubi: allow UBI volumes to provide NVMEM

The series is a follow-up and contains all patches of the previous series "mtd: ubi: behave like a good MTD citizen"[1] which was meant in preparation for implementing the NVMEM provider.

The goal is to support embedded Linux devices which got NVMEM bits stored inside a UBI volume. Representing the UBI volume in the Device Tree, adding a phandle to be referenced by NVMEM consumers allows such devices to come up with their correct MAC addresses and device-specific Wi-Fi calibration data loaded.

In order to be available for other drivers, attaching UBI devices has to be moved from late_initcall (which is too late for other drivers) to happen earlier. As an alternative to the existing kernel cmdline parameter the Device Tree property 'compatible = "linux,ubi";' inside an MTD partition can be used to have that MTD device attached as UBI device. MTD partitions which serve as UBI devices may have a "volumes" firmware subnode with volumes which may be compatible with "nvmem-cells".

In this way, other drivers (think: Ethernet, Wi-Fi) can resolve and acquire NVMEM bits using the usual device tree phandle, just this time the NVMEM content is read from a UBI volume.

[1]: https://patchwork.ozlabs.org/project/linux-mtd/list/?series=353177&state=%2A&archive=both

Changes since v1:
* include patch to fix exiting Kconfig formatting issues
* fix typo and indentation in Kconfig

Daniel Golle (7):
mtd: ubi: improve Kconfig formatting
mtd: ubi: block: don't return on error when removing
mtd: ubi: block: use notifier to create ubiblock from parameter
mtd: ubi: attach MTD partition from device-tree
mtd: ubi: introduce pre-removal notification for UBI volumes
mtd: ubi: populate ubi volume fwnode
mtd: ubi: provide NVMEM layer over UBI volumes

 drivers/mtd/ubi/Kconfig  |  72 ++++++++-------
 drivers/mtd/ubi/Makefile |   1 +
 drivers/mtd/ubi/block.c  | 186 +++++++++++++++++++++++---------------
 drivers/mtd/ubi/build.c  | 160 ++++++++++++++++++++++++---------
 drivers/mtd/ubi/cdev.c   |   4 +-
 drivers/mtd/ubi/nvmem.c  | 189 +++++++++++++++++++++++++++++++++++++++
 drivers/mtd/ubi/ubi.h    |   6 +-
 drivers/mtd/ubi/vmt.c    |  36 ++++++++
 include/linux/mtd/ubi.h  |   2 +
 9 files changed, 507 insertions(+), 149 deletions(-)
 create mode 100644 drivers/mtd/ubi/nvmem.c
Signature · 1 line
2.41.0
#1 lore raw

PATCH v2 1/7 mtd: ubi: improve Kconfig formatting

Kconfig help text should be indented with one tab + 2 spaces according to coding-style.rst. Apply this rule in drivers/mtd/ubi/Kconfig

---
 drivers/mtd/ubi/Kconfig | 60 ++++++++++++++++++++---------------------
 1 file changed, 30 insertions(+), 30 deletions(-)
drivers/mtd/ubi/Kconfig +30 -30
index 2ed77b7b3fcb5..184118f9a2969 100644
@@ -61,47 +61,47 @@ config MTD_UBI_FASTMAP
 	bool "UBI Fastmap (Experimental feature)"
 	default n
 	help
-	   Important: this feature is experimental so far and the on-flash
-	   format for fastmap may change in the next kernel versions
-
-	   Fastmap is a mechanism which allows attaching an UBI device
-	   in nearly constant time. Instead of scanning the whole MTD device it
-	   only has to locate a checkpoint (called fastmap) on the device.
-	   The on-flash fastmap contains all information needed to attach
-	   the device. Using fastmap makes only sense on large devices where
-	   attaching by scanning takes long. UBI will not automatically install
-	   a fastmap on old images, but you can set the UBI module parameter
-	   fm_autoconvert to 1 if you want so. Please note that fastmap-enabled
-	   images are still usable with UBI implementations without
-	   fastmap support. On typical flash devices the whole fastmap fits
-	   into one PEB. UBI will reserve PEBs to hold two fastmaps.
-
-	   If in doubt, say "N".
+	  Important: this feature is experimental so far and the on-flash
+	  format for fastmap may change in the next kernel versions
+
+	  Fastmap is a mechanism which allows attaching an UBI device
+	  in nearly constant time. Instead of scanning the whole MTD device it
+	  only has to locate a checkpoint (called fastmap) on the device.
+	  The on-flash fastmap contains all information needed to attach
+	  the device. Using fastmap makes only sense on large devices where
+	  attaching by scanning takes long. UBI will not automatically install
+	  a fastmap on old images, but you can set the UBI module parameter
+	  fm_autoconvert to 1 if you want so. Please note that fastmap-enabled
+	  images are still usable with UBI implementations without
+	  fastmap support. On typical flash devices the whole fastmap fits
+	  into one PEB. UBI will reserve PEBs to hold two fastmaps.
+
+	  If in doubt, say "N".
 
 config MTD_UBI_GLUEBI
 	tristate "MTD devices emulation driver (gluebi)"
 	help
-	   This option enables gluebi - an additional driver which emulates MTD
-	   devices on top of UBI volumes: for each UBI volumes an MTD device is
-	   created, and all I/O to this MTD device is redirected to the UBI
-	   volume. This is handy to make MTD-oriented software (like JFFS2)
-	   work on top of UBI. Do not enable this unless you use legacy
-	   software.
+	  This option enables gluebi - an additional driver which emulates MTD
+	  devices on top of UBI volumes: for each UBI volumes an MTD device is
+	  created, and all I/O to this MTD device is redirected to the UBI
+	  volume. This is handy to make MTD-oriented software (like JFFS2)
+	  work on top of UBI. Do not enable this unless you use legacy
+	  software.
 
 config MTD_UBI_BLOCK
 	bool "Read-only block devices on top of UBI volumes"
 	default n
 	depends on BLOCK
 	help
-	   This option enables read-only UBI block devices support. UBI block
-	   devices will be layered on top of UBI volumes, which means that the
-	   UBI driver will transparently handle things like bad eraseblocks and
-	   bit-flips. You can put any block-oriented file system on top of UBI
-	   volumes in read-only mode (e.g., ext4), but it is probably most
-	   practical for read-only file systems, like squashfs.
+	  This option enables read-only UBI block devices support. UBI block
+	  devices will be layered on top of UBI volumes, which means that the
+	  UBI driver will transparently handle things like bad eraseblocks and
+	  bit-flips. You can put any block-oriented file system on top of UBI
+	  volumes in read-only mode (e.g., ext4), but it is probably most
+	  practical for read-only file systems, like squashfs.
 
-	   When selected, this feature will be built in the UBI driver.
+	  When selected, this feature will be built in the UBI driver.
 
-	   If in doubt, say "N".
+	  If in doubt, say "N".
 
 endif # MTD_UBI
Signature · 1 line
2.41.0
#2 lore raw

PATCH v2 2/7 mtd: ubi: block: don't return on error when removing

In reply to Daniel Golle

There is no point on returning the error from ubiblock_remove in case it is being called due to a volume removal event -- the volume is gone, we should destroy and remove the ubiblock device no matter what.

Introduce new boolean parameter 'force' to tell ubiblock_remove to go on even in case the ubiblock device is still busy. Use that new option when calling ubiblock_remove due to a UBI_VOLUME_REMOVED event.

---
 drivers/mtd/ubi/block.c | 6 +++---
 drivers/mtd/ubi/cdev.c  | 2 +-
 drivers/mtd/ubi/ubi.h   | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)
drivers/mtd/ubi/block.c +3 -3
index 437c5b83ffe51..69fa6fecb8494 100644
@@ -456,7 +456,7 @@ static void ubiblock_cleanup(struct ubiblock *dev)
 	idr_remove(&ubiblock_minor_idr, dev->gd->first_minor);
 }
 
-int ubiblock_remove(struct ubi_volume_info *vi)
+int ubiblock_remove(struct ubi_volume_info *vi, bool force)
 {
 	struct ubiblock *dev;
 	int ret;
@@ -470,7 +470,7 @@ int ubiblock_remove(struct ubi_volume_info *vi)
 
 	/* Found a device, let's lock it so we can check if it's busy */
 	mutex_lock(&dev->dev_mutex);
-	if (dev->refcnt > 0) {
+	if (dev->refcnt > 0 && !force) {
 		ret = -EBUSY;
 		goto out_unlock_dev;
 	}
@@ -545,7 +545,7 @@ static int ubiblock_notify(struct notifier_block *nb,
 		 */
 		break;
 	case UBI_VOLUME_REMOVED:
-		ubiblock_remove(&nt->vi);
+		ubiblock_remove(&nt->vi, true);
 		break;
 	case UBI_VOLUME_RESIZED:
 		ubiblock_resize(&nt->vi);
drivers/mtd/ubi/cdev.c +1 -1
index f43430b9c1e65..bb55e863dd296 100644
@@ -572,7 +572,7 @@ static long vol_cdev_ioctl(struct file *file, unsigned int cmd,
 		struct ubi_volume_info vi;
 
 		ubi_get_volume_info(desc, &vi);
-		err = ubiblock_remove(&vi);
+		err = ubiblock_remove(&vi, false);
 		break;
 	}
 
drivers/mtd/ubi/ubi.h +2 -2
index c8f1bd4fa1008..44c0eeaf1e1b0 100644
@@ -979,7 +979,7 @@ static inline void ubi_fastmap_destroy_checkmap(struct ubi_volume *vol) {}
 int ubiblock_init(void);
 void ubiblock_exit(void);
 int ubiblock_create(struct ubi_volume_info *vi);
-int ubiblock_remove(struct ubi_volume_info *vi);
+int ubiblock_remove(struct ubi_volume_info *vi, bool force);
 #else
 static inline int ubiblock_init(void) { return 0; }
 static inline void ubiblock_exit(void) {}
@@ -987,7 +987,7 @@ static inline int ubiblock_create(struct ubi_volume_info *vi)
 {
 	return -ENOSYS;
 }
-static inline int ubiblock_remove(struct ubi_volume_info *vi)
+static inline int ubiblock_remove(struct ubi_volume_info *vi, bool force)
 {
 	return -ENOSYS;
 }
Signature · 1 line
2.41.0
#3 lore raw

PATCH v2 4/7 mtd: ubi: attach MTD partition from device-tree

In reply to Daniel Golle

Split ubi_init() function into early function to be called by device_initcall() and keep cmdline attachment in late_initcall(). (when building ubi as module, both is still done in a single module_init() call)

Register MTD notifier and attach MTD devices which are marked as compatible with 'linux,ubi' in OF device-tree when being added, detach UBI device from MTD device when it is being removed.

For existing users this should not change anything besides automatic removal of (dead) UBI devices when their underlying MTD devices are already gone, e.g. in case of MTD driver module or (SPI) bus driver module being removed.

For new users this opens up the option to attach UBI using device-tree which then happens early and in parallel with other drivers being probed which slightly reduces the total boot time.

Attachment no longer happening late is also a requirement for other drivers to make use of UBI, e.g. drivers/nvmem/u-boot-env.c can now be extended to support U-Boot environment stored in UBI volumes.

---
 drivers/mtd/ubi/block.c |   2 +-
 drivers/mtd/ubi/build.c | 153 +++++++++++++++++++++++++++++-----------
 drivers/mtd/ubi/cdev.c  |   2 +-
 drivers/mtd/ubi/ubi.h   |   2 +-
 4 files changed, 115 insertions(+), 44 deletions(-)
drivers/mtd/ubi/block.c +1 -1
index e0618bbde3613..99b5f502c9dbc 100644
@@ -470,7 +470,7 @@ int ubiblock_remove(struct ubi_volume_info *vi, bool force)
 	}
 
 	/* Found a device, let's lock it so we can check if it's busy */
-	mutex_lock(&dev->dev_mutex);
+	mutex_lock_nested(&dev->dev_mutex, SINGLE_DEPTH_NESTING);
 	if (dev->refcnt > 0 && !force) {
 		ret = -EBUSY;
 		goto out_unlock_dev;
drivers/mtd/ubi/build.c +112 -41

230 lines not on this page · raw message

drivers/mtd/ubi/cdev.c +1 -1
index bb55e863dd296..0ba6aa6a2e11d 100644
@@ -1065,7 +1065,7 @@ static long ctrl_cdev_ioctl(struct file *file, unsigned int cmd,
 		}
 
 		mutex_lock(&ubi_devices_mutex);
-		err = ubi_detach_mtd_dev(ubi_num, 0);
+		err = ubi_detach_mtd_dev(ubi_num, 0, false);
 		mutex_unlock(&ubi_devices_mutex);
 		break;
 	}
drivers/mtd/ubi/ubi.h +1 -1
index 44c0eeaf1e1b0..54093858f3385 100644
@@ -939,7 +939,7 @@ int ubi_io_write_vid_hdr(struct ubi_device *ubi, int pnum,
 int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num,
 		       int vid_hdr_offset, int max_beb_per1024,
 		       bool disable_fm);
-int ubi_detach_mtd_dev(int ubi_num, int anyway);
+int ubi_detach_mtd_dev(int ubi_num, int anyway, bool have_lock);
 struct ubi_device *ubi_get_device(int ubi_num);
 void ubi_put_device(struct ubi_device *ubi);
 struct ubi_device *ubi_get_by_major(int major);
Signature · 1 line
2.41.0
#4 lore raw

PATCH v2 5/7 mtd: ubi: introduce pre-removal notification for UBI volumes

In reply to Daniel Golle

Introduce a new notification type UBI_VOLUME_SHUTDOWN to inform users that a volume is just about to be removed.
This is needed because users (such as the NVMEM subsystem) expect that at the time their removal function is called, the parenting device is still available (for removal of sysfs nodes, for example, in case of NVMEM which otherwise WARNs on volume removal).

---
 drivers/mtd/ubi/block.c | 26 ++++++++++++++++++++++++++
 drivers/mtd/ubi/build.c |  7 ++++++-
 drivers/mtd/ubi/vmt.c   |  5 +++++
 include/linux/mtd/ubi.h |  2 ++
 4 files changed, 39 insertions(+), 1 deletion(-)
drivers/mtd/ubi/block.c +26 -0
index 99b5f502c9dbc..1d5148371991b 100644
@@ -533,6 +533,29 @@ static int ubiblock_resize(struct ubi_volume_info *vi)
 	return 0;
 }
 
+static int ubiblock_shutdown(struct ubi_volume_info *vi)
+{
+	struct ubiblock *dev;
+	struct gendisk *disk;
+	int ret = 0;
+
+	mutex_lock(&devices_mutex);
+	dev = find_dev_nolock(vi->ubi_num, vi->vol_id);
+	if (!dev) {
+		ret = -ENODEV;
+		goto out_unlock;
+	}
+	disk = dev->gd;
+
+out_unlock:
+	mutex_unlock(&devices_mutex);
+
+	if (!ret)
+		blk_mark_disk_dead(disk);
+
+	return ret;
+};
+
 static bool
 match_volume_desc(struct ubi_volume_info *vi, const char *name, int ubi_num, int vol_id)
 {
@@ -624,6 +647,9 @@ static int ubiblock_notify(struct notifier_block *nb,
 	case UBI_VOLUME_REMOVED:
 		ubiblock_remove(&nt->vi, true);
 		break;
+	case UBI_VOLUME_SHUTDOWN:
+		ubiblock_shutdown(&nt->vi);
+		break;
 	case UBI_VOLUME_RESIZED:
 		ubiblock_resize(&nt->vi);
 		break;
drivers/mtd/ubi/build.c +6 -1
index c153373c13dab..ccee4a28ffe97 100644
@@ -1088,7 +1088,6 @@ int ubi_detach_mtd_dev(int ubi_num, int anyway, bool have_lock)
 		return -EINVAL;
 
 	spin_lock(&ubi_devices_lock);
-	put_device(&ubi->dev);
 	ubi->ref_count -= 1;
 	if (ubi->ref_count) {
 		if (!anyway) {
@@ -1099,6 +1098,12 @@ int ubi_detach_mtd_dev(int ubi_num, int anyway, bool have_lock)
 		ubi_err(ubi, "%s reference count %d, destroy anyway",
 			ubi->ubi_name, ubi->ref_count);
 	}
+	spin_unlock(&ubi_devices_lock);
+
+	ubi_notify_all(ubi, UBI_VOLUME_SHUTDOWN, NULL);
+
+	spin_lock(&ubi_devices_lock);
+	put_device(&ubi->dev);
 	ubi_devices[ubi_num] = NULL;
 	spin_unlock(&ubi_devices_lock);
 
drivers/mtd/ubi/vmt.c +5 -0
index 2c867d16f89f7..eed4b57c61bda 100644
@@ -352,6 +352,11 @@ int ubi_remove_volume(struct ubi_volume_desc *desc, int no_vtbl)
 		err = -EBUSY;
 		goto out_unlock;
 	}
+	spin_unlock(&ubi->volumes_lock);
+
+	ubi_volume_notify(ubi, vol, UBI_VOLUME_SHUTDOWN);
+
+	spin_lock(&ubi->volumes_lock);
 	ubi->volumes[vol_id] = NULL;
 	spin_unlock(&ubi->volumes_lock);
 
include/linux/mtd/ubi.h +2 -0
index a529347fd75b2..562f92504f2b7 100644
@@ -192,6 +192,7 @@ struct ubi_device_info {
  *			or a volume was removed)
  * @UBI_VOLUME_RESIZED: a volume has been re-sized
  * @UBI_VOLUME_RENAMED: a volume has been re-named
+ * @UBI_VOLUME_SHUTDOWN: a volume is going to removed, shutdown users
  * @UBI_VOLUME_UPDATED: data has been written to a volume
  *
  * These constants define which type of event has happened when a volume
@@ -202,6 +203,7 @@ enum {
 	UBI_VOLUME_REMOVED,
 	UBI_VOLUME_RESIZED,
 	UBI_VOLUME_RENAMED,
+	UBI_VOLUME_SHUTDOWN,
 	UBI_VOLUME_UPDATED,
 };
 
Signature · 1 line
2.41.0
#5 lore raw

PATCH v2 6/7 mtd: ubi: populate ubi volume fwnode

In reply to Daniel Golle

Look for the 'volumes' subnode of an MTD partition attached to a UBI device and attach matching child nodes to UBI volumes. This allows UBI volumes to be referenced in device tree, e.g. for use as NVMEM providers.

---
 drivers/mtd/ubi/vmt.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)
drivers/mtd/ubi/vmt.c +31 -0
index eed4b57c61bda..3b997256cfba7 100644
@@ -124,6 +124,35 @@ static void vol_release(struct device *dev)
 	kfree(vol);
 }
 
+static struct fwnode_handle *find_volume_fwnode(struct ubi_volume *vol)
+{
+	struct fwnode_handle *fw_vols, *fw_vol;
+	const char *volname;
+	u32 reg;
+
+	fw_vols = device_get_named_child_node(vol->dev.parent->parent, "volumes");
+	if (!fw_vols)
+		return NULL;
+
+	fwnode_for_each_child_node(fw_vols, fw_vol) {
+		if (!fwnode_property_read_string(fw_vol, "volname", &volname) &&
+		    strncmp(volname, vol->name, vol->name_len))
+			continue;
+
+		/*
+		 * volume id (reg) in device tree greater than UBI_MAX_VOLUMES
+		 * can be used to match by volname only
+		 */
+		if (!fwnode_property_read_u32(fw_vol, "reg", &reg) &&
+		    reg < UBI_MAX_VOLUMES && vol->vol_id != reg)
+			continue;
+
+		return fw_vol;
+	}
+
+	return NULL;
+}
+
 /**
  * ubi_create_volume - create volume.
  * @ubi: UBI device description object
@@ -223,6 +252,7 @@ int ubi_create_volume(struct ubi_device *ubi, struct ubi_mkvol_req *req)
 	vol->name_len  = req->name_len;
 	memcpy(vol->name, req->name, vol->name_len);
 	vol->ubi = ubi;
+	device_set_node(&vol->dev, find_volume_fwnode(vol));
 
 	/*
 	 * Finish all pending erases because there may be some LEBs belonging
@@ -597,6 +627,7 @@ int ubi_add_volume(struct ubi_device *ubi, struct ubi_volume *vol)
 	vol->dev.class = &ubi_class;
 	vol->dev.groups = volume_dev_groups;
 	dev_set_name(&vol->dev, "%s_%d", ubi->ubi_name, vol->vol_id);
+	device_set_node(&vol->dev, find_volume_fwnode(vol));
 	err = device_register(&vol->dev);
 	if (err) {
 		cdev_del(&vol->cdev);
Signature · 1 line
2.41.0
#6 lore raw

PATCH v2 7/7 mtd: ubi: provide NVMEM layer over UBI volumes

In reply to Daniel Golle

In an ideal world we would like UBI to be used where ever possible on a NAND chip. And with UBI support in ARM Trusted Firmware and U-Boot it is possible to achieve an (almost-)all-UBI flash layout. Hence the need for a way to also use UBI volumes to store board-level constants, such as MAC addresses and calibration data of wireless interfaces.

Add UBI volume NVMEM driver module exposing UBI volumes as NVMEM providers. Allow UBI devices to have a "volumes" firmware subnode with volumes which may be compatible with "nvmem-cells".
Access to UBI volumes via the NVMEM interface at this point is read-only, and it is slow, opening and closing the UBI volume for each access due to limitations of the NVMEM provider API.

---
 drivers/mtd/ubi/Kconfig  |  12 +++
 drivers/mtd/ubi/Makefile |   1 +
 drivers/mtd/ubi/nvmem.c  | 189 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 202 insertions(+)
 create mode 100644 drivers/mtd/ubi/nvmem.c
drivers/mtd/ubi/Kconfig +12 -0
index 184118f9a2969..fb15d4549d55f 100644
@@ -104,4 +104,16 @@ config MTD_UBI_BLOCK
 
 	  If in doubt, say "N".
 
+config MTD_UBI_NVMEM
+	tristate "UBI virtual NVMEM"
+	default n
+	depends on NVMEM
+	help
+	  This option enables an additional driver exposing UBI volumes as NVMEM
+	  providers, intended for platforms where UBI is part of the firmware
+	  specification and used to store also e.g. MAC addresses or board-
+	  specific Wi-Fi calibration data.
+
+	  If in doubt, say "N".
+
 endif # MTD_UBI
drivers/mtd/ubi/Makefile +1 -0
index 543673605ca72..4b51aaf00d1a2 100644
@@ -7,3 +7,4 @@ ubi-$(CONFIG_MTD_UBI_FASTMAP) += fastmap.o
 ubi-$(CONFIG_MTD_UBI_BLOCK) += block.o
 
 obj-$(CONFIG_MTD_UBI_GLUEBI) += gluebi.o
+obj-$(CONFIG_MTD_UBI_NVMEM) += nvmem.o
drivers/mtd/ubi/nvmem.c new file +189 -0

189 lines not on this page · raw message

Signature · 5 lines
2.41.0

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/