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, Rafael -- 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
