From: Ondrej Zary <linux@rainbow-software.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-pm@lists.linux-foundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] [RFC] ehci: Disable wake on overcurrent (WKOC_E) and disconnect (WKDISC_E)
Date: Tue, 27 Apr 2010 22:46:48 +0200 [thread overview]
Message-ID: <201004272246.51494.linux@rainbow-software.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1004271509450.1850-100000@iolanthe.rowland.org>
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
> > 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. 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
> > 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.
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.
--
Ondrej Zary
next prev parent reply other threads:[~2010-04-27 20:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-27 13:23 ehci_hcd causes immediate wakeup from suspend to RAM or disk on Asus P4P800-VM Ondrej Zary
2010-04-27 14:22 ` [PATCH] ehci: Disable wake on overcurrent (WKOC_E) Ondrej Zary
2010-04-27 16:25 ` [PATCH v2] [RFC] ehci: Disable wake on overcurrent (WKOC_E) and disconnect (WKDISC_E) Ondrej Zary
2010-04-27 19:21 ` Alan Stern
2010-04-27 20:46 ` Ondrej Zary [this message]
2010-04-27 21:33 ` Greg KH
2010-04-28 15:41 ` Alan Stern
2010-04-28 17:30 ` Ondrej Zary
2010-04-29 16:16 ` Alan Stern
2010-04-29 17:45 ` [linux-pm] " Alan Stern
2010-04-29 21:14 ` Ondrej Zary
2010-05-04 5:37 ` Du, Alek
2010-05-05 3:12 ` Du, Alek
2010-05-05 15:55 ` Alan Stern
2010-05-06 0:11 ` Du, Alek
2010-05-06 8:23 ` Du, Alek
2010-05-06 14:46 ` Alan Stern
2010-05-06 15:20 ` Du, Alek
2010-05-06 16:06 ` Alan Stern
2010-05-07 1:32 ` Du, Alek
2010-05-07 15:20 ` Alan Stern
2010-05-08 2:00 ` Du, Alek
[not found] ` <6C44CD31806DCD4BB88546DAB7AFC9A201EB5A39FA@shsmsx502.ccr.corp.intel.com>
2010-05-10 2:25 ` Du, Alek
2010-05-10 21:05 ` Alan Stern
2010-05-11 3:31 ` Du, Alek
2010-05-11 14:01 ` Alan Stern
2010-05-11 15:58 ` Alan Stern
2010-05-11 16:10 ` Du, Alek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201004272246.51494.linux@rainbow-software.org \
--to=linux@rainbow-software.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox