>-----Original Message----- >From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- >owner@xxxxxxxxxxxxxxx] On Behalf Of David Brownell >Sent: Tuesday, September 09, 2008 10:57 AM >To: Li, Shaohua >Cc: Rafael J. Wysocki; linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux- >acpi@xxxxxxxxxxxxxxx; stern@xxxxxxxxxxxxxxxxxxx; Jesse Barnes >Subject: Re: [RFC 3/5] pci wakeup handler > >On Monday 08 September 2008, Li, Shaohua wrote: >> > if (drv && drv->pm && drv->pm->base.wakeup_event) { >> > int dev_ret = drv->pm->base.wakeup_event(&pdev->dev); >> > if (ret) >> > ret = dev_ret; >> > } >> > >> > Also, why do you think we should ignore the returned value if ret is >zero? >> >> Because we already identified the device which invokes PME. > >Well, we *may* have identified *one* of them. If the device >supports the PCI PM standards, we did. If it uses legacy PM >(like Intel's UHCI controllers), that's not guaranteed ... Right, so the patch always 0 if device follows PM standards. Otherwise, return .wakeup_event(). >> Even the .wakeup_event() returns an error, we should populate >> It's this device which has wakeup event. > >You haven't exactly defined the semantics of the return value, >or what a caller would do with it. I'll comment this on another mail >> In my mind, driver isn't >> required to provide .wakeup_event() unless device has non-standard >> regs for wakeup event or some special to handle. Generic PME handling >> should be fine for most devices (for PCI devices). > >I don't follow this then. You're saying it will suffice to >just clear the PCI PM status, and the driver is expected to >work fine without even being notified about its wake event?? NPME or ACPI will call ' device_receive_wakeup_event()', which will do anything you want. Thanks, Shaohua -- 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
