On Mon, 2009-08-24 at 10:48 +0800, Matthew Garrett wrote: > 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. This depends on where you put the ACPI GPE code. If you put it to ACPI directory, then we need a .wakeup_event at least in bus level. ACPI is a generic framework, it can send wakeup event to any bus. It's definitely better to put the wakeup GPE handling into ACPI directory. -- 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
