linux-kernel - RE: [PATCH 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: <CY5PR11MB63661AF635C8A98EF82861CCED3E2@CY5PR11MB6366.namprd11.prod.outlook.com>
Date: Wed, 11 Dec 2024 09:46:52 +0000
From: "Usyskin, Alexander" <alexander.usyskin@...el.com>
To: Miquel Raynal <miquel.raynal@...tlin.com>, "Poosa, Karthik"
	<karthik.poosa@...el.com>
CC: "Vivi, Rodrigo" <rodrigo.vivi@...el.com>, "Gupta, Anshuman"
	<anshuman.gupta@...el.com>, "Deak, Imre" <imre.deak@...el.com>, "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 06/10] mtd: intel-dg: wake card on operations

Adding Kartihik

> Subject: Re: [PATCH 06/10] mtd: intel-dg: wake card on operations
> 
> Hi Alexander,
> 
> Please reduce the context when answering, otherwise it's hard to find
> all places where you commented.
> 
> >> > > > That's the part that I'm not sure if I agree. if I remember from some
> >> > > > experiments in the past,
> >> > > > when you call to wake up the child, the parent will wakeup first
> anyway.
> >> > > >
> >> > > The child (mtd device) does not exist at this point of time.
> >> > > To create MTD device, the partition table should be provided
> >> > > and it read directly from flash that should be powered to do read.
> >> >
> >> > I don't understand... you have the mtd->dev at this point... this is
> >> > the one you should be touching, not the mtd->dev.parent... even at the
> >> > probe, but moreover on everywhere else as well.
> >> >
> >>
> >> At the probe time I do not have dev->mtd, but now I see you point here.
> >> I'll separate power management:
> >> - probe before dev->mtd creation will use aux_dev->dev (that will be mtd-
> >> >dev.parent later)
> >> - mtd functions will use mtd->dev
> >>
> >> Is this that you have in mind?
> >
> > I've tried it and found out that mtd->dev is not initialized if partitions are
> present [1].
> > Miquel - this may be the reason why other mtd drivers use pci or platform
> > devices to manage runtime pm.
> > Or I have missed something?
> 
> Please keep in mind there is _a lot_ of history behind mtd, and
> sometimes choices from the past cannot be simply "fixed" without
> breaking userspace. The problem with mtd is that the "mtd" structure
> defines nothing with precision. It may be a controller, a chip, a
> partition, or whatever mix of those. In this particular case, I believe
> you are mentioning the KEEP_PARTITIONED_MASTER configuration, which by
> default is unset, which means you'll loose the "top level" mtd device?
> 
> However in general I believe the "framework" struct device is maybe less
> relevant than the "bus" struct device when it comes to runtime PM, so
> actually I would eventually expect this device to be used?
> 

So, we can't reliable use the mtd here and should hook power management
on mtd->parent, as done in the patch.
Not sure if there any value in extending mtd to support runtime power management.

- - 
Thanks,
Sasha


> > [1] https://elixir.bootlin.com/linux/v6.12-
> rc6/source/drivers/mtd/mtdcore.c#L1078
> 
> Thanks,
> Miquèl