[PATCH v6 01/11] mtd: core: always create master device

Guenter Roeck linux at roeck-us.net
Mon Jun 9 15:53:04 UTC 2025


On 6/9/25 08:16, Usyskin, Alexander wrote:
>> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>>
>> On 6/9/25 05:23, Usyskin, Alexander wrote:
>>>> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>>>>
>>>>
>>>>>>>> Several of my qemu boot tests fail to boot from mtd devices with this
>>>> patch
>>>>>>>> in the mainline kernel. Reverting it fixes the problem. As far as I can
>>>>>>>> see this affects configurations with
>>>> CONFIG_MTD_PARTITIONED_MASTER=y
>>>>>>>> when
>>>>>>>> trying to boot from an mtd partition other than mtdblock0, with the
>>>>>>>> mtd partition data in devicetree (.../aspeed/openbmc-flash-
>> layout.dtsi).
>>>>>>>> Is there a guidance describing the changed behavior, by any chance,
>>>>>>>> and how the boot command line now needs to look like when using
>> one
>>>> of
>>>>>>>> the flash partitions as root file system ?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Guenter
>>>>>>>
>>>>>>> I've tried to make is as transparent as possible for the existing users.
>>>>>>> Only change is that now every partition has master that is not
>> partitioned.
>>>>>>> Is the CONFIG_MTD_PARTITIONED_MASTER=n fixed the problem for
>> you?
>>>>>> No change is expected, can you please describe the devices that you
>>>>>> observe with and without the patch? Maybe there is something wrong in
>>>>>> the core logic.
>>>>>>
>>>>>
>>>>> I am trying to boot supermicro-x11spi-bmc in qemu from flash partition 6.
>>>>> The qemu command line is something like
>>>>>
>>>>>       qemu-system-arm -M supermicro-x11spi-bmc,fmc-
>>>> model=n25q256a13,spi-model=n25q256a13 \
>>>>> 	-kernel arch/arm/boot/zImage -no-reboot -snapshot \
>>>>> 	-audio none \
>>>>> 	-drive file=/tmp/flash,format=raw,if=mtd,index=1 \
>>>>> 	-nic user \
>>>>> 	--append "root=/dev/mtdblock6 rootwait console=ttyS4,115200
>>>> earlycon=uart8250,mmio32,0x1e784000,115200n8" \
>>>>> 	-dtb arch/arm/boot/dts/aspeed/aspeed-bmc-supermicro-x11spi.dtb
>>>> \
>>>>> 	-nographic -monitor null -serial stdio
>>>>>
>>>>> This is with aspeed_g5_defconfig. Note that the flash models need to be
>>>> specified.
>>>>> The default flashes are no longer recognized when booting from qemu
>> since
>>>> commit
>>>>> 947c86e481a0 ("mtd: spi-nor: macronix: Drop the redundant flash info
>>>> fields").
>>>>>
>>>>> The above only works with this patch reverted (or with v6.15 and older, of
>>>> course).
>>>>>
>>>>> Guenter
>>>>
>>>> Alexander, can you please investigate? We need a fix because Guenter
>>>> might not be the only affecter user. Otherwise this patch can't stand,
>>>> unfortunately.
>>>>
>>>> Thanks,
>>>> Miquèl
>>>
>>> Maybe something is moved, and it is not /dev/mtdblock6 now.
>>>
>>
>> With this patch:
>>
>> # ls -l /dev/*mtd*
>> crw-------    1 root     root       90,   0 Jan  1 00:00 /dev/mtd0
>> crw-------    1 root     root       90,   1 Jan  1 00:00 /dev/mtd0ro
>> crw-------    1 root     root       90,   2 Jan  1 00:00 /dev/mtd1
>> crw-------    1 root     root       90,   3 Jan  1 00:00 /dev/mtd1ro
>> crw-------    1 root     root      244,   0 Jan  1 00:00 /dev/mtd_master0
>> crw-------    1 root     root      244,   1 Jan  1 00:00 /dev/mtd_master1
>> brw-------    1 root     root       31,   0 Jan  1 00:00 /dev/mtdblock0
>> brw-------    1 root     root       31,   1 Jan  1 00:00 /dev/mtdblock1
>> ~ # ls /proc/mtd
>> /proc/mtd
>> ~ # cat /proc/mtd
>> dev:    size   erasesize  name
>> mtd0: 02000000 00010000 "bmc"
>> mtd1: 02000000 00010000 "pnor"
>>
>> After reverting it:
>>
>> # ls -l /dev/mtd*
>> crw-------    1 root     root       90,   0 Jan  1 00:00 /dev/mtd0
>> crw-------    1 root     root       90,   1 Jan  1 00:00 /dev/mtd0ro
>> crw-------    1 root     root       90,   2 Jan  1 00:00 /dev/mtd1
>> crw-------    1 root     root       90,   3 Jan  1 00:00 /dev/mtd1ro
>> crw-------    1 root     root       90,   4 Jan  1 00:00 /dev/mtd2
>> crw-------    1 root     root       90,   5 Jan  1 00:00 /dev/mtd2ro
>> crw-------    1 root     root       90,   6 Jan  1 00:00 /dev/mtd3
>> crw-------    1 root     root       90,   7 Jan  1 00:00 /dev/mtd3ro
>> crw-------    1 root     root       90,   8 Jan  1 00:00 /dev/mtd4
>> crw-------    1 root     root       90,   9 Jan  1 00:00 /dev/mtd4ro
>> crw-------    1 root     root       90,  10 Jan  1 00:00 /dev/mtd5
>> crw-------    1 root     root       90,  11 Jan  1 00:00 /dev/mtd5ro
>> crw-------    1 root     root       90,  12 Jan  1 00:00 /dev/mtd6
>> crw-------    1 root     root       90,  13 Jan  1 00:00 /dev/mtd6ro
>> brw-------    1 root     root       31,   0 Jan  1 00:00 /dev/mtdblock0
>> brw-------    1 root     root       31,   1 Jan  1 00:00 /dev/mtdblock1
>> brw-------    1 root     root       31,   2 Jan  1 00:00 /dev/mtdblock2
>> brw-------    1 root     root       31,   3 Jan  1 00:00 /dev/mtdblock3
>> brw-------    1 root     root       31,   4 Jan  1 00:00 /dev/mtdblock4
>> brw-------    1 root     root       31,   5 Jan  1 00:00 /dev/mtdblock5
>> brw-------    1 root     root       31,   6 Jan  1 00:00 /dev/mtdblock6
>> ~ # cat /proc/mtd
>> dev:    size   erasesize  name
>> mtd0: 02000000 00010000 "bmc"
>> mtd1: 00060000 00010000 "u-boot"
>> mtd2: 00020000 00010000 "u-boot-env"
>> mtd3: 00440000 00010000 "kernel"
>> mtd4: 01740000 00010000 "rofs"
>> mtd5: 00400000 00010000 "rwfs"
>> mtd6: 02000000 00010000 "pnor"
>>
>> I am trying to boot from "pnor". It looks like the partition data (from
>> devicetree)
>> is now ignored. mtdblock6 used to be the second flash.
>>
>> Guenter
> 
> Is this with CONFIG_MTD_PARTITIONED_MASTER?
> 

Yes

> I think that mtd_is_partition is ambiguous now.
> We always have master partition when CONFIG_MTD_PARTITIONED_MASTER
> is enabled and parent check is useless.
> We must check grandparent in this case.
> Miquel, am I right?
> 
> We can return to older patch version that have created partition
> instead of the master device.
> Or try to fix mtd_is_partition, like below.
> Guenter, is below patch helps?
> 
No, it does not make a difference. Partitions are still not created.

Guenter



More information about the Intel-gfx mailing list