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: <CY5PR11MB63663382E44A258B0BAEF1BAED052@CY5PR11MB6366.namprd11.prod.outlook.com>
Date: Wed, 18 Dec 2024 07:38:17 +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?

- - 
Thanks,
Sasha


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ