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

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hello,

On 11/06/2025 at 10:52:36 GMT, "Usyskin, Alexander" <alexander.usyskin@intel.com> wrote:

>> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>> 
>> ----- Ursprüngliche Mail -----
>> > Von: "Miquel Raynal" <miquel.raynal@bootlin.com>
>> >> On 6/10/25 05:54, Richard Weinberger wrote:
>> >>> ----- Ursprüngliche Mail -----
>> >>>> Von: "Alexander Usyskin" <alexander.usyskin@intel.com>
>> >>>> Richard, I've reproduced your setup (modulo that I must load mtdram
>> manually)
>> >>>> and patch provided in this thread helps to fix the issue.
>> >>>> Can you apply and confirm?
>> >>> Yes, it fixes the issue here! :-)
>> >>>
>> >>
>> >> It doesn't seem to fix the issue if the partition data is in
>> >> devicetree.
>> >
>> > I had a look at the patch again. The whole mtd core makes assumptions on
>> > parenting, which is totally changed with this patch. There are so many
>> > creative ways this can break, I don't believe we are going to continue
>> > this route. I propose to revert the patch entirely for now. We need to
>> > find another approach, I'm sorry.
>> 
>> I think reverting is a valid option to consider if the issue turns out to be
>> a "back to the drawing board" problem.
>> 
>> > Alexander, can you please remind me what was your initial problem? I
>> > believe you needed to anchor runtime PM on the master device. Can you
>> > please elaborate again? Why taking the controller as source (the
>> > default, before your change) did not work? Also why was selecting
>> > MTD_PARTITIONED_MASTER not an option for you? I'm trying to get to the
>> > root of this change again, so we can find a solution fixing "the world"
>> > (fast) and in a second time a way to address your problem.
>> 
>> IIRC the problem is that depending on CONFIG_MTD_PARTITIONED_MASTER
>> won't fly as PM needs to work with any configuration.
>> And enforcing CONFIG_MTD_PARTITIONED_MASTER will break existing
>> setups because mtd id's will change.
>> 
>> On the other hand, how about placing the master device at the end
>> of the available mtd id space if CONFIG_MTD_PARTITIONED_MASTER=n?
>> A bit hacky but IMHO worth a thought.
>> 
>> Thanks,
>> //Richard
>
> The original problem was that general purpose OS never set
> CONFIG_MTD_PARTITIONED_MASTER and we need valid device tree
> to power management to work.
>
> We can return to V7 of this patch that only creates dummy master if
> CONFIG_MTD_PARTITIONED_MASTER is off.
> In this case the hierarchy remains the same.
>
> Miquel, can you re-review v7 and say if it worth to revert current version and
> put v7 instead?

After taking inspiration from Richard's wisdom on IRC, we have another
proposal. Let's drop the mtd_master class. We need an mtd device to be
the master device, we already have one but we cannot keep *at the
beginning* of the ID space under the CONFIG_MTD_PARTITIONED_MASTER=n
configuration to avoid breaking userspace. So let's keep the master
anyway, with the following specificities in the problematic case:
- id is allocated from the max value downwards (avoids messing with
  numbering)
- mtd device is simply hidden (same user experience as before)

Apparently this second point, while not natively supported, is something
the block world already does:
https://elixir.bootlin.com/linux/v6.15.1/source/include/linux/blkdev.h#L88

What do you think?

Thanks,
Miquèl