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

[Usyskin, Alexander]

> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
> 
> Hello,
> 
> On 11/06/2025 at 10:52:36 GMT, "Usyskin, Alexander"
> <alexander.usyskin at intel.com> wrote:
> 
> >> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
> >>
> >> ----- Ursprüngliche Mail -----
> >> > Von: "Miquel Raynal" <miquel.raynal at bootlin.com>
> >> >> On 6/10/25 05:54, Richard Weinberger wrote:
> >> >>> ----- Ursprüngliche Mail -----
> >> >>>> Von: "Alexander Usyskin" <alexander.usyskin at 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

In general, it is fine for me - we have parent mtd initialized and participating
in power management.

I can't see how to bend idr_alloc to allocate from the end and corner case
of full idr range is also will be problematic.

- - 
Thanks,
Sasha