On Tuesday, December 16, 2008 1:01 pm Rafael J. Wysocki wrote: > On Tuesday, 16 of December 2008, Jesse Barnes wrote: > > On Tuesday, December 16, 2008 7:02 am Alan Stern wrote: > > > On Mon, 15 Dec 2008, Jesse Barnes wrote: > > > > Yeah, if it's a PCI device pci_enable_wake should do the right thing > > > > (use ACPI or other platform code if needed, otherwise fall back to > > > > banging on the PM cap bits, etc.). The call can fail if the device > > > > or platform can't wake up the system, is that what you're looking > > > > for? > > > > > > You don't understand. pci_enable_wake() enables wakeup events > > > (assuming the device supports them). But that's not what Joseph is > > > concerned about. He's concerned about device_init_wakeup(), which sets > > > the can_wakeup flag to indicate that the device is _capable_ of > > > generating wakeup events. > > > > > > Why doesn't the PCI core set the can_wakeup flag when a PCI device is > > > first discovered? > > > > pci_pm_init() should do that, from pci_init_capabilities(), but only if > > the device has PM caps will can_wakeup be set correctly. OTOH, > > pci_enable_wake() will enable wake on a device even w/o PM caps if the > > platform supports it. We don't check for platform support at init time > > though, so if your driver checks for can_wake it may fail. So something > > like this patch might be what you're looking for? Or are you seeing > > cases where the PM cap bits are ignored too? In that case we'd have a bug > > in our pm_init code... > > FWIW, I think the patch does the right thing. Thanks for looking. I'll wait for Joseph's test results before applying. -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
