linux-kernel - Re: [PATCH 7/7] PCI PM: Let the core be more careful with respect to drivers using new framework

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: <200902050147.02632.rjw@sisk.pl>
Date:	Thu, 5 Feb 2009 01:47:01 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux PCI <linux-pci@...r.kernel.org>
Subject: Re: [PATCH 7/7] PCI PM: Let the core be more careful with respect to drivers using new framework

On Wednesday 04 February 2009, Benjamin Herrenschmidt wrote:
> 
> > For non-bridge devices without drivers the PCI PM core will disable
> > them and save their state on suspend.  During resume, it will put
> > them into D0, if necessary, restore their state (early) and reenable
> > them.
> 
> This is "without drivers" only or does it include devices that have a
> driver and no PM ops ?

It includes devices with drivers and without PM ops (either "legacy" or "new"),
the idea being that in the simplest cases the driver should not be required to
implement PM ops and the device should be handled nevertheless.

> In the later case, the worry is that the driver will potentially still
> take shared interrupts after you have disabled the device. I know the
> normal disable path only disables bus mastering, which is a GOOD
> thing :-) but the pcibios hook might do more here ...

I don't know about ppc, but on x86 the pcibios hook is only supposed to
disable the device's interrupt link.

> I would recommend only doing that disabling in the "noirq" phase of
> suspend to avoid problems here. Do you see any reason that wouldn't
> work ?

Potentially, calling into the AML interpreter.

When we implement the changes discussed in the "PCI PM: Restore standard
config registers of all devices early" thread, that part will end up in
suspend_noirq.

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/