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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 28 Jul 2014 01:08:58 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Linux PCI <linux-pci@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [PATCH] PCI / PM: Make PCIe PME interrupts wake up from "freeze" sleep state

On Thursday, July 24, 2014 05:36:28 PM Rafael J. Wysocki wrote:
> On Thursday, July 24, 2014 03:42:41 PM Peter Zijlstra wrote:
> 
> [...]
> 
> > 
> > So with this patch on:
> > 
> >   http://marc.info/?l=3Dlinux-kernel&m=3D140620918218199
> > 
> > This will not work on my machine, because aerdrv is requesting the same
> > irq.
> > 
> > Now I've not a f'cking clue what aerdrv is, and whether it too wants
> > NO_SUSPEND on or not.
> > 
> > But if I make it also request NO_SUSPEND it all starts working.
> 
> OK, so can you please test the updated patch below?
> 
> Rafael
> 
> ---
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> Subject: PCI / PM: Make PCIe PME interrupts wake up from "freeze" sleep state
> 
> The "freeze" sleep state, also known as suspend-to-idle, is entered
> without taking nonboot CPUs offline, right after devices have been
> suspended.  It works by waiting for at least one wakeup source object
> to become "active" as a result of handling a hardware interrupt.
> 
> Of course, interrupts supposed to be able to wake up the system from
> suspend-to-idle cannot be disabled by suspend_device_irqs() and their
> interrupt handlers must be able to cope with interrupts coming after
> all devices have been suspended.  In that case, they only need to
> call __pm_wakeup_event() for a single wakeup source object without
> trying to access hardware (that will be resumed later as part of
> the subsequent system resume).
> 
> Make PCIe PME interrupts work this way.
> 
> Register an additional wakeup source object for each PCIe PME
> service device.  That object will be used to generate wakeups from
> suspend-to-idle.
> 
> Add IRQF_NO_SUSPEND to PME interrupt flags.  This will make
> suspend_device_irqs() to ignore PME interrupts, but that's OK,
> because the PME interrupt handler is suspend-aware anyway and
> can cope with interrupts coming during system suspend-resume.
> Unfortunately, that requires the AER service driver to pass
> IRQF_NO_SUSPEND when requesting its IRQ which may be shared with
> the PME interrupt and to make that safe, simple suspend/resume
> routines need to be added to the AER driver.
> 
> During system suspend, while suspending the PME service for given
> port, walk the bus below that port and see if any devices on that
> bus are configured for wakeup.  If so, do not disable the PME
> interrupt, but only set a "suspend level" for the service to
> "wakeup" and make the interrupt handler behave in a special way,
> which is to call __pm_wakeup_event() with the service's wakeup
> source object as the first argument whenever the interrupt is
> triggered.
> 
> The "suspend level" is cleared while resuming the PME service.
> 
> This change allows Wake-on-LAN to be used for wakeup from
> suspend-to-idle on my MSI Wind tesbed netbook.

Hi Bjorn,

There will be a new version of this, please ignore for now.

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/

Powered by blists - more mailing lists