Wire up device parents of UBI devices and ubiblock devices (UBI volume
devices are already correctly wired to their parent UBI device). This
makes more sense than having UBI devices free-standing in
/sys/devices/virtual/ubi/ without any connection to their parent MTD
device, and ubiblock devices in /sys/devices/virtual/block/ which would
be better hosted by the UBI volume device they belong to.
The purpose of these changes is to allow downstream tools to more
easily identify UBI<->hardware relationship, and potentially also
improve power management and scheduling performance in future.
Daniel Golle (2):
mtd: ubi: wire-up parent MTD device
mtd: ubi: block: wire-up device parent
drivers/mtd/ubi/block.c | 2 +-
drivers/mtd/ubi/build.c | 1 +
drivers/mtd/ubi/kapi.c | 1 +
include/linux/mtd/ubi.h | 1 +
4 files changed, 4 insertions(+), 1 deletion(-)
base-commit: e45fb347b630ee76482fe938ba76cf8eab811290
--
2.39.0
Wire up the device parent pointer of UBI devices to their lower MTD
device, typically an MTD partition or whole-chip device.
The most noticeable change is that in sysfs, previously ubi devices
would be could in /sys/devices/virtual/ubi while after this change they
would be correctly attached to their parent MTD device, e.g.
/sys/devices/platform/1100d000.spi/spi_master/spi1/spi1.0/mtd/mtd2/ubi0.
Locating UBI devices using /sys/class/ubi/ of course still works as
well.
Signed-off-by: Daniel Golle <[email protected]>
---
drivers/mtd/ubi/build.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index 5e90a4423b699..0904eb40c95fa 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -915,6 +915,7 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num,
ubi->dev.release = dev_release;
ubi->dev.class = &ubi_class;
ubi->dev.groups = ubi_dev_groups;
+ ubi->dev.parent = &mtd->dev;
ubi->mtd = mtd;
ubi->ubi_num = ubi_num;
--
2.39.0
ubiblock devices were previously only identifyable by their name, but
not connected to their parent UBI volume device e.g. in sysfs.
Properly parent ubiblock device as descendant of a UBI volume device
to reflect device model hierachy.
Signed-off-by: Daniel Golle <[email protected]>
---
drivers/mtd/ubi/block.c | 2 +-
drivers/mtd/ubi/kapi.c | 1 +
include/linux/mtd/ubi.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
index d725215ae66e5..e99b29ba48dc4 100644
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -455,7 +455,7 @@ int ubiblock_create(struct ubi_volume_info *vi)
list_add_tail(&dev->list, &ubiblock_devices);
/* Must be the last step: anyone can call file ops from now on */
- ret = add_disk(dev->gd);
+ ret = device_add_disk(vi->dev, dev->gd, NULL);
if (ret)
goto out_destroy_wq;
diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c
index 0fce99ff29b58..5db653eacbd45 100644
--- a/drivers/mtd/ubi/kapi.c
+++ b/drivers/mtd/ubi/kapi.c
@@ -79,6 +79,7 @@ void ubi_do_get_volume_info(struct ubi_device *ubi, struct ubi_volume *vol,
vi->name_len = vol->name_len;
vi->name = vol->name;
vi->cdev = vol->cdev.dev;
+ vi->dev = &vol->dev;
}
/**
diff --git a/include/linux/mtd/ubi.h b/include/linux/mtd/ubi.h
index 7d48ea368c5e5..a529347fd75b2 100644
--- a/include/linux/mtd/ubi.h
+++ b/include/linux/mtd/ubi.h
@@ -110,6 +110,7 @@ struct ubi_volume_info {
int name_len;
const char *name;
dev_t cdev;
+ struct device *dev;
};
/**
--
2.39.0
Hi!
I've only recently noticed that this series is marked as 'Accepted' in
patchwork. However, I fail to find the commits in any public linux
tree, nor has patchwork sent the usual notification email informing me
about it being accepted.
Can it be that it has slipped under the table (or even the carpet)
somehow?
Please let me know if there is anything wrong with this series and/or
if I should re-submit it, or if I shall just wait for it to surface in
linux-mtd or linux-next.
Thank you!
Best regards
Daniel
On Thu, Dec 22, 2022 at 07:32:46PM +0000, Daniel Golle wrote:
> Wire up device parents of UBI devices and ubiblock devices (UBI volume
> devices are already correctly wired to their parent UBI device). This
> makes more sense than having UBI devices free-standing in
> /sys/devices/virtual/ubi/ without any connection to their parent MTD
> device, and ubiblock devices in /sys/devices/virtual/block/ which would
> be better hosted by the UBI volume device they belong to.
>
> The purpose of these changes is to allow downstream tools to more
> easily identify UBI<->hardware relationship, and potentially also
> improve power management and scheduling performance in future.
>
> Daniel Golle (2):
> mtd: ubi: wire-up parent MTD device
> mtd: ubi: block: wire-up device parent
>
> drivers/mtd/ubi/block.c | 2 +-
> drivers/mtd/ubi/build.c | 1 +
> drivers/mtd/ubi/kapi.c | 1 +
> include/linux/mtd/ubi.h | 1 +
> 4 files changed, 4 insertions(+), 1 deletion(-)
>
>
> base-commit: e45fb347b630ee76482fe938ba76cf8eab811290
> --
> 2.39.0
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
----- Ursprüngliche Mail -----
> I've only recently noticed that this series is marked as 'Accepted' in
> patchwork. However, I fail to find the commits in any public linux
> tree, nor has patchwork sent the usual notification email informing me
> about it being accepted.
>
> Can it be that it has slipped under the table (or even the carpet)
> somehow?
>
> Please let me know if there is anything wrong with this series and/or
> if I should re-submit it, or if I shall just wait for it to surface in
> linux-mtd or linux-next.
The patches are in linux-ubifs #next and in linux-next itself.
See:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=05b8773ca33253ea562be145cf3145b05ef19f86
So, all good. :-)
Thanks,
//richard