Yes, I would suggest we add a device object to can_wake. This allows the acpica core to handle this "implicit notify" with no additional overhead from the host. >-----Original Message----- >From: Rafael J. Wysocki [mailto:rjw@xxxxxxx] >Sent: Wednesday, October 06, 2010 12:30 PM >To: Matthew Garrett >Cc: Moore, Robert; linux-acpi@xxxxxxxxxxxxxxx; linux- >kernel@xxxxxxxxxxxxxxx; linux-pci@xxxxxxxxxxxxxxx >Subject: Re: [PATCH 1/5] ACPI: Allow handlers to be installed at the same >time as methods > >On Wednesday, October 06, 2010, Matthew Garrett wrote: >> On Wed, Oct 06, 2010 at 09:14:07AM -0700, Moore, Robert wrote: >> >> > Although there exists a single Windows document mentions this behavior >as a windows "feature", I'm not 100% convinced that this is actually true. >AFAIK, we've never seen a machine that depends on an "implicit notify" on a >device when a wake GPE happens. >> >> Such behaviour would be irrelevant for system sleep/wake - the only >> requirement is in runtime power management. >> >> > It appears to me that the biggest issue right now is the fact that a >Notify() must be performed on a Device object, and the problem is how to >associate the GPE with the device object. >> >> The other important aspect of this is that a single GPE may correspond >> to multiple devices. The methods will generally cope with this by either >> sending multiple notifies, executing some SMM code to identify the >> relevant device or reading PCI configuration registers to identify the >> source of the wakeup. We need to handle that case as well. > >So, as I said, we can modify acpi_gpe_can_wake() to pass a device object to >ACPICA. Then, the device object will be added to the list of devices to >Notify() >if the GPE is signaled. Plain and simple. > >Thanks, >Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
