[PATCH 1/5] introduce .wakeup_event ops

[PATCH 1/5] introduce .wakeup_event ops

[Shaohua Li]

Introduce .wakeup_event(). When a device gets a wakeup event,
the callback is called. The callback usually should check if the device
really invokes wakeup event and disable wakeup event if yes.

Usually driver should does nothing in the op as bus can handle it. But in some
cases, like pci bus, UHCI controller doesn't use standard PME registers for
wakeup, instead of using special approach. In this case, UHCI controller driver
should implement this op.

---
 include/linux/pm.h |    8 ++++++++
 1 file changed, 8 insertions(+)

Index: linux/include/linux/pm.h
===================================================================
--- linux.orig/include/linux/pm.h	2009-08-19 11:44:41.000000000 +0800
+++ linux/include/linux/pm.h	2009-08-19 13:44:03.000000000 +0800
@@ -191,6 +191,13 @@ typedef struct pm_message {
  *	power state if all of the necessary conditions are satisfied.  Check
  *	these conditions and handle the device as appropriate, possibly queueing
  *	a suspend request for it.
+ *
+ * @wakeup_event: Checks if a wakeup event occurs. In bus level, the op might
+ *	check all devices under the bus and call device_receive_wakeup_event()
+ *	for devices which invoke wakeup event. In device level, the op just
+ *	returns if a wakeup event occurs. Note, if device follows standard
+ *	mechanism for wakeup which bus level can handle, device level op can be
+ *	empty.
  */
 
 struct dev_pm_ops {
@@ -211,6 +218,7 @@ struct dev_pm_ops {
 	int (*runtime_suspend)(struct device *dev);
 	int (*runtime_resume)(struct device *dev);
 	void (*runtime_idle)(struct device *dev);
+	bool (*wakeup_event)(struct device *dev);
 };
 
 /**

Re: [PATCH 1/5] introduce .wakeup_event ops

[Matthew Garrett]

On Wed, Aug 19, 2009 at 03:24:11PM +0800, Shaohua Li wrote:

> Usually driver should does nothing in the op as bus can handle it. But in some
> cases, like pci bus, UHCI controller doesn't use standard PME registers for
> wakeup, instead of using special approach. In this case, UHCI controller driver
> should implement this op.

I'm not averse to the general concept, but I'm not entirely sold on it 
being necessary. All the hardware I'm aware of will send non-PME events 
as a notification on a specific device. Under what circumstances will we 
get a wakeup GPE for a non-PME device without knowing which device 
should be woken?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/5] introduce .wakeup_event ops

[Alan Stern]

On Wed, 19 Aug 2009, Shaohua Li wrote:

> Introduce .wakeup_event(). When a device gets a wakeup event,
> the callback is called. The callback usually should check if the device
> really invokes wakeup event and disable wakeup event if yes.
> 
> Usually driver should does nothing in the op as bus can handle it. But in some
> cases, like pci bus, UHCI controller doesn't use standard PME registers for
> wakeup, instead of using special approach. In this case, UHCI controller driver
> should implement this op.

I don't understand the reason behind this.  Doesn't this sort of thing
belong in the bus and platform code, not in the PM core?  (In the case
of UHCI, it should be handled by the platform, in the same way as
remote wakeup gets enabled before the suspend.)

Drivers don't have to be involved at all.  When a wakeup signal is 
detected, the driver's runtime_resume method should get called -- 
nothing more is needed.

Alan Stern

Re: [PATCH 1/5] introduce .wakeup_event ops

[Shaohua Li]

On Wed, Aug 19, 2009 at 10:49:30PM +0800, Alan Stern wrote:
> On Wed, 19 Aug 2009, Shaohua Li wrote:
> 
> > Introduce .wakeup_event(). When a device gets a wakeup event,
> > the callback is called. The callback usually should check if the device
> > really invokes wakeup event and disable wakeup event if yes.
> > 
> > Usually driver should does nothing in the op as bus can handle it. But in some
> > cases, like pci bus, UHCI controller doesn't use standard PME registers for
> > wakeup, instead of using special approach. In this case, UHCI controller driver
> > should implement this op.
> 
> I don't understand the reason behind this.  Doesn't this sort of thing
> belong in the bus and platform code, not in the PM core?  (In the case
> of UHCI, it should be handled by the platform, in the same way as
> remote wakeup gets enabled before the suspend.)
> 
> Drivers don't have to be involved at all.  When a wakeup signal is 
> detected, the driver's runtime_resume method should get called -- 
> nothing more is needed.
The only case is UHCI in my mind. Because UHCI has non-standard wakeup event
register. If BIOS doesn't handle it correctly (for example, not clear the wakeup
event after a GPE), we will keep see the wakeup event. And the bus/platform
level has no knowledge to handle such event.

Thanks,
Shaohua

Re: [PATCH 1/5] introduce .wakeup_event ops

[Shaohua Li]

On Wed, Aug 19, 2009 at 07:52:10PM +0800, Matthew Garrett wrote:
> On Wed, Aug 19, 2009 at 03:24:11PM +0800, Shaohua Li wrote:
> 
> > Usually driver should does nothing in the op as bus can handle it. But in some
> > cases, like pci bus, UHCI controller doesn't use standard PME registers for
> > wakeup, instead of using special approach. In this case, UHCI controller driver
> > should implement this op.
> 
> I'm not averse to the general concept, but I'm not entirely sold on it 
> being necessary. All the hardware I'm aware of will send non-PME events 
> as a notification on a specific device. Under what circumstances will we 
> get a wakeup GPE for a non-PME device without knowing which device 
> should be woken?
Below code is gotten from a laptop (samsung-x10), the PCIB is the PCI bridge.
We can't guarantee the device which gets a wakeup event notification is really
the device which invokes the wakeup event.

	Device (PCIB)
        {
                Name (_ADR, 0x001E0000)
                Device (CDB0)
		{
		    Name (_ADR, 0x00030000)
		}
		 Device (CDB1)
                {
                    Name (_ADR, 0x00030001)

		}
	}


        Method (_L0B, 0, NotSerialized)
        {
            Notify (\_SB.PCI0.PCIB, 0x02)
            Notify (\_SB.PWRB, 0x02)
            Store (0x01, \_SB.PCI0.PCIB.CDB0.PMES)
            Store (0x01, \_SB.PCI0.PCIB.CDB1.PMES)
        }

Thanks,
Shaohua

Re: [PATCH 1/5] introduce .wakeup_event ops

[Matthew Garrett]

On Thu, Aug 20, 2009 at 11:24:50AM +0800, Shaohua Li wrote:
> On Wed, Aug 19, 2009 at 07:52:10PM +0800, Matthew Garrett wrote:
> > I'm not averse to the general concept, but I'm not entirely sold on it 
> > being necessary. All the hardware I'm aware of will send non-PME events 
> > as a notification on a specific device. Under what circumstances will we 
> > get a wakeup GPE for a non-PME device without knowing which device 
> > should be woken?
> Below code is gotten from a laptop (samsung-x10), the PCIB is the PCI bridge.
> We can't guarantee the device which gets a wakeup event notification is really
> the device which invokes the wakeup event.

_L0B will only be triggered if a PME is generated, so we'll be able to 
determine which device generated the wakeup by looking at the PME 
registers.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/5] introduce .wakeup_event ops

[Alan Stern]

On Thu, 20 Aug 2009, Shaohua Li wrote:

> > I don't understand the reason behind this.  Doesn't this sort of thing
> > belong in the bus and platform code, not in the PM core?  (In the case
> > of UHCI, it should be handled by the platform, in the same way as
> > remote wakeup gets enabled before the suspend.)
> > 
> > Drivers don't have to be involved at all.  When a wakeup signal is 
> > detected, the driver's runtime_resume method should get called -- 
> > nothing more is needed.
> The only case is UHCI in my mind. Because UHCI has non-standard wakeup event
> register.

That's an oversimplification.  _Some_ (I think) of _Intel's_ UHCI
implementations have a non-standard wakeup event register.

> If BIOS doesn't handle it correctly (for example, not clear the wakeup
> event after a GPE), we will keep see the wakeup event. And the bus/platform
> level has no knowledge to handle such event.

How is the wakeup event received?  Maybe for this one type of device a 
PCI quirk will solve the problem.

Or if that doesn't work, code can be added to uhci-hcd to turn off the
non-standard wakeup register as part of the resume routine.  (The
problem here is that the resume routine runs in process context so it
has to be called after the wakeup event handler has returned.)

Alan Stern

Re: [PATCH 1/5] introduce .wakeup_event ops

[Matthew Garrett]

On Thu, Aug 20, 2009 at 10:11:19AM -0400, Alan Stern wrote:

> How is the wakeup event received?  Maybe for this one type of device a 
> PCI quirk will solve the problem.

Pretty much the same as PME events on PCI - a GPE is generated, an SCI 
raised, the ACPI interpreter executes the code that's in the ACPI 
tables, that generates a notification event on the appropriate UHCI 
device, we live happily ever after.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/5] introduce .wakeup_event ops

[Alan Stern]

On Thu, 20 Aug 2009, Matthew Garrett wrote:

> On Thu, Aug 20, 2009 at 10:11:19AM -0400, Alan Stern wrote:
> 
> > How is the wakeup event received?  Maybe for this one type of device a 
> > PCI quirk will solve the problem.
> 
> Pretty much the same as PME events on PCI - a GPE is generated, an SCI 
> raised, the ACPI interpreter executes the code that's in the ACPI 
> tables, that generates a notification event on the appropriate UHCI 
> device, we live happily ever after.

What happens after the notification event is generated?  That is, what
functions get called?  I'm not at all familiar with this part of the
kernel.

If the wakeup signal isn't squelched at the source, as part of the
event handling, will we get an interrupt storm?  Will the uhci-hcd 
resume routine be able to handle this or does it need to be done 
earlier?  In other words, do we need special-purpose code in the PCI 
layer to handler it?

Alan Stern

Re: [PATCH 1/5] introduce .wakeup_event ops

[Matthew Garrett]

On Thu, Aug 20, 2009 at 10:38:15AM -0400, Alan Stern wrote:
> On Thu, 20 Aug 2009, Matthew Garrett wrote:
> > Pretty much the same as PME events on PCI - a GPE is generated, an SCI 
> > raised, the ACPI interpreter executes the code that's in the ACPI 
> > tables, that generates a notification event on the appropriate UHCI 
> > device, we live happily ever after.
> 
> What happens after the notification event is generated?  That is, what
> functions get called?  I'm not at all familiar with this part of the
> kernel.

The notification will be sent to whichever code has registered a 
notification handler for that device. In my patches that means it'll 
arrive in the PCI layer (if it's a PCI device) and then call 
pci_runtime_resume on the appropriate device.

> If the wakeup signal isn't squelched at the source, as part of the
> event handling, will we get an interrupt storm?  Will the uhci-hcd 
> resume routine be able to handle this or does it need to be done 
> earlier?  In other words, do we need special-purpose code in the PCI 
> layer to handler it?

No, nothing special needs to be done at the PCI level. It seems that 
(for Intel at least) there's no need to do anything special at the UHCI 
level either.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/5] introduce .wakeup_event ops

[Alan Stern]

On Thu, 20 Aug 2009, Matthew Garrett wrote:

> > If the wakeup signal isn't squelched at the source, as part of the
> > event handling, will we get an interrupt storm?  Will the uhci-hcd 
> > resume routine be able to handle this or does it need to be done 
> > earlier?  In other words, do we need special-purpose code in the PCI 
> > layer to handler it?
> 
> No, nothing special needs to be done at the PCI level. It seems that 
> (for Intel at least) there's no need to do anything special at the UHCI 
> level either.

This contradicts what Shaohua wrote:

"The only case is UHCI in my mind. Because UHCI has non-standard wakeup
event register. If BIOS doesn't handle it correctly (for example, not
clear the wakeup event after a GPE), we will keep see the wakeup
event."

What code would be responsible for setting and clearing the 
non-standard wakeup register?  Are you assuming that ACPI will always 
handle it?  I guess that's a reasonable assumption -- if ACPI wasn't 
aware of the register then it never would get enabled, and conversely, 
if ACPI was aware and could enable the register, then ACPI ought to 
disable it when necessary.

Alan Stern

Re: [PATCH 1/5] introduce .wakeup_event ops

[Rafael J. Wysocki]

On Thursday 20 August 2009, Alan Stern wrote:
> On Thu, 20 Aug 2009, Matthew Garrett wrote:
> 
> > > If the wakeup signal isn't squelched at the source, as part of the
> > > event handling, will we get an interrupt storm?  Will the uhci-hcd 
> > > resume routine be able to handle this or does it need to be done 
> > > earlier?  In other words, do we need special-purpose code in the PCI 
> > > layer to handler it?
> > 
> > No, nothing special needs to be done at the PCI level. It seems that 
> > (for Intel at least) there's no need to do anything special at the UHCI 
> > level either.
> 
> This contradicts what Shaohua wrote:
> 
> "The only case is UHCI in my mind. Because UHCI has non-standard wakeup
> event register. If BIOS doesn't handle it correctly (for example, not
> clear the wakeup event after a GPE), we will keep see the wakeup
> event."

I'm not sure what the phrase "we will keep see the wakeup event" is supposed to
mean.  For us to "see" any events there has to be a GPE set up or PCIe PME
enabled on the right root port.  Otherwise I don't see how we can receive the
event at all.

The bus type wakeup code won't know how to clear the register to acknowledge
the wakeup, but the driver's ->runtime_resume() callback surely can do that.

> What code would be responsible for setting and clearing the 
> non-standard wakeup register?  Are you assuming that ACPI will always 
> handle it?  I guess that's a reasonable assumption -- if ACPI wasn't 
> aware of the register then it never would get enabled, and conversely, 
> if ACPI was aware and could enable the register, then ACPI ought to 
> disable it when necessary.

In any case the event has to be raised in one of the standard ways.

Thanks,
Rafael

Re: [PATCH 1/5] introduce .wakeup_event ops

[Alan Stern]

On Thu, 20 Aug 2009, Rafael J. Wysocki wrote:

> On Thursday 20 August 2009, Alan Stern wrote:
> > On Thu, 20 Aug 2009, Matthew Garrett wrote:
> > 
> > > > If the wakeup signal isn't squelched at the source, as part of the
> > > > event handling, will we get an interrupt storm?  Will the uhci-hcd 
> > > > resume routine be able to handle this or does it need to be done 
> > > > earlier?  In other words, do we need special-purpose code in the PCI 
> > > > layer to handler it?
> > > 
> > > No, nothing special needs to be done at the PCI level. It seems that 
> > > (for Intel at least) there's no need to do anything special at the UHCI 
> > > level either.
> > 
> > This contradicts what Shaohua wrote:
> > 
> > "The only case is UHCI in my mind. Because UHCI has non-standard wakeup
> > event register. If BIOS doesn't handle it correctly (for example, not
> > clear the wakeup event after a GPE), we will keep see the wakeup
> > event."
> 
> I'm not sure what the phrase "we will keep see the wakeup event" is supposed to
> mean.  For us to "see" any events there has to be a GPE set up or PCIe PME
> enabled on the right root port.  Otherwise I don't see how we can receive the
> event at all.
> 
> The bus type wakeup code won't know how to clear the register to acknowledge
> the wakeup, but the driver's ->runtime_resume() callback surely can do that.
> 
> > What code would be responsible for setting and clearing the 
> > non-standard wakeup register?  Are you assuming that ACPI will always 
> > handle it?  I guess that's a reasonable assumption -- if ACPI wasn't 
> > aware of the register then it never would get enabled, and conversely, 
> > if ACPI was aware and could enable the register, then ACPI ought to 
> > disable it when necessary.
> 
> In any case the event has to be raised in one of the standard ways.

I'm still not clear on this.  Does the non-standard wakeup register
have to be set and cleared by the suspend and resume routines in
uhci-hcd, or will it be handled by other code?

Alan Stern

Re: [PATCH 1/5] introduce .wakeup_event ops

[Rafael J. Wysocki]

On Thursday 20 August 2009, Alan Stern wrote:
> On Thu, 20 Aug 2009, Rafael J. Wysocki wrote:
> 
> > On Thursday 20 August 2009, Alan Stern wrote:
> > > On Thu, 20 Aug 2009, Matthew Garrett wrote:
> > > 
> > > > > If the wakeup signal isn't squelched at the source, as part of the
> > > > > event handling, will we get an interrupt storm?  Will the uhci-hcd 
> > > > > resume routine be able to handle this or does it need to be done 
> > > > > earlier?  In other words, do we need special-purpose code in the PCI 
> > > > > layer to handler it?
> > > > 
> > > > No, nothing special needs to be done at the PCI level. It seems that 
> > > > (for Intel at least) there's no need to do anything special at the UHCI 
> > > > level either.
> > > 
> > > This contradicts what Shaohua wrote:
> > > 
> > > "The only case is UHCI in my mind. Because UHCI has non-standard wakeup
> > > event register. If BIOS doesn't handle it correctly (for example, not
> > > clear the wakeup event after a GPE), we will keep see the wakeup
> > > event."
> > 
> > I'm not sure what the phrase "we will keep see the wakeup event" is supposed to
> > mean.  For us to "see" any events there has to be a GPE set up or PCIe PME
> > enabled on the right root port.  Otherwise I don't see how we can receive the
> > event at all.
> > 
> > The bus type wakeup code won't know how to clear the register to acknowledge
> > the wakeup, but the driver's ->runtime_resume() callback surely can do that.
> > 
> > > What code would be responsible for setting and clearing the 
> > > non-standard wakeup register?  Are you assuming that ACPI will always 
> > > handle it?  I guess that's a reasonable assumption -- if ACPI wasn't 
> > > aware of the register then it never would get enabled, and conversely, 
> > > if ACPI was aware and could enable the register, then ACPI ought to 
> > > disable it when necessary.
> > 
> > In any case the event has to be raised in one of the standard ways.
> 
> I'm still not clear on this.  Does the non-standard wakeup register
> have to be set and cleared by the suspend and resume routines in
> uhci-hcd, or will it be handled by other code?

I'm not sure if anyone can answer this 100% accurately without doing any
testing.

Best,
Rafael

Re: [PATCH 1/5] introduce .wakeup_event ops

[Shaohua Li]

On Thu, Aug 20, 2009 at 03:40:51PM +0800, Matthew Garrett wrote:
> On Thu, Aug 20, 2009 at 11:24:50AM +0800, Shaohua Li wrote:
> > On Wed, Aug 19, 2009 at 07:52:10PM +0800, Matthew Garrett wrote:
> > > I'm not averse to the general concept, but I'm not entirely sold on it 
> > > being necessary. All the hardware I'm aware of will send non-PME events 
> > > as a notification on a specific device. Under what circumstances will we 
> > > get a wakeup GPE for a non-PME device without knowing which device 
> > > should be woken?
> > Below code is gotten from a laptop (samsung-x10), the PCIB is the PCI bridge.
> > We can't guarantee the device which gets a wakeup event notification is really
> > the device which invokes the wakeup event.
> 
> _L0B will only be triggered if a PME is generated, so we'll be able to 
> determine which device generated the wakeup by looking at the PME 
> registers.
Right, but the event is sent to a bridge. The devices under the bridge invoke
wakeup event, not the bridge itself. So you must scan all devices under the
bridge to check which device has its PME registers set.
So the bridge case isn't what you said (notification always sent to a specific
device which invokes the wakeup event)

Thanks,
Shaohua

Re: [PATCH 1/5] introduce .wakeup_event ops

[Shaohua Li]

On Fri, Aug 21, 2009 at 05:27:10AM +0800, Rafael J. Wysocki wrote:
> On Thursday 20 August 2009, Alan Stern wrote:
> > On Thu, 20 Aug 2009, Rafael J. Wysocki wrote:
> > 
> > > On Thursday 20 August 2009, Alan Stern wrote:
> > > > On Thu, 20 Aug 2009, Matthew Garrett wrote:
> > > > 
> > > > > > If the wakeup signal isn't squelched at the source, as part of the
> > > > > > event handling, will we get an interrupt storm?  Will the uhci-hcd 
> > > > > > resume routine be able to handle this or does it need to be done 
> > > > > > earlier?  In other words, do we need special-purpose code in the PCI 
> > > > > > layer to handler it?
> > > > > 
> > > > > No, nothing special needs to be done at the PCI level. It seems that 
> > > > > (for Intel at least) there's no need to do anything special at the UHCI 
> > > > > level either.
> > > > 
> > > > This contradicts what Shaohua wrote:
> > > > 
> > > > "The only case is UHCI in my mind. Because UHCI has non-standard wakeup
> > > > event register. If BIOS doesn't handle it correctly (for example, not
> > > > clear the wakeup event after a GPE), we will keep see the wakeup
> > > > event."
> > > 
> > > I'm not sure what the phrase "we will keep see the wakeup event" is supposed to
> > > mean.  For us to "see" any events there has to be a GPE set up or PCIe PME
> > > enabled on the right root port.  Otherwise I don't see how we can receive the
> > > event at all.
> > > 
> > > The bus type wakeup code won't know how to clear the register to acknowledge
> > > the wakeup, but the driver's ->runtime_resume() callback surely can do that.
> > > 
> > > > What code would be responsible for setting and clearing the 
> > > > non-standard wakeup register?  Are you assuming that ACPI will always 
> > > > handle it?  I guess that's a reasonable assumption -- if ACPI wasn't 
> > > > aware of the register then it never would get enabled, and conversely, 
> > > > if ACPI was aware and could enable the register, then ACPI ought to 
> > > > disable it when necessary.
> > > 
> > > In any case the event has to be raised in one of the standard ways.
> > 
> > I'm still not clear on this.  Does the non-standard wakeup register
> > have to be set and cleared by the suspend and resume routines in
> > uhci-hcd, or will it be handled by other code?
> 
> I'm not sure if anyone can answer this 100% accurately without doing any
> testing.
As far as I know, when the pci trys to enable pme, we will call corresponding
ACPI methods. In that methods, the non-starndard wakeup registers will be
set/clear. The issue is we must relay on correct BIOS.

Thanks,
Shaohua

Re: [PATCH 1/5] introduce .wakeup_event ops

[Matthew Garrett]

On Fri, Aug 21, 2009 at 02:33:50PM +0800, Shaohua Li wrote:
> On Thu, Aug 20, 2009 at 03:40:51PM +0800, Matthew Garrett wrote:
> > _L0B will only be triggered if a PME is generated, so we'll be able to 
> > determine which device generated the wakeup by looking at the PME 
> > registers.
> Right, but the event is sent to a bridge. The devices under the bridge invoke
> wakeup event, not the bridge itself. So you must scan all devices under the
> bridge to check which device has its PME registers set.
> So the bridge case isn't what you said (notification always sent to a specific
> device which invokes the wakeup event)

Yes, but that's fine because the PME state tells us exactly which device 
caused the wakeup. We'll never get a bus notification if the wakeup is 
triggered by UHCI on Intel.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/5] introduce .wakeup_event ops

[Alan Stern]

On Fri, 21 Aug 2009, Shaohua Li wrote:

> > > I'm still not clear on this.  Does the non-standard wakeup register
> > > have to be set and cleared by the suspend and resume routines in
> > > uhci-hcd, or will it be handled by other code?
> > 
> > I'm not sure if anyone can answer this 100% accurately without doing any
> > testing.
> As far as I know, when the pci trys to enable pme, we will call corresponding
> ACPI methods. In that methods, the non-starndard wakeup registers will be
> set/clear. The issue is we must relay on correct BIOS.

If the BIOS doesn't know about the non-standard register then it won't 
set the wakeup bits.  Therefore the fact that it won't clear them 
doesn't matter.

Alan Stern

Re: [PATCH 1/5] introduce .wakeup_event ops

[Shaohua Li]

On Fri, Aug 21, 2009 at 05:23:16PM +0800, Matthew Garrett wrote:
> On Fri, Aug 21, 2009 at 02:33:50PM +0800, Shaohua Li wrote:
> > On Thu, Aug 20, 2009 at 03:40:51PM +0800, Matthew Garrett wrote:
> > > _L0B will only be triggered if a PME is generated, so we'll be able to 
> > > determine which device generated the wakeup by looking at the PME 
> > > registers.
> > Right, but the event is sent to a bridge. The devices under the bridge invoke
> > wakeup event, not the bridge itself. So you must scan all devices under the
> > bridge to check which device has its PME registers set.
> > So the bridge case isn't what you said (notification always sent to a specific
> > device which invokes the wakeup event)
> 
> Yes, but that's fine because the PME state tells us exactly which device 
> caused the wakeup. We'll never get a bus notification if the wakeup is 
> triggered by UHCI on Intel.
Hmm, but here what we are talking about is if notification is always sent to the device
which invokes wakeup event.
I pointed out this isn't true because BIOS might sent notification to a pci bridge and
OS should scan devices under the bridge to check which devices invokes it by looking at
PME state. Looks you are talking about other things.

Thanks,
Shaohua

Re: [PATCH 1/5] introduce .wakeup_event ops

[Matthew Garrett]

On Mon, Aug 24, 2009 at 09:50:46AM +0800, Shaohua Li wrote:
> On Fri, Aug 21, 2009 at 05:23:16PM +0800, Matthew Garrett wrote:
> > Yes, but that's fine because the PME state tells us exactly which device 
> > caused the wakeup. We'll never get a bus notification if the wakeup is 
> > triggered by UHCI on Intel.
> Hmm, but here what we are talking about is if notification is always sent to the device
> which invokes wakeup event.
> I pointed out this isn't true because BIOS might sent notification to a pci bridge and
> OS should scan devices under the bridge to check which devices invokes it by looking at
> PME state. Looks you are talking about other things.

There are two cases:

1) Notification is sent to a device. Since we know the device that 
generated the event, we don't need .wakeup_event.

2) Notification is sent to a bus. This will only happen if the device 
supports PME, so we don't need .wakeup_event.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 1/5] introduce .wakeup_event ops

[Rafael J. Wysocki]

On Monday 24 August 2009, Shaohua Li wrote:
> On Mon, 2009-08-24 at 16:27 +0800, Matthew Garrett wrote:
> > On Mon, Aug 24, 2009 at 04:21:50PM +0800, Shaohua Li wrote:
> > > On Mon, 2009-08-24 at 16:09 +0800, Matthew Garrett wrote:
> > > > I don't agree - the wakeup GPE will generate a standard notify, and the 
> > > > notification handler has to be at the device or bus layer to handle 
> > > > device-specific requests.
> > > Then we will have duplicate code at each device or bus.
> > 
> > I think that's inevitable, unless the notification infrastructure is 
> > made more fine grained.
> At least we need some check and maybe gpe handling and we need some
> "ifdef ACPI" staff at each device or bus.

Why would we need that?

> There isn't big difference device/bus register a notification handler or
> register a .wakeup_event. And .wakeup_event is more simple in device/bus
> level.

As Matthew said, there is.

To make things clear, we're not going to add .wakeup_event().

Thanks,
Rafael