[RFC] ehci: Disable wake on overcurrent (WKOC_E) and disconnect (WKDISC_E)
in [Kernel]
|
Prev: [PATCH:resend] rt: Remove CONFIG_STACK_TRACER from DEBUG_COUNT, and fix reminder block
Next: [GIT PULL] block/writeback bits for 2.6.34-rc
From: Alan Stern on 27 Apr 2010 15:30 On Tue, 27 Apr 2010, Ondrej Zary wrote: > The previous patch was not enough as it worked only when there were no USB > devices connected. With a bus-powered device connected, power loss causes > disconnect which wakes up the machine immediately again. You said earlier that the host controller was disabled for remote wakeup ("/sys/devices/pci0000:00/0000:00:1d.7/power/wakeup is disabled by default"). So even though the root hub might issue a wakeup request, the controller hardware should not forward that request to the PCI bus and it should not cause the system to wake up. > Does anyone know why is this enabled by default? Why _what_ is enabled? Detection of disconnects? Because otherwise your computer wouldn't realize anything had happened when a suspended USB device was unplugged from a suspended root hub. > No other USB host driver > (except oxu210hp-hcd which is based on EHCI) does that. Look again -- they all do. (All the HCDs that support suspend/resume, anyway.) > This also means that > suspended laptop wakes up when disconnecting a mouse? No, for the reason I described above. The controller is aware of the wakeup request but doesn't generate a PME# event. Likewise for desktop systems. > I don't have any to test > right now. Wakeup on USB connect makes a bit more sense but I'd say that it's > still not a good idea to enable it by default. > > If we don't need that, perhaps the following patch should be applied. > > > Disable wake on overcurrent and disconnect in EHCI. > This fixes immediate resume from standby on boards where port power is lost > in standby which triggers overcurrent detection and disconnect if a > bus-powered device is connected. At least Asus P4P800 boards are affected when > any of the USBPWxx (e.g. USBPW12) jumpers is set to 5V. Why would you want to change the jumper settings? Host controllers are _supposed_ to supply 5V power during system suspend. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 28 Apr 2010 11:50 On Tue, 27 Apr 2010, Ondrej Zary wrote: > On Tuesday 27 April 2010 21:21:23 Alan Stern wrote: > > On Tue, 27 Apr 2010, Ondrej Zary wrote: > > > The previous patch was not enough as it worked only when there were no > > > USB devices connected. With a bus-powered device connected, power loss > > > causes disconnect which wakes up the machine immediately again. > > > > You said earlier that the host controller was disabled for remote > > wakeup ("/sys/devices/pci0000:00/0000:00:1d.7/power/wakeup is disabled > > by default"). So even though the root hub might issue a wakeup > > request, the controller hardware should not forward that request to the > > PCI bus and it should not cause the system to wake up. > > Maybe it should not - but it wakes up this board and probably also P4P800, > P4P800-E and P4C800-E at least: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/75497 Okay, evidently the hardware or firmware on these boards is buggy. Other systems do not have the same problem, as far as I know. > > > Does anyone know why is this enabled by default? > > > > Why _what_ is enabled? Detection of disconnects? Because otherwise > > your computer wouldn't realize anything had happened when a suspended > > USB device was unplugged from a suspended root hub. > > That's not disconnect detection - that's wakeup on disconnect. True; I oversimplified. Furthermore, starting in 2.6.34, the wakeup settings during system sleep (suspend or hibernation) can be different from the settings during autosuspend, so you can have root hubs enabled for wakeup during autosuspend but not during system sleep. > If I understand > EHCI 1.0 specification correctly, disconnect detection should work regardless > of the state of this bit: > | PORTSC bit 21: Wake on Disconnect Enable (WKDSCNNT_E): > | R/W. Default = 0b. > | Writing this bit to a one enables the port to be sensitive to device > | disconnects as wake-up events. See Section 4.3 for effects of this bit on > | resume event behavior. Refer to Section 4.3.1 for operational model. > > And it really does. With this patch applied, system does not wake up when a > device is disconnected during suspend. When I wake up the system manually, > the disconnect is detected immediately (does not matter It's worth pointing out that EHCI is different in this respect from OHCI and UHCI; the older controllers do not have the capability to enable or disable wakeup independently for connect, disconnect, and overcurrent events. They are all or nothing. So are external USB hubs. > > > If we don't need that, perhaps the following patch should be applied. > > > > > > > > > Disable wake on overcurrent and disconnect in EHCI. > > > This fixes immediate resume from standby on boards where port power is > > > lost in standby which triggers overcurrent detection and disconnect if a > > > bus-powered device is connected. At least Asus P4P800 boards are affected > > > when any of the USBPWxx (e.g. USBPW12) jumpers is set to 5V. > > > > Why would you want to change the jumper settings? Host controllers are > > _supposed_ to supply 5V power during system suspend. > > Maybe because I don't want all my USB devices to be powered when the system is > turned off. I doubt that laptop in suspend-to-RAM (on battery) provides power > to USB ports. This depends on how your system was turned off. During suspend or hibernation, you _should_ want USB devices to be powered (and some people do, as Greg pointed out). During a normal system shutdown, the USB buses should not be powered. Regardless, I don't think a kernel patch is the way to solve your problem. Changing the wakeup setting for the root hub will do what you want, and that setting is explicitly intended to be controlled by userspace (after all, that's why it is exposed in sysfs). The initial value is only a reasonable default; you can certainly add scripts or udev rules to disable wakeup on your EHCI root hub. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 30 Apr 2010 16:20
On Wed, 28 Apr 2010, Ondrej Zary wrote: > On Wednesday 28 April 2010 17:41:30 Alan Stern wrote: > > On Tue, 27 Apr 2010, Ondrej Zary wrote: > > > On Tuesday 27 April 2010 21:21:23 Alan Stern wrote: > > > > On Tue, 27 Apr 2010, Ondrej Zary wrote: > > > > > The previous patch was not enough as it worked only when there were > > > > > no USB devices connected. With a bus-powered device connected, power > > > > > loss causes disconnect which wakes up the machine immediately again. > > > > > > > > You said earlier that the host controller was disabled for remote > > > > wakeup ("/sys/devices/pci0000:00/0000:00:1d.7/power/wakeup is disabled > > > > by default"). So even though the root hub might issue a wakeup > > > > request, the controller hardware should not forward that request to the > > > > PCI bus and it should not cause the system to wake up. > > > > > > Maybe it should not - but it wakes up this board and probably also > > > P4P800, P4P800-E and P4C800-E at least: > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/75497 > > > > Okay, evidently the hardware or firmware on these boards is buggy. > > Other systems do not have the same problem, as far as I know. I take this back. The same thing happens on my machine (Intel ICH5 chipset). I'd guess there is a bug in the PCI or ACPI subsystem, but more testing is needed before I can be sure. Somehow the PCI or platform wakeup mechanism gets activated even when it is supposed to be disabled. > It works fine in Windows. How can you tell? How do you know what values Windows writes into the EHCI port control registers? > > Regardless, I don't think a kernel patch is the way to solve your > > problem. Changing the wakeup setting for the root hub will do what you > > want, and that setting is explicitly intended to be controlled by > > userspace (after all, that's why it is exposed in sysfs). The initial > > value is only a reasonable default; you can certainly add scripts or > > udev rules to disable wakeup on your EHCI root hub. > > Yes, I can work around that. But many users can't. This is an attempt to make > it "just work". It should "just work" already. The fact that it doesn't means there is a bug. At the moment I can't be sure where the bug is -- but even if it is in ehci-hcd, your suggested patch isn't the right fix. > I'm trying to say that the "wakeup on everything" is not a good thing (if not > a bug). Who needs it? I don't know, and neither do you. But the USB spec requires this behavior from external hubs, so evidently _somebody_ thought it was a good idea. > I can't imagine any real use for it. It clearly breaks > suspend on some systems and is annoying on other. If everything was working properly, the machine wouldn't wake up when a disconnect occurred. > Who expects that > disconnecting a device should wake up sleeping machine? Perhaps the same people who expect that plugging in a device should wake up a sleeping machine? > When all these three wakeups (overcurrent, connect, disconnect) are disabled, > we lose nothing. Connect/disconnect detection works fine after wakeup. Wakeup > by USB devices (not by connect/disconnect but by the device itself signaling > a resume) is completely independent of this (according to EHCI > specification). What about UHCI or OHCI? What about external hubs? In short, why should EHCI behave differently from everything else? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |