linux-kernel - Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

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: <alpine.LFD.2.00.0812051411400.3386@nehalem.linux-foundation.org>
Date:	Fri, 5 Dec 2008 14:14:23 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Frans Pop <elendil@...net.nl>, Greg KH <greg@...ah.com>,
	Ingo Molnar <mingo@...e.hu>, jbarnes@...tuousgeek.org,
	lenb@...nel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	tiwai@...e.de, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Regression from 2.6.26: Hibernation (possibly suspend) broken
 on Toshiba R500 (bisected)



On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> 
> Well, actually I think we should go further and save the standard config
> registers of _all_ PCI devices in the _late() callbacks (ie. with interrupts
> disabled) and restore them in the _early() callbacks.

That would certainly simplify the code. 

> I don't really understand why pci_restore_state() is not called by the core
> and every single driver calls it by itself.

The idea was to allow PCI drivers to override it if they wanted to.

That said, the ones that do their own state restore generally do it wrong 
(eg the USB host controllers doing things in the wrong order and enabling 
the device before having actually written back the BAR values), so it's 
arguably broken to let drivers override it.

> IOW, I would split the resume of PCI devices into two parts, the first of
> which will call pci_restore_state() with interrupts disabled and the second
> will do the remaining stuff.

I would definitely not disagree with that - leave the regular 
"suspend/resume" callbacks for purely higher-level actions. It would 
interesting to hear what it does for you.

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