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
