linux-kernel - [RFD] Asynchronous suspend/resume of PCI devices

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-next>] [day] [month] [year] [list]

Message-Id: <200912200031.38775.rjw@sisk.pl>
Date:	Sun, 20 Dec 2009 00:31:38 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Linux PCI <linux-pci@...r.kernel.org>
Cc:	Greg KH <gregkh@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Alan Stern <stern@...land.harvard.edu>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg@...hat.com>
Subject: [RFD] Asynchronous suspend/resume of PCI devices

Hi,

I'd like to know your opinions about the viability of suspending and resuming
PCI devices asynchronously during system-wide PM transitions (suspend to RAM
and hibernation).

Linus says it's generally dangerous, because some PCI devices may indirectly
depend on the others, but if that's the case, I wonder if we really can power
manage PCI devices at run time.

It follows from my experiments that suspending and resuming PCI devices
asynchronously doesn't lead to problems as long as we make sure that every
PCI device is suspended before and resumed after its ACPI "shadow" partner.
However, I'm not sure if this is generally correct.

What are possible problems we can run into while doing asynchronous suspend
and resume of PCI devices?  What do we need to do in general to avoid that
problems?

Please tell me what you think.

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/