linux-kernel - Re: [linux-pm] [patch update 2 fix] PM: Introduce core framework for run-time PM of I/O 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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200906221739.34920.rjw@sisk.pl>
Date:	Mon, 22 Jun 2009 17:39:34 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Magnus Damm <magnus.damm@...il.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Greg KH <gregkh@...e.de>, LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	"Linux-pm mailing list" <linux-pm@...ts.linux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [linux-pm] [patch update 2 fix] PM: Introduce core framework for  run-time PM of I/O devices

On Monday 22 June 2009, Arjan van de Ven wrote:
> On Mon, 22 Jun 2009 16:27:29 +0900
> Magnus Damm <magnus.damm@...il.com> wrote:
> 
> > On Mon, Jun 22, 2009 at 3:43 PM, Arjan van de
> > Ven<arjan@...radead.org> wrote:
> > > On Mon, 22 Jun 2009 15:20:43 +0900
> > > Magnus Damm <magnus.damm@...il.com> wrote:
> > >
> > >> On Sat, Jun 20, 2009 at 11:30 PM, Alan
> > >> Stern<stern@...land.harvard.edu> wrote:
> > >> > Some more thoughts...
> > >> >
> > >> > Magnus, you might have some insights here.  It occurred to me
> > >> > that some devices can switch power levels very quickly, and the
> > >> > drivers might therefore want the runtime suspend and resume
> > >> > methods to be called as soon as possible, even in interrupt
> > >> > context.
> > >>
> > >> I'd like to call pm_request_suspend() from interrupt context. I
> > >> don't
> > >
> > > there are some really strong reasons to at least be able to call the
> > > resume function from an interrupt handler.... shared interrupts are
> > > one of them.
> > 
> > I suppose you mean that you need to resume the hardware device before
> > you can check if it has a pending interrupt source? If so then you
> > also mean that suspended hardware devices may generate interrupts, no?
> 
> yes and no. For the shared interrupt case.. no.
> but yes for the hw I have in mind (and on my desk ;-) that can happen
> as well from the device itself.

If that's PCI hardware (I guess it is ;-)), I'm not really sure if this
behavior is compliant with the specification.

Anyway, if the interrupt is not shared and the device can wake up fast enough,
we should be able to handle it.

Best,
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/