Hi Daniel,
On 2026-08-23T19:12:43, Daniel Golle <[email protected]> wrote:
> cmd: ubi: create a ubi_blk device when attaching UBI
>
> A UBI volume can be reached as a partition on the ubi_blk block
> device, but that device is only bound from spinand_bind(), so it is
> missing on every other flash type (raw NAND, SPI-NOR, ...).
>
> Bind a ubi_blk device when a UBI partition is attached, unless one has
> already been created, parented to the MTD device UBI sits on. UBI
> volumes then become reachable as block-device partitions regardless of
> the underlying flash. The imagemap block path relies on this to read a
> UBI volume.
>
> Signed-off-by: Daniel Golle <[email protected]>
>
> cmd/ubi.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> diff --git a/cmd/ubi.c b/cmd/ubi.c
> @@ -670,6 +673,29 @@ int ubi_detach(void)
> + ubi_bind(ubi && ubi->mtd && ubi->mtd->dev ? ubi->mtd->dev : dm_root());
> +}
The return value from ubi_bind() is silently dropped, so a failed bind
(e.g. -ENOMEM) leaves ubi_part() reporting success while there is no
ubi_blk at all. Please propagate it, or at least log a warning.
> diff --git a/cmd/ubi.c b/cmd/ubi.c
> @@ -670,6 +673,29 @@ int ubi_detach(void)
> + /*
> + * A single ubi_blk device serves all volumes of the attached UBI
> + * device, the volume being selected through the block descriptor's
> + * hwpart. Bind one when UBI is attached -- unless a previous attach
> + * already did -- parented to the MTD device UBI sits on.
> + */
> + for (uclass_find_first_device(UCLASS_BLK, &dev); dev;
> + uclass_find_next_device(&dev)) {
> + if (dev->driver == DM_DRIVER_GET(ubi_blk))
> + return;
> + }
ubi_detach() doesn't unbind the ubi_blk, so after 'ubi part A; ubi
detach; ubi part B' the existing ubi_blk stays parented to A's MTD
device even though UBI now sits on B. Reads still work because
get_ubi_device() returns ubi_devices[0], but the DM tree is left with
a stale parent (and A's MTD isn't safe to remove). Either unbind in
ubi_detach(), or re-parent here when the target MTD has changed.
Also, walking every UCLASS_BLK to detect a single ubi_blk is awkward.
Since ubi_blk is always parented to an MTD device, iterating the
children of that parent e.g. with device_find_first_child_by_uclass()
(or tracking the bound udevice in a static pointer) would be more
direct and avoid poking dev->driver.
Regards,
Simon
