linux-kernel - RE: [PATCH v3 06/10] mtd: intel-dg: wake card on operations

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] [day] [month] [year] [list]

Message-ID: <CY5PR11MB6366CBE2D1AA392AD3F745F7ED052@CY5PR11MB6366.namprd11.prod.outlook.com>
Date: Wed, 18 Dec 2024 15:58:35 +0000
From: "Usyskin, Alexander" <alexander.usyskin@...el.com>
To: "Poosa, Karthik" <karthik.poosa@...el.com>, "Vivi, Rodrigo"
	<rodrigo.vivi@...el.com>, Miquel Raynal <miquel.raynal@...tlin.com>
CC: Richard Weinberger <richard@....at>, Vignesh Raghavendra
	<vigneshr@...com>, "De Marchi, Lucas" <lucas.demarchi@...el.com>,
	Thomas Hellström <thomas.hellstrom@...ux.intel.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>,
	"Weil, Oren jer" <oren.jer.weil@...el.com>, "linux-mtd@...ts.infradead.org"
	<linux-mtd@...ts.infradead.org>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "intel-gfx@...ts.freedesktop.org"
	<intel-gfx@...ts.freedesktop.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 06/10] mtd: intel-dg: wake card on operations

> > >> @@ -474,20 +478,28 @@ static int intel_dg_mtd_erase(struct mtd_info
> > *mtd, struct erase_info *info)
> > >>   	total_len = info->len;
> > >>   	addr = info->addr;
> > >>
> > >> +	ret = pm_runtime_resume_and_get(mtd->dev.parent);
> > > on this, I really don't believe this is right and we should use
> > > the parent child relation ship in our favor and only have the mtd
> > > device to handle their own runtime pm...
> > I concur with Rodrigo. If the parent-child relationship is preserved,
> > the parent will resume before the child, eliminating the need to
> > explicitly wake the parent.
> > Please refer to https://docs.kernel.org/driver-api/pm/devices.html
> >
> > The ordering of the device hierarchy is defined by the order in which
> > devices get registered:
> > "a child can never be registered, probed or
> > resumed before its parent; "
> > and can’t be removed or suspended after that parent.
> > >
> 
> If so, I have to add patch for mtd subsystem to always have device for master
> initialized regardless of kernel flag.
> Only to initialize struct device, not to create full mtd node.
> 
> Miquel - are you agree to this?

I've looked deeply in the mtd code and there is some interesting discrepancy:
- the mtd partition creates device and puts parent of parent in its parent pointer if master does not exist
- the callbacks, like _write/_read/_erase receive master object pointer
Thus, we can't use good partition device for power management...

Maybe rewrite these callbacks to receive actual partition (huge change all over)?

> 
> - -
> Thanks,
> Sasha
>