linux-kernel - Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation callbacks (rev. 6)

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]

Date:	Tue, 1 Apr 2008 23:57:29 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Nigel Cunningham <ncunningham@...a.org.au>
Cc:	pm list <linux-pm@...ts.linux-foundation.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Greg KH <greg@...ah.com>, Len Brown <lenb@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	David Brownell <david-b@...bell.net>,
	Pavel Machek <pavel@....cz>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Oliver Neukum <oliver@...kum.org>
Subject: Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation callbacks (rev. 6)

On Tuesday, 1 of April 2008, Nigel Cunningham wrote:
> Hi Rafael etc.
> 
> On Tue, 2008-04-01 at 22:12 +0200, Rafael J. Wysocki wrote:
> > 'ext' means 'extended'.  The idea is that the 'extended' version will be used
> > by bus types / driver types that don't need to implement the _noirq callbacks.
> > Both the platform and PCI bus types generally allow drivers to use _noirq
> > callbacks, so they use 'struct pm_ext_ops', as well as their corresponding
> > driver types.
> 
> Do you mean to say in the first sentence "...that _do_ need to implement..."?

Yes, sorry.

> If not, then extended sounds like a misnomer and the two 
> sentences seem to contradict one another.
> 
> [...]
> 
> > > > + *	However, drivers may NOT assume anything about the availability of the
> > > > + *	user space at that time and it is not correct to request firmware from
> > > > + *	within @prepare() (it's too late to do that).
> > > 
> > > That doesn't sound good. It would be good to be able to get drivers to
> > > request firmware early in the process.
> > 
> > That will be possible when we drop the freezer.
> 
> Yeah, but right now, it seems to me to be a bogus limitation for drivers
> to have no way of automatically loading firmware when you're about to
> hibernate. (Of course I've since been reminded of the notifier chain -
> that should probably be mentioned here as the way of achieving this).

This is a tricky stuff, though, because the notifier is used for disabling the
user mode helpers too ...
 
> By the way, I'm going to go on record now as saying I think dropping the
> freezer is a silly idea. I'm therefore currently considering including
> the freezer in TuxOnice from the time it gets dropped from mainline. I
> know that will only make it less likely that TuxOnIce gets merged, but
> I've given up caring about that anyway - caring about merging is
> pointless when the people who decide if it gets merged don't care.

Well, I'm just not sure if dropping the freezer entirely will actually work,
but we won't know that if we don't try.

There's been a lot of pressure on going into this direction recently and
in principle it seems to be doable at least for suspend.  Hibernation is
another issue, but IMO it's better to focus on suspend first.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/