On Thu, 11 Aug 2011, Sarah Sharp wrote: > > In principle, all you should need is to echo "enabled" to the > > power/wakeup attribute for the keyboard in question, possibly for the > > root hub ancestor device (it should be enabled by default), and for the > > PCI USB controller device. > > Interesting. I checked the USB roothub's usbN/power/wakeup file, and it > was marked as enabled. However, the PCI device's power/wakeup file was > marked as disabled. Any idea why it would be disabled by default? In general, all devices are disabled for wakeup by default, except for things that are expected to wake up the machine -- things like keyboards and power buttons. That could be considered a policy decision, but really it's just a matter of having sensible defaults. (Also, there are plenty of devices that don't implement remote wakeup correctly, so leaving it disabled is safer.) One could argue that a USB controller never generates wakeup events by itself; it merely acts as a bridge between the USB and PCI buses. Therefore it ought to be enabled by default, whereas USB hubs (including root hubs) shouldn't since they _do_ generate wakeup events upon plug and unplug. But historically that's not the way things worked out. Maybe they deserve to be changed. > I do notice that when I enable the PCI USB roothub remote wake for the > second EHCI host controller in the system (PCI device 00:1a.7), the > system will immediately pop out of suspend, even though there's no USB > devices attached. All the other host controllers on this system seem to > work properly, except for the NEC host controller add-in card, which I > can't get to wake the system up at all. > > Perhaps the PCI developers disabled remote wake for all Intel PCI USB > hosts because of that? Not really. Remote wakeup is disabled by default for all PCI devices. You might be interested in examining that second EHCI controller more closely to see what it's doing. I think "lspci -vv -s 00:1a.7" will include the power management information if you run it as root. The NEC add-in card issue may actually be a problem with a PCI bridge. 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
