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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 8 Aug 2010 15:07:37 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Arve Hjønnevåg <arve@...roid.com>,
	Matthew Garrett <mjg59@...f.ucam.org>, <david@...g.hm>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	<linux-pm@...ts.linux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <pavel@....cz>,
	<florian@...kler.org>, <swetland@...gle.com>,
	<peterz@...radead.org>, <tglx@...utronix.de>,
	<alan@...rguk.ukuu.org.uk>
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Sun, 8 Aug 2010, Rafael J. Wysocki wrote:

> > > Also please note that it depends a good deal on the definition of a "wakeup
> > > event".  Under the definition used when my patch was being developed, ie. that
> > > wakeup events are the events that would wake up the system from a sleep state,
> > > PCI interrupts cannot be wakeup events, unless the given device remains in the
> > > full power state although the system has been suspended (standard PCI devices
> > > are not allowed to generate signals except for PME from low-power states).
> > 
> > Um, what do you mean by "event"?  Let's take a concrete example.  
> > Suppose you have a system where you want USB plug or unplug events to
> > cause a wakeup.  This is relevant to the discussion at hand if your USB
> > host controller is a PCI device.
> > 
> > By your reckoning, a plug or unplug event that occurs while the system
> > is asleep would be a wakeup event by definition.  And yet you say that
> > the same plug or unplug event occurring while the controller was at
> > full power would not count as a wakeup event?  And in particular, it 
> > should not prevent the system from suspending before the event can be
> > fully processed?  That doesn't make sense.  The same event is the same 
> > event, regardless of the context in which it occurs.  If it is treated 
> > as a wakeup event in context then it should be treated as a wakeup 
> > event in other contexts too.
> 
> In this example the event is not a PCI interrupt itself, which is a consqeuence
> of the event, but the USB plug-unplug.  So, whoever detects the plug-unplug
> should use pm_stay_awake() or pm_wakeup_event().  That may be an
> interrupt handler of a PCI USB controller, so if that is the case, the
> controller driver probably should use one of these functions in its interrupt
> handler.  Still, that by no measn implies that _every_ PCI interrupt should in
> principle be regarded as a wakeup event.

Okay, agreed.  I just wanted you to grant that some PCI interrupts
should be treated like wakeup events even if they don't actually wake
the system up from a sleep state.  The "PCI interrupts cannot be wakeup 
events" statement is a little strong.

Alan Stern

--
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