linux-kernel - Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

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:	Sat, 6 Dec 2008 09:07:26 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Greg KH <greg@...ah.com>, Ingo Molnar <mingo@...e.hu>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Len Brown <lenb@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Takashi Iwai <tiwai@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: [PATCH 1/3] PCI: Rework default handling of suspend and resume

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
> 
> Rework the handling of suspend and resume of PCI devices which have
> no drivers or the drivers of which do not provide any suspend-resume
> callbacks in such a way that their standard PCI configuration
> registers will be saved and restored with interrupts disabled.

Ok, I think this is good, but I _also_ think that we should do one more 
fix:

 - if a device uses the new-format suspend/resume structure, we should do 
   the low-level save-restore _unconditionally_ in the PCI layer.

Because apparently there is only a single user of the new format, and that 
single user got it wrong. So wouldn't it be much nicer to just _remove_ 
the code from the USB host controllers that does the save/restore thing.

Quite frankly, the USB code really does look wrong. Not just in that it 
enables the BAR's before restoring them, but on the suspend side it 
actually puts the device into D3_hot _before_ it then does the whole 
"pci_enable_wake()", which I'm not at all sure will necessarily work. I'm 
pretty sure that you should enable wakeup events _before_ going to sleep.

If the generic PCI layer unconditionally did the suspend as the last thing 
it does (and the resume as the first thing), then drivers couldn't do 
insane things like that, even by mistake.

Hmm?

				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/