Update the USB core to deal with USB 3.0 hubs. These hubs have a slightly
different hub descriptor than USB 2.0 hubs, with a fixed (rather than
variable length) size. Change the USB core's hub descriptor to have a
union for the last fields that differ. Change the host controller drivers
that access those last fields (DeviceRemovable and PortPowerCtrlMask) to
use the union.
Translate the new version of the hub port status field into the old
version that khubd understands. (Note: we need to fix it to translate the
roothub's port status once we stop converting it to USB 2.0 hub status
internally.)
Add new code to handle link state change status. Send out new control
messages that are needed for USB 3.0 hubs, like Set Hub Depth.
This patch is a modified version of the original patch submitted by John
Youn. It's updated to reflect the removal of the "bitmap" #define, and
change the hub descriptor accesses of a couple new host controller
drivers.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Cc: Tony Olech <tony.olech@elandigitalsystems.com>
Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: Max Vozeler <mvz@vozeler.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Rodolfo Giometti <giometti@linux.it>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Anton Vorontsov <avorontsov@mvista.com>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Lothar Wassmann <LW@KARO-electronics.de>
Cc: Olav Kongas <ok@artecdesign.ee>
Cc: Martin Fuzzey <mfuzzey@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <dbrownell@users.sourceforge.net>
This patch (as1394) adds code to ehci-hcd, ohci-hcd, and uhci-hcd for
automatically resuming the root hub when the controller is resumed, if
the root hub has a wakeup request pending on some port.
During resume from system sleep this doesn't matter, because the root
hubs will naturally be resumed along with every other device in the
system. However it _will_ matter for runtime PM: If the controller is
suspended and a remote wakeup request is received then the controller
will autoresume, but we need to ensure that the root hub also
autoresumes. Otherwise the wakeup request would be ignored, the
controller would go back to sleep, and the cycle would repeat a large
number of times (I saw this happen before the patch was written).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1393) converts several of the single-bit fields in
struct usb_hcd to atomic flags. This is for safety's sake; not all
CPUs can update bitfield values atomically, and these flags are used
in multiple contexts.
The flag fields that are set only during registration or removal can
remain as they are, since non-atomic accesses at those times will not
cause any problems.
(Strictly speaking, the authorized_default flag should become atomic
as well. I didn't bother with it because it gets changed only via
sysfs. It can be done later, if anyone wants.)
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1371) fixes a small bug in ohci-hcd. The HCD already
knows how many ports the controller has; there's no need to go looking
at the root hub's usb_device structure to find out. Especially since
the root hub's maxchild value is set correctly only while the root hub
is bound to the hub driver.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1149) fixes an obscure problem in OHCI polling. In the
current code, if the RHSC interrupt status flag turns on at a time
when RHSC interrupts are disabled, it will remain on forever:
The interrupt handler is the only place where RHSC status
gets turned back off;
The interrupt handler won't turn RHSC status off because it
doesn't turn off status flags if the corresponding interrupt
isn't enabled;
RHSC interrupts will never get enabled because
ohci_root_hub_state_changes() doesn't reenable RHSC if RHSC
status is on!
As a result we will continue polling indefinitely instead of reverting
to interrupt-driven operation, and the root hub will not autosuspend.
This particular sequence of events is not at all unusual; in fact
plugging a USB device into an OHCI controller will usually cause it to
occur.
Of course, this is a bug. The proper thing to do is to turn off RHSC
status just before reading the actual port status values. That way
either a port status change will be detected (if it occurs before the
status read) or it will turn RHSC back on. Possibly both, but that
won't hurt anything.
We can still check for systems in which RHSC is totally broken, by
re-reading RHSC after clearing it and before reading the port
statuses. (This re-read has to be done anyway, to post the earlier
write.) If RHSC is on but no port-change statuses are set, then we
know that RHSC is broken and we can avoid re-enabling it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1134) attempts to improve the way we handle OHCI
controllers with broken Root Hub Status Change interrupt support. In
these controllers the RHSC interrupt bit essentially never turns off,
making RHSC interrupts useless -- they have to remain permanently
disabled.
Such controllers should still be allowed to turn off their root hubs
when no devices are attached. Polling for new connections can
continue while the root hub is suspended. The patch implements this
feature. (It won't have much effect unless CONFIG_PM is enabled and
CONFIG_USB_SUSPEND is disabled, but since the overhead is very small
we may as well do it.)
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1069c) changes the way OHCI root-hub status-change
interrupts are enabled. Currently a special HCD method,
hub_irq_enable(), is called when the hub driver is finished using a
root hub. This approach turns out to be subject to races, resulting
in unnecessary polling.
The patch does away with the method entirely. Instead, the driver
automatically enables the RHSC interrupt when no more status changes
are present. This scheme is safe with controllers using
level-triggered semantics for their interrupt flags.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1114) fixes a problem that was revealed by an earlier
patch (as1069b). Some broken controllers seem never to turn off their
RHCS interrupt status bit, even when told to do so. As a result they
generate an interrupt storm and hang the system.
The patch avoids enabling RHSC interrupt requests when the RHCS status
bit is already set. This should have no adverse affects on normal
controllers, since they won't set the status bit until a root-hub
status change actually occurs, in which case we wouldn't enable RHSC
interrupt requests anyway -- we would wait until the status change had
been processed and cleared.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested by: Andrey Borzenkov <arvidjaar@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This reverts commit e872154921.
Andrey Borzenkov reports that it resulted in a totally hung machine for
him when loading the OHCI driver. Extensive netconsole capture with
SysRq output shows that modprobe gets stuck in ohci_hub_status_data()
when probing and enabling the OHCI controller, see for example
http://lkml.org/lkml/2008/7/5/236
for an analysis.
The problem appears to be an interrupt flood triggered by the commit
that gets reverted, and Andrey confirmed that the revert makes things
work for him again.
Reported-and-tested-by: Andrey Borzenkov <arvidjaar@mail.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: David Brownell <david-b@pacbell.net>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The patch (as1086) works around a bogus "uninitialized variable"
warning generated by some versions of GCC.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1069b) changes the way OHCI root-hub status-change
interrupts are enabled. Currently a special HCD method,
hub_irq_enable(), is called when the hub driver is finished using a
root hub. This approach turns out to be subject to races, resulting
in unnecessary polling.
The patch does away with the method entirely. Instead, the driver
automatically enables the RHSC interrupt when no more status changes
are present. This scheme is safe with controllers using
level-triggered semantics for their interrupt flags.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1068b) disables the RD interrupt flag when an OHCI root
hub is suspended with remote wakeup disabled. Although the spec
clearly states that this flag permits the controller to issue an
interrupt when a resume request from downstream is detected and not
when a local status change occurs, some controllers mistakenly use it
for both types of event.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When a USB device is suspended, whether or not it is enabled for
remote wakeup depends on the device_may_wakeup() setting. The setting
is then saved in the do_remote_wakeup flag.
Later on, however, the device_may_wakeup() value can change because of
user activity. So when testing whether a suspended device is or
should be enabled for remote wakeup, we should always test
do_remote_wakeup instead of device_may_wakeup(). This patch (as1076)
makes that change for root hubs in several places.
The patch also adjusts uhci-hcd so that when an autostopped controller
is suspended, the remote wakeup setting agrees with the value recorded
in the root hub's do_remote_wakeup flag.
And the patch adjusts ehci-hcd so that wakeup events on selectively
suspended ports (i.e., the bus itself isn't suspended) don't turn on
the PME# wakeup signal.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Drivers in the ohci-hcd family should perform certain tasks whenever
their controller device is resumed. These include checking for loss
of power during suspend, turning on port power, and enabling interrupt
requests.
Until now these jobs have been carried out when the root hub is
resumed, not when the controller is. Many drivers work around the
resulting awkwardness by automatically resuming their root hub
whenever the controller is resumed. But this is wasteful and
unnecessary.
To simplify the situation, this patch (as1066) adds a new core
routine, ohci_finish_controller_resume(), which can be used by all the
OHCI-variant drivers. They can call the new routine instead of
resuming their root hubs. And ohci-pci.c can call it instead of using
its own special-purpose handler.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This limits how long the OHCI port reset loop waits for the hardware
to do its job, if the controller either (a) dies, or (b) can't finish
the reset. Such limits are always a good idea.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes a silicon bug in some NEC OHCI chips. The bug appears
at random times and is very, very difficult to reproduce. Without the
following patch, Linux would shut the chip and its associated devices
down. In Apple PowerBooks this leads to an unusable keyboard and mouse
(SSH still working). The idea of restarting the chip is taken from
public Darwin code.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as901) fixes an oversight in ohci-hcd. The
hub_status_data routine must not try to access the controller's
memory-mapped registers if the controller is in a low-power state;
such attempts will cause a crash on some architectures (such as PPC).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I have found a problem where the root_port_reset() goes into an infinite
loop and stalls the kernel.
This happens when a hardware fault inside the machine occurs during a small
timing window. In case of USB device connection, if a USB device responds to
hcd_submit_urb(), and later the controller fails before root_port_reset(),
root_port_reset() will loop infinitely because ohci_readl() will always
return "-1". Such a failure can include ejecting a CardBus OHCI controller.
The probability of this problem is low, but it will increase if PnP type
usage is frequent. The attached patch can solve this problem and I believe
that it is better to fix this problem.
Signed-off-by: Takamasa Ohtake <ohtake-txa@necst.nec.co.jp>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is an OHCI cleanup patch ... it removes a lot of erroneous whitespace
(space before tab, at end of line) as well as the obsolete inline changelog.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Unlike UHCI, OHCI does not exert any DMA load on the system when no
devices are connected. Consequently there is no advantage to doing
an autostop other than the power savings, so we shouldn't compile the
necessary code unless CONFIG_PM is enabled.
This patch (as820) makes the root-hub suspend and resume routines
conditional on CONFIG_PM. It also prevents autostop from activating
if the device_may_wakeup flag isn't set; some people use this flag to
alert the driver about Resume-Detect bugs in the hardware.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
All the other root-hub suspend or resume log messages, in ohci-hcd or
any of the other host controller drivers, use the debug priority
level. This patch (as815) makes the one single exception behave like
all the rest.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as811) removes some stale testing code from the root-hub
resume routine in ohci-hcd. It also adds a spin_lock_irq() call that
inadvertently got left out of an error pathway.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
John Youn
Sarah Sharp
Alan Stern
Dmitry Baryshkov
Linus Torvalds
Harvey Harrison
David Brownell
Michael Hanselmann
Takamasa Ohtake