Re: Attempted summary of suspend-blockers LKML thread

[Alan Stern]

On Sat, 7 Aug 2010, Rafael J. Wysocki wrote:

> > Arguably not every PCI interrupt should be regarded as a wakeup event, so
> > I think we can simply say in the cases when that's necessary the driver should
> > be responsible for using pm_wakeup_event() or pm_stay_awake() / pm_relax() as
> > appropriate.
> > 
> > My patch only added it to the bus-level code which covered the PME-based
> > wakeup events that _cannot_ be handled by device drivers.

In other words, your bus-level changes were a necessary but not
sufficient start.  I can buy that.

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

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/