[PATCH 1/9] mtd: bind an mtd_blk device for non-NAND MTD masters

[Simon Glass]

Hi Daniel,

On 2026-08-23T19:12:43, Daniel Golle <daniel at makrotopia.org> wrote:
> mtd: bind an mtd_blk device for non-NAND MTD masters
>
> Only the SPI-NAND bind path currently creates an mtd_blk block device,
> so a bare NOR (parallel NOR, SPI-NOR, ...) has no block-device access
> at all. Bind an mtd_blk device for every non-NAND MTD master when
> CONFIG_MTD_BLOCK is enabled, so its partitions become reachable
> through the block layer (and thus by bootstd, imagemap, ...).
>
> NAND is excluded on purpose: it needs UBI, which brings its own block
> device. Partitions inherit the master's block device via the "mtd"
> partition type, so only masters are bound.
>
> mtd_bind() keeps a pointer to the passed mtd_info pointer (SPI-NAND
> fills it after bind), so the generic caller provides a small heap slot
> that lives as long as the block device; an MTD master is never removed
> in practice.
>
> Signed-off-by: Daniel Golle <daniel at makrotopia.org>
>
> drivers/mtd/mtdcore.c | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)

> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> @@ -494,6 +494,30 @@ int add_mtd_device(struct mtd_info *mtd)
> +             struct mtd_info **mtdp = kmalloc(sizeof(*mtdp), GFP_KERNEL);
> +
> +             if (mtdp) {
> +                     *mtdp = mtd;
> +                     mtd_bind(mtd->dev, mtdp);
> +             }

Two issues. The return value from mtd_bind() is dropped, so on failure
mtdp is leaked (mtd_bind() only pr_err()s and returns; it doesn't free
what was passed in). And if kmalloc() returns NULL the block device is
silently not created, with no hint why partitions are unreachable.
Please log a warning in both paths and free mtdp on the mtd_bind()
failure path.

> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> @@ -494,6 +494,30 @@ int add_mtd_device(struct mtd_info *mtd)
> +              * mtd_bind() keeps a pointer to the passed mtd_info pointer, so
> +              * it needs storage that lives as long as the block device; the
> +              * MTD master is never removed in practice, so a small heap slot
> +              * is fine.
> +              */

The pointer-to-pointer indirection only exists because SPI-NAND fills
its mtd in after bind. Every other caller (including this one) already
knows the mtd, so the heap slot is pure overhead and, as the comment
concedes, leaks if the master is ever removed. Since you're touching
this path anyway, how about a second helper (say
mtd_bind_master(struct udevice *, struct mtd_info *)) that stashes the
mtd pointer itself, and leave the double-indirection variant to the
one caller that needs it. What do you think?

Regards,
Simon