----- 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
