Message-ID: <87y0tytjmj.fsf@bootlin.com>
Date: Wed, 11 Jun 2025 16:53:24 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: "Usyskin, Alexander" <alexander.usyskin@...el.com>
Cc: Richard Weinberger <richard@....at>,  Guenter Roeck
 <linux@...ck-us.net>,  Vignesh Raghavendra <vigneshr@...com>,  "De Marchi,
 Lucas" <lucas.demarchi@...el.com>,  Thomas Hellström
 <thomas.hellstrom@...ux.intel.com>,  "Vivi, Rodrigo"
 <rodrigo.vivi@...el.com>,  Maarten Lankhorst
 <maarten.lankhorst@...ux.intel.com>,  Maxime Ripard <mripard@...nel.org>,
  Thomas Zimmermann <tzimmermann@...e.de>,  David Airlie
 <airlied@...il.com>,  Simona Vetter <simona@...ll.ch>,  Jani Nikula
 <jani.nikula@...ux.intel.com>,  Joonas Lahtinen
 <joonas.lahtinen@...ux.intel.com>,  Tvrtko Ursulin <tursulin@...ulin.net>,
  "Poosa, Karthik" <karthik.poosa@...el.com>,  "Abliyev, Reuven"
 <reuven.abliyev@...el.com>,  "Weil, Oren jer" <oren.jer.weil@...el.com>,
  linux-mtd <linux-mtd@...ts.infradead.org>,  "DRI mailing list"
 <dri-devel@...ts.freedesktop.org>,  intel-gfx
 <intel-gfx@...ts.freedesktop.org>,  linux-kernel
 <linux-kernel@...r.kernel.org>
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@...el.com> wrote:

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

Powered by blists - more mailing lists