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? On Tue, 16 Dec 2008 JosephChan@xxxxxxxxxx wrote: > We're curious why there is no problem that the echi-pci.c and > ohci-pci.c also call the device_init_wakeup(). ohci-pci.c never calls device_init_wakeup(dev, 1); it only calls device_init_wakeup(dev, 0). That's okay; it's always safe to _disable_ remote wakeup. ehci-pci.c checks that the device supports wakeup events before it calls device_init_wakeup(). So does ohci-hcd.c. Note the comment in ehci-pci.c: /* Workaround current PCI init glitch: wakeup bits aren't * being set from PCI PM capability. */ and the comment in ohci-pci.c: /* RWC may not be set for add-in PCI cards, since boot * firmware probably ignored them. This transfers PCI * PM wakeup capabilities (once the PCI layer is fixed). */ If the PCI core did the initialization properly then the call in ehci-pci.c could be removed. > And is it possible for us to add this into "uhci_check_and_reset_hc" > function of <kernel source>/drivers/usb/host/pci-quirks.c ? No. It should be added to the PCI core. Alan Stern -- 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
