Re: [PATCH v2] [RFC] ehci: Disable wake on overcurrent (WKOC_E) anddisconnect (WKDISC_E)

[Alan Stern]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/