linux-kernel - RE: [PATCH v6 01/11] mtd: core: always create master device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CY5PR11MB6366DA38B20B29C1662BDC76ED74A@CY5PR11MB6366.namprd11.prod.outlook.com>
Date: Thu, 12 Jun 2025 10:01:49 +0000
From: "Usyskin, Alexander" <alexander.usyskin@...el.com>
To: Miquel Raynal <miquel.raynal@...tlin.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

> 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

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