linux-kernel - Re: PME via interrupt or SCI mechanism?

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:	Mon, 26 Sep 2011 16:48:35 -0700
From:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: PME via interrupt or SCI mechanism?

On Tue, Sep 27, 2011 at 12:20:26AM +0200, Rafael J. Wysocki wrote:
> On Sunday, September 25, 2011, Rafael J. Wysocki wrote:
> > On Thursday, September 22, 2011, Sarah Sharp wrote:
> > > On Mon, Sep 19, 2011 at 11:43:33PM +0200, Rafael J. Wysocki wrote:
> > Without looking at the tables at the moment (I'll do that later),
> > I think that they are missing the information that GPE 0D is a wakeup
> > GPE for the xHCI device.
> 
> The DSDT appears to contain that information, so I'm not sure what's
> going on.  Perhaps you can put a debug printk into acpi_dev_run_wake()
> to see if that function is called for the xHCI controllers?

I put a printk in acpi_dev_run_wake(), and that shows up in the original
dmesg I sent:

Sep 22 10:47:09 talon kernel: [ 2026.211933] xhci_hcd 0000:00:14.0: acpi_pci_run_wake - enable dev wake
Sep 22 10:47:09 talon kernel: [ 2026.211936] acpi device:34: acpi_dev_run_wake - enable dev wake
Sep 22 10:47:09 talon kernel: [ 2026.211955] acpi device:34: acpi_dev_run_wake - return -19

The patch I've been using for adding debugging to the PCI and ACPI code
is attached.  I've been adding printks willy-nilly to try to understand
what's going on.

> > > In digging through the ACPI code, I noticed that acpi_bus_get_flags()
> > > looks for the ACPI methods _PR0 or _PS0 and sets
> > > device->flags.power_manageable to 1 if either of those methods are
> > > successfully invoked.  When I deassembled the ACPI tables, I didn't see
> > > either method for any of the USB host controllers in the system.
> 
> However, the power_manageable flag only indicates that the device can
> be put into low-power states through ACPI methods, it shouldn't have
> any effect on the wakeup settings.

Ok, good to know.

> > > device->flags.power_manageable is checked later when the runtime PM
> > > system attempts to put the PCI device into a lower state, but it seems
> > > to be ignored?  Is it supposed to be ignored?
> > 
> > Hmm, not really.  I'll have a look at that later.
> 
> It is used to decide whether or not to call __acpi_bus_set_power(), AFAICS.
> If it is not set, this function is not called, which is OK.  Still,
> devices for which it is not set may be put into low-power states and may
> generate wakeup signals.
> 
> For many PCI devices there are two possible power management interfaces,
> the native one and the ACPI-based one.  All of the modern devices support
> the native power management interface, so they can be put into low-power
> states even if the ACPI-based interface is missing for them (which is the
> case for your USB controllers).  For those devices, if the ACPI-based
> interface is not present, we simply use the native one only.

So if I understand you correctly, the kernel can use the native PCI power
management interface to put the PCI device into a lower power state...

> As far as wakeup is concerned, we should enable them to generate PME
> using the native interface and in addition to it we should use ACPI to
> enable the wakeup GPEs that are supposed to be triggered in response to
> the PME signals.

...but the kernel ACPI core will still be watching for the SCI that the
firmware generates on a PME wakeup?  Correct?

Is the native PCI power management interface you're referring to
implemented through the PCIe PME driver?  Because this particular host
controller is a PCIe device, not a PCI device.  I added some debug
statements to drivers/pci/pcie/pme.c, but the dmesg shows that none of
them got called.

> This apparently doesn't work correctly on your system and we need to figure
> out why.

Ok.  Do you have suggestions for any tests I can run or debugging
statements to add?  I'm really not an ACPI expert and I've been
basically fumbling in the dark.

Sarah Sharp

View attachment "pci-acpi-debugging.patch" of type "text/x-diff" (24358 bytes)