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