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: <1612313571.134371311.1749637592940.JavaMail.zimbra@nod.at>
Date: Wed, 11 Jun 2025 12:26:32 +0200 (CEST)
From: Richard Weinberger <richard@....at>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: Guenter Roeck <linux@...ck-us.net>, 
	Alexander Usyskin <alexander.usyskin@...el.com>, 
	Vignesh Raghavendra <vigneshr@...com>, 
	Lucas De Marchi <lucas.demarchi@...el.com>, 
	Thomas Hellström <thomas.hellstrom@...ux.intel.com>, 
	Rodrigo Vivi <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>, 
	Karthik Poosa <karthik.poosa@...el.com>, 
	Reuven Abliyev <reuven.abliyev@...el.com>, 
	Oren Weil <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

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