We've had another report of the "chipmunk" sound on a Logitech C600 webcam.
This patch resolves the issue.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-usb-linus' of ra.kernel.org:/pub/scm/linux/kernel/git/sarah/xhci:
usb, xhci: Clear warm reset change event during init
xhci: Set slot and ep0 flags for address command.
usb, xhci: fix lockdep warning on endpoint timeout
* 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits)
Revert "tracing: Include module.h in define_trace.h"
irq: don't put module.h into irq.h for tracking irqgen modules.
bluetooth: macroize two small inlines to avoid module.h
ip_vs.h: fix implicit use of module_get/module_put from module.h
nf_conntrack.h: fix up fallout from implicit moduleparam.h presence
include: replace linux/module.h with "struct module" wherever possible
include: convert various register fcns to macros to avoid include chaining
crypto.h: remove unused crypto_tfm_alg_modname() inline
uwb.h: fix implicit use of asm/page.h for PAGE_SIZE
pm_runtime.h: explicitly requires notifier.h
linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h
miscdevice.h: fix up implicit use of lists and types
stop_machine.h: fix implicit use of smp.h for smp_processor_id
of: fix implicit use of errno.h in include/linux/of.h
of_platform.h: delete needless include <linux/module.h>
acpi: remove module.h include from platform/aclinux.h
miscdevice.h: delete unnecessary inclusion of module.h
device_cgroup.h: delete needless include <linux/module.h>
net: sch_generic remove redundant use of <linux/module.h>
net: inet_timewait_sock doesnt need <linux/module.h>
...
Fix up trivial conflicts (other header files, and removal of the ab3550 mfd driver) in
- drivers/media/dvb/frontends/dibx000_common.c
- drivers/media/video/{mt9m111.c,ov6650.c}
- drivers/mfd/ab3550-core.c
- include/linux/dmaengine.h
Originally, the runtime PM core would send an idle notification
whenever a suspend attempt failed. The idle callback routine could
then schedule a delayed suspend for some time later.
However this behavior was changed by commit
f71648d73c (PM / Runtime: Remove idle
notification after failing suspend). No notifications were sent, and
there was no clear mechanism to retry failed suspends.
This caused problems for the usbhid driver, because it fails
autosuspend attempts as long as a key is being held down. A companion
patch changes the PM core's behavior, but we also need to change the
USB core. In particular, this patch (as1493) updates the device's
last_busy time when an autosuspend fails, so that the PM core will
retry the autosuspend in the future when the delay time expires
again.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Cc: <stable@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
I noticed on my Panther Point system that I wasn't getting hotplug events
for my usb3.0 disk on a usb3 port. I tracked it down to the fact that the
system had the warm reset change bit still set. This seemed to block future
events from being received, including a hotplug event.
Clearing this bit during initialization allowed the hotplug event to be
received and the disk to be recognized correctly.
This patch should be backported to kernels as old as 2.6.39.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
With module.h being implicitly everywhere via device.h, the absence
of explicitly including something for EXPORT_SYMBOL went unnoticed.
Since we are heading to fix things up and clean module.h from the
device.h file, we need to explicitly include these files now.
Use the lightweight version of the header that has just THIS_MODULE
and EXPORT_SYMBOL variants.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* 'pm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (63 commits)
PM / Clocks: Remove redundant NULL checks before kfree()
PM / Documentation: Update docs about suspend and CPU hotplug
ACPI / PM: Add Sony VGN-FW21E to nonvs blacklist.
ARM: mach-shmobile: sh7372 A4R support (v4)
ARM: mach-shmobile: sh7372 A3SP support (v4)
PM / Sleep: Mark devices involved in wakeup signaling during suspend
PM / Hibernate: Improve performance of LZO/plain hibernation, checksum image
PM / Hibernate: Do not initialize static and extern variables to 0
PM / Freezer: Make fake_signal_wake_up() wake TASK_KILLABLE tasks too
PM / Hibernate: Add resumedelay kernel param in addition to resumewait
MAINTAINERS: Update linux-pm list address
PM / ACPI: Blacklist Vaio VGN-FW520F machine known to require acpi_sleep=nonvs
PM / ACPI: Blacklist Sony Vaio known to require acpi_sleep=nonvs
PM / Hibernate: Add resumewait param to support MMC-like devices as resume file
PM / Hibernate: Fix typo in a kerneldoc comment
PM / Hibernate: Freeze kernel threads after preallocating memory
PM: Update the policy on default wakeup settings
PM / VT: Cleanup #if defined uglyness and fix compile error
PM / Suspend: Off by one in pm_suspend()
PM / Hibernate: Include storage keys in hibernation image on s390
...
To add USB 3.0 link power management (LPM), we need to know what the U1
and U2 exit latencies are for the xHCI host controller. External USB 3.0
hubs report these values through the SuperSpeed Capabilities descriptor in
the BOS descriptor. Make the USB 3.0 roothub for the xHCI host behave
like an external hub and return the BOS descriptors.
The U1 and U2 exit latencies will vary across each host controller, so we
need to dynamically fill those values in by reading the exit latencies out
of the xHC registers. Make the roothub code in the USB core handle
hub_control() returning the length of the data copied.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* pm-runtime:
PM / Tracing: build rpm-traces.c only if CONFIG_PM_RUNTIME is set
PM / Runtime: Replace dev_dbg() with trace_rpm_*()
PM / Runtime: Introduce trace points for tracing rpm_* functions
PM / Runtime: Don't run callbacks under lock for power.irq_safe set
USB: Add wakeup info to debugging messages
PM / Runtime: pm_runtime_idle() can be called in atomic context
PM / Runtime: Add macro to test for runtime PM events
PM / Runtime: Add might_sleep() to runtime PM functions
My webcam is a Logitech C300 and I get "chipmunk"ed squeaky sound.
The following trivial patch fixes it.
Signed-off-by: Jon Levell <linuxusb@coralbark.net>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add to the dev_state and alloc_async structures the user namespace
corresponding to the uid and euid. Pass these to kill_pid_info_as_uid(),
which can then implement a proper, user-namespace-aware uid check.
Changelog:
Sep 20: Per Oleg's suggestion: Instead of caching and passing user namespace,
uid, and euid each separately, pass a struct cred.
Sep 26: Address Alan Stern's comments: don't define a struct cred at
usbdev_open(), and take and put a cred at async_completed() to
ensure it lasts for the duration of kill_pid_info_as_cred().
Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
"length" is type size_t so the cast to unsigned int truncates the
upper bytes. This isn't an issue in real life (I've checked the
callers) but it's a bit messy.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1487) improves the usbcore debugging output for port
suspend and bus suspend, by stating whether or not remote wakeup is
enabled.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
In the usb printer class specific request get_device_id the value of
wIndex is (interface << 8 | altsetting) instead of just interface.
This enables the detection of some printers with libusb.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Matthias Dellweg <2500@gmx.de>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern points out that after spin_unlock(&ps->lock) there is no
guarantee that ps->pid won't be freed. Since kill_pid_info_as_uid() is
called after the spin_unlock(), the pid passed to it must be pinned.
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1486) implements the kernel's new wakeup policy for USB
host controllers. Since they don't generate wakeup requests on their
but merely forward requests from their root hubs toward the CPU, they
should be enabled for wakeup by default.
Also, to be compliant with both the old and new policies, root hubs
should not be enabled for remote wakeup by default. Userspace must
enable it explicitly if it is desired.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds sysfs support to xHCI usb2 hardware LPM, so developer can
enable and disable usb2 hardware LPM manually for test purpose.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If the device pass the USB2 software LPM and the host supports hardware
LPM, enable hardware LPM for the device to let the host decide when to
put the link into lower power state.
If hardware LPM is enabled for a port and driver wants to put it into
suspend, it must first disable hardware LPM, resume the port into U0,
and then suspend the port.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Check device's LPM capability by examining the bmAttibutes field of the
USB2.0 Extension Descriptor.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This commit gets BOS(Binary Device Object Store) descriptor set for Super
Speed devices and High Speed devices which support BOS descriptor.
BOS descriptor is used to report additional USB device-level capabilities
that are not reported via the Device descriptor. By getting BOS descriptor
set, driver can check device's device-level capability such as LPM
capability.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When a hot reset (standard USB port reset) fails on a USB 3.0 port, the
host controller transitions to the "Error" state. It reports the port
link state as "Inactive", sets the link state change flag, and (if the
device disconnects) also reports the disconnect and connect change status.
It's also supposed to transition the link state to "RxDetect", but the NEC
µPD720200 xHCI host does not.
Unfortunately, Harald found that the combination of the NEC µPD720200 and
a LogiLink USB 3.0 to SATA adapter triggered this issue. The USB core
would reset the device, the port would go into this error state, and the
device would never be enumerated. This combination works under Windows,
but not under Linux.
When a hot reset fails on a USB 3.0 port, and the link state is reported
as Inactive, fall back to a warm port reset instead. Harald confirms that
with a warm port reset (along with all the change bits being correctly
cleared), the USB 3.0 device will successfully enumerate.
Harald also had to add two other patches ("xhci: Set change bit when warm
reset change is set." and "usbcore: refine warm reset logic") to make this
setup work. Since the warm reset refinement patch is not destined for the
stable kernels (it's too big), this patch should not be backported either.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=41752
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Harald Brennich <harald.brennich@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current waiting time for warm(BH) reset in hub_port_warm_reset() is too short
for xHC host to complete the warm reset and report a BH reset change.
This patch increases the waiting time for warm reset and merges the function
into hub_port_reset(), so it can handle both cold reset and warm reset, and
factor out hub_port_finish_reset() to make the code looks cleaner.
This fixes the issue that driver fails to clear BH reset change and port is
"dead".
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The new runtime PM code has shown that many webcams suffer
from a race condition that may crash them upon resume.
Runtime PM is especially prone to show the problem because
it retains power to the cameras at all times. However
system suspension may also crash the devices and retain
power to the devices.
The only way to solve this problem without races is in
usbcore with the RESET_RESUME quirk.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In a few places in the kernel, the code prints
a human-readable USB device speed (eg. "high speed").
This involves a switch statement sometimes wrapped
around in ({ ... }) block leading to code repetition.
To mitigate this issue, this commit introduces
usb_speed_string() function, which returns
a human-readable name of provided speed.
It also changes a few places switch was used to use
this new function. This changes a bit the way the
speed is printed in few instances at the same time
standardising it.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A return value of -EINPROGRESS from pm_runtime_get indicates that
the device is already resuming due to a previous call. Internally,
usb_autopm_get_interface_async doesn't treat this as an error and
increments the usage count, but passes the error status along
to the caller. The logical assumption of the caller is that
any negative return value reflects the device not resuming
and the pm_usage_cnt not being incremented. Since the usage count
is being incremented and the device is resuming, return success (0)
instead.
Signed-off-by: James Wylder <james.wylder@motorola.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Now ${LINUX}/drivers/usb/* can use usb_endpoint_maxp(desc) to get maximum packet size
instead of le16_to_cpu(desc->wMaxPacketSize).
This patch fix it up
Cc: Armin Fuerst <fuerst@in.tum.de>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Johannes Erdfelt <johannes@erdfelt.com>
Cc: Vojtech Pavlik <vojtech@suse.cz>
Cc: Oliver Neukum <oliver@neukum.name>
Cc: David Kubicek <dave@awk.cz>
Cc: Johan Hovold <jhovold@gmail.com>
Cc: Brad Hards <bhards@bigpond.net.au>
Acked-by: Felipe Balbi <balbi@ti.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Dahlmann <dahlmann.thomas@arcor.de>
Cc: David Brownell <david-b@pacbell.net>
Cc: David Lopo <dlopo@chipidea.mips.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Michal Nazarewicz <m.nazarewicz@samsung.com>
Cc: Xie Xiaobo <X.Xie@freescale.com>
Cc: Li Yang <leoli@freescale.com>
Cc: Jiang Bo <tanya.jiang@freescale.com>
Cc: Yuan-hsin Chen <yhchen@faraday-tech.com>
Cc: Darius Augulis <augulis.darius@gmail.com>
Cc: Xiaochen Shen <xiaochen.shen@intel.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: OKI SEMICONDUCTOR, <toshiharu-linux@dsn.okisemi.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Ben Dooks <ben@simtec.co.uk>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Herbert Pötzl <herbert@13thfloor.at>
Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
Cc: Roman Weissgaerber <weissg@vienna.at>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Tony Olech <tony.olech@elandigitalsystems.com>
Cc: Florian Floe Echtler <echtler@fs.tum.de>
Cc: Christian Lucht <lucht@codemercs.com>
Cc: Juergen Stuber <starblue@sourceforge.net>
Cc: Georges Toth <g.toth@e-biz.lu>
Cc: Bill Ryder <bryder@sgi.com>
Cc: Kuba Ober <kuba@mareimbrium.org>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In drivers/usb/core/hub.c::usb_disconnect(), 'udev' will never be
NULL, so remove the test and printing of debug message.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1482) adds a macro for testing whether or not a
pm_message value represents an autosuspend or autoresume (i.e., a
runtime PM) event. Encapsulating this notion seems preferable to
open-coding the test all over the place.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
usb_ifnum_to_if() can return NULL if the USB device does not have a
configuration installed (usb_device->actconfig == NULL), or if we can't
find the interface number in the installed configuration. Return an
error instead of crashing.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
wMaxPacketSize is __le16 and should be accessed as such. Also fix the
wBytesPerInterval assignment while here.
v2: also fix the wBytesPerInterval assigment, noticed by Matt Evans
This patch should be backported to the 3.0 kernel.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Matt Evans <matt@ozlabs.org>
Cc: stable@kernel.org
* 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (115 commits)
EHCI: fix direction handling for interrupt data toggles
USB: serial: add IDs for WinChipHead USB->RS232 adapter
USB: OHCI: fix another regression for NVIDIA controllers
usb: gadget: m66592-udc: add pullup function
usb: gadget: m66592-udc: add function for external controller
usb: gadget: r8a66597-udc: add pullup function
usb: renesas_usbhs: support multi driver
usb: renesas_usbhs: inaccessible pipe is not an error
usb: renesas_usbhs: care buff alignment when dma handler
USB: PL2303: correctly handle baudrates above 115200
usb: r8a66597-hcd: fixup USB_PORT_STAT_C_SUSPEND shift
usb: renesas_usbhs: compile/config are rescued
usb: renesas_usbhs: fixup comment-out
usb: update email address in ohci-sh and r8a66597-hcd
usb: r8a66597-hcd: add function for external controller
EHCI: only power off port if over-current is active
USB: mon: Allow to use usbmon without debugfs
USB: EHCI: go back to using the system clock for QH unlinks
ehci: add pci quirk for Ordissimo and RM Slate 100 too
ehci: refactor pci quirk to use standard dmi_check_system method
...
Fix up trivial conflicts in Documentation/feature-removal-schedule.txt
Commit e534c5b831 (USB: fix regression
occurring during device removal) didn't go far enough. It failed to
take into account that when a driver claims multiple interfaces, it may
release them all at the same time. As a result, some interfaces can
get released before they are unregistered, and we deadlock trying to
acquire the bandwidth_mutex that we already own.
This patch (asl478) handles this case by setting the "unregistering"
flag on all the interfaces before removing any of them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Tested-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1476) fixes a regression introduced by
fccf4e8620 (USB: Free bandwidth when
usb_disable_device is called). usb_disconnect() grabs the
bandwidth_mutex before calling usb_disable_device(), which calls down
indirectly to usb_set_interface(), which tries to acquire the
bandwidth_mutex.
The fix causes usb_set_interface() to return early when it is called
for an interface that has already been unregistered, which is what
happens in usb_disable_device().
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
MAINTAINERS: add myself as maintainer of USB/IP
usb: r8a66597-hcd: fix cannot detect low/full speed device
USB: ehci-ath79: fix a NULL pointer dereference
USB: Add new FT232H chip to drivers/usb/serial/ftdi_sio.c
usb/isp1760: Fix bug preventing the unlinking of control urbs
USB: Fix up URB error codes to reflect implementation.
xhci: Always set urb->status to zero for isoc endpoints.
xhci: Add reset on resume quirk for asrock p67 host
xHCI 1.0: Incompatible Device Error
USB: don't let errors prevent system sleep
USB: don't let the hub driver prevent system sleep
USB: change maintainership of ohci-hcd and ehci-hcd
xHCI 1.0: Force Stopped Event(FSE)
xhci: Don't warn about zeroed bMaxBurst descriptor field.
USB: Free bandwidth when usb_disable_device is called.
xhci: Reject double add of active endpoints.
USB: TI 3410/5052 USB Serial Driver: Fix mem leak when firmware is too big.
usb: musb: gadget: clear TXPKTRDY flag when set FLUSHFIFO
usb: musb: host: compare status for negative error values
* 'for-usb-linus' of git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sarah/xhci:
USB: Fix up URB error codes to reflect implementation.
xhci: Always set urb->status to zero for isoc endpoints.
xhci: Add reset on resume quirk for asrock p67 host
xHCI 1.0: Incompatible Device Error
xHCI 1.0: Force Stopped Event(FSE)
xhci: Don't warn about zeroed bMaxBurst descriptor field.
USB: Free bandwidth when usb_disable_device is called.
xhci: Reject double add of active endpoints.
This patch (as1473) renames the "in_suspend" field in struct
dev_pm_info to "is_prepared", in preparation for an upcoming change.
The new name is more descriptive of what the field really means.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: stable@kernel.org
This patch (as1464) implements the recommended policy that most errors
during suspend or hibernation should not prevent the system from going
to sleep. In particular, failure to suspend a USB driver or a USB
device should not prevent the sleep from succeeding:
Failure to suspend a device won't matter, because the device will
automatically go into suspend mode when the USB bus stops carrying
packets. (This might be less true for USB-3.0 devices, but let's not
worry about them now.)
Failure of a driver to suspend might lead to trouble later on when the
system wakes up, but it isn't sufficient reason to prevent the system
from going to sleep.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1465) continues implementation of the policy that errors
during suspend or hibernation should not prevent the system from going
to sleep.
In this case, failure to turn on the Suspend feature for a hub port
shouldn't be reported as an error. There are situations where this
does actually occur (such as when the device plugged into that port
was disconnected in the recent past), and it turns out to be harmless.
There's no reason for it to prevent a system sleep.
Also, don't allow the hub driver to fail a system suspend if the
downstream ports aren't all suspended. This is also harmless (and
should never happen, given the change mentioned above); printing a
warning message in the kernel log is all we really need to do.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tanya ran into an issue when trying to switch a UAS device from the BOT
configuration to the UAS configuration via the bConfigurationValue sysfs
file. Before installing the UAS configuration, set_bConfigurationValue()
calls usb_disable_device(). That function is supposed to remove all host
controller resources associated with that device, but it leaves some state
in the xHCI host controller.
Commit 0791971ba8
usb: allow drivers to use allocated bandwidth until unbound
added a call to usb_disable_device() in usb_set_configuration(), before
the xHCI bandwidth functions were invoked. That commit fixed a bug, but
also introduced a bug that is triggered when a configured device is
switched to a new configuration.
usb_disable_device() goes through all the motions of unbinding the drivers
attached to active interfaces and removing the USB core structures
associated with those interfaces, but it doesn't actually remove the
endpoints from the internal xHCI host controller bandwidth structures.
When usb_disable_device() calls usb_disable_endpoint() with reset_hardware
set to true, the entries in udev->ep_out and udev->ep_in will be set to
NULL. Usually, when the USB core installs a new configuration,
usb_hcd_alloc_bandwidth() will drop all non-NULL endpoints in udev->ep_out
and udev->ep_in before adding any new endpoints. However, when the new
UAS configuration was added, all those entries were null, so none of the
old endpoints in the BOT configuration were dropped.
The xHCI driver blindly added the UAS configuration endpoints, and some of
the endpoint addresses overlapped with the old BOT configuration
endpoints. This caused the xHCI host to reject the Configure Endpoint
command. Now that the xHCI driver code is cleaned up to reject a
double-add of active endpoints, we need to fix the USB core to properly
drop old endpoints in usb_disable_device().
If the host controller driver needs bandwidth checking support, make
usb_disable_device() call usb_disable_endpoint() with
reset_hardware set to false, drop the endpoints from the xHCI host
controller, and then call usb_disable_endpoint() again with
reset_hardware set to true.
The first call to usb_disable_endpoint() will cancel any pending URBs and
wait on them to be freed in usb_hcd_disable_endpoint(), but will keep the
pointers in udev->ep_out and udev->ep in intact. Then
usb_hcd_alloc_bandwidth() will use those pointers to know which endpoints
to drop.
The final call to usb_disable_endpoint() will do two things:
1. It will call usb_hcd_disable_endpoint() again, which should be harmless
since the ep->urb_list should be empty after the first call to
usb_disable_endpoint() returns.
2. It will set the entries in udev->ep_out and udev->ep in to NULL, and call
usb_hcd_disable_endpoint(). That call will have no effect, since the xHCI
driver doesn't set the endpoint_disable function pointer.
Note that usb_disable_device() will now need to be called with
hcd->bandwidth_mutex held.
This should be backported to kernels as old as 2.6.32.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Tanya Brokhman <tlinder@codeaurora.org>
Cc: ablay@codeaurora.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@kernel.org
The "authorized_default" module parameter of usbcore controls the default
for the authorized_default variable of each USB host controller.
-1 is authorized for all devices except wireless (default, old behaviour)
0 is unauthorized for all devices
1 is authorized for all devices
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Commit 64252c75a (vfs: remove dget() from dentry_unhash()) removed the
useless dget from dentry_unhash but didn't fix up this caller in the usb
code. There used to be exactly one dput per dentry_unhash call; now
there are none.
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sage Weil <sage@newdream.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Protocol stall should not be fatal while reading port or hub status as it is
transient state. Currently hub EP0 STALL during port status read results in
failed device enumeration. This has been observed with ST-Ericsson (formerly
Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1467) removes the last usages of hcd->state from
usbcore. We no longer check to see if an interrupt handler finds that
a controller has died; instead we rely on host controller drivers to
make an explicit call to usb_hc_died().
This fixes a regression introduced by commit
9b37596a2e (USB: move usbcore away from
hcd->state). It used to be that when a controller shared an IRQ with
another device and an interrupt arrived while hcd->state was set to
HC_STATE_HALT, the interrupt handler would be skipped. The commit
removed that test; as a result the current code doesn't skip calling
the handler and ends up believing the controller has died, even though
it's only temporarily stopped. The solution is to ignore HC_STATE_HALT
following the handler's return.
As a consequence of this change, several of the host controller
drivers need to be modified. They can no longer implicitly rely on
usbcore realizing that a controller has died because of hcd->state.
The patch adds calls to usb_hc_died() in the appropriate places.
The patch also changes a few of the interrupt handlers. They don't
expect to be called when hcd->state is equal to HC_STATE_HALT, even if
the controller is still alive. Early returns were added to avoid any
confusion.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Manuel Lauss <manuel.lauss@googlemail.com>
CC: Rodolfo Giometti <giometti@linux.it>
CC: Olav Kongas <ok@artecdesign.ee>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some USB3.0 devices go to SS.Inactive state when hot plug to USB3 ports.
Warm reset the port to transition it to U0 state.
This patch fixes the issue that Kingston USB3.0 flash drive can not be
recognized when hot plug to USB3 port.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
In the past, we use USB2.0 request to suspend and resume a USB3.0 device.
Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request,
instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device
suspend/resume comply with USB3.0 specification.
This patch fixes the issue that USB3.0 device can not be suspended when
connected to a USB3.0 external hub.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
USB3.0 specification has different wPortStatus and wPortChange definitions
from USB2.0 specification. Since USB3 root hub and USB2 root hub are split
now and USB3 hub only has USB3 protocol ports, we should modify the
portstatus and portchange report of USB3 ports to comply with USB3.0
specification.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
while going through Tatyana's changes for the gadget framework I noticed
that this type is not defined as __le16.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The usb_create_sysfs_intf_files() function always returned zero even
if it failed to create sysfs fails. Since this is a desired behaviour
there is no need to return return code at all. This commit changes
function's return type (form int) to void.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If USB type detections fails, we run into default and return 0.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch clear PORT_POWER when suspend a USB3.0 device behind a USB3.0
external hub, so the system can suspend and resume.
Note USB3.0 device may not work after system resume and this is a temporary
workaround. The correct fix will be in future patches.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
If I unplug a device while the UAS driver is loaded, I get an oops
in usb_free_streams(). This is because usb_unbind_interface() calls
usb_disable_interface() which calls usb_disable_endpoint() which sets
ep_out and ep_in to NULL. Then the UAS driver calls usb_pipe_endpoint()
which returns a NULL pointer and passes an array of NULL pointers to
usb_free_streams().
I think the correct fix for this is to check for the NULL pointer
in usb_free_streams() rather than making the driver check for this
situation. My original patch for this checked for dev->state ==
USB_STATE_NOTATTACHED, but the call to usb_disable_interface() is
conditional, so not all drivers would want this check.
Note from Sarah Sharp: This patch does avoid a potential dereference,
but the real fix (which will be implemented later) is to set the
.soft_unbind flag in the usb_driver structure for the UAS driver, and
all drivers that allocate streams. The driver should free any streams
when it is unbound from the interface. This avoids leaking stream rings
in the xHCI driver when usb_disable_interface() is called.
This should be queued for stable trees back to 2.6.35.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
The `name' variable is unused in usb_deregister_dev() since commit d6e5bcf
(devfs: Remove the mode field from usb_class_driver as it's no longer needed).
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Isochronous and interrupt SuperSpeed endpoints use the same mechanisms
for decoding bInterval values as HighSpeed ones so adjust the code
accordingly.
Also bandwidth reservation for SuperSpeed matches highspeed, not
low/full speed.
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When `echo Y > /sys/module/usbcore/parameters/usbfs_snoop` and
usb_control_msg() returns error, a lot of kernel memory is dumped to dmesg
until unhandled kernel paging request occurs.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB defines usb_device_type pointing to usb_device_pm_ops that
provides system-wide PM callbacks only and usb_bus_type pointing to
usb_bus_pm_ops that provides runtime PM callbacks only. However,
the USB runtime PM callbacks may be defined in usb_device_pm_ops
which makes it possible to drop usb_bus_pm_ops and will allow us
to consolidate the handling of subsystems by the PM core code.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (172 commits)
USB: Add support for SuperSpeed isoc endpoints
xhci: Clean up cycle bit math used during stalls.
xhci: Fix cycle bit calculation during stall handling.
xhci: Update internal dequeue pointers after stalls.
USB: Disable auto-suspend for USB 3.0 hubs.
USB: Remove bogus USB_PORT_STAT_SUPER_SPEED symbol.
xhci: Return canceled URBs immediately when host is halted.
xhci: Fixes for suspend/resume of shared HCDs.
xhci: Fix re-init on power loss after resume.
xhci: Make roothub functions deal with device removal.
xhci: Limit roothub ports to 15 USB3 & 31 USB2 ports.
xhci: Return a USB 3.0 hub descriptor for USB3 roothub.
xhci: Register second xHCI roothub.
xhci: Change xhci_find_slot_id_by_port() API.
xhci: Refactor bus suspend state into a struct.
xhci: Index with a port array instead of PORTSC addresses.
USB: Set usb_hcd->state and flags for shared roothubs.
usb: Make core allocate resources per PCI-device.
usb: Store bus type in usb_hcd, not in driver flags.
usb: Change usb_hcd->bandwidth_mutex to a pointer.
...
After redefining CONFIG_PM to depend on (CONFIG_PM_SLEEP ||
CONFIG_PM_RUNTIME) the CONFIG_PM_OPS option is redundant and can be
replaced with CONFIG_PM.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
A subsequent patch will modify device_set_wakeup_capable() in such
a way that it will call functions which may sleep and therefore it
shouldn't be called under spinlocks. In preparation to that, modify
usb_set_device_state() to avoid calling device_set_wakeup_capable()
under device_state_lock.
Tested-by: Minchan Kim <minchan.kim@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Use the Mult and bMaxBurst values from the endpoint companion
descriptor to calculate the max length of an isoc transfer.
Add USB_SS_MULT macro to access Mult field of bmAttributes, at
Sarah's suggestion.
This patch should be queued for the 2.6.36 and 2.6.37 stable trees, since
those were the first kernels to have isochronous support for SuperSpeed
devices.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
USB 3.0 devices have a slightly different suspend sequence than USB
2.0/1.1 devices. There isn't support for USB 3.0 device suspend yet, so
make khubd leave autosuspend disabled for USB 3.0 hubs. Make sure that
USB 3.0 roothubs still have autosuspend enabled, since that path in the
xHCI driver works fine.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
USB_PORT_STAT_SUPER_SPEED is a made up symbol that the USB core used to
track whether USB ports had a SuperSpeed device attached. This is a
linux-internal symbol that was used when SuperSpeed and non-SuperSpeed
devices would show up under the same xHCI roothub. This particular
port status is never returned by external USB 3.0 hubs. (Instead they
have a USB_PORT_STAT_SPEED_5GBPS that uses a completely different speed
mask.)
Now that the xHCI driver registers two roothubs, USB 3.0 devices will only
show up under USB 3.0 hubs. Rip out USB_PORT_STAT_SUPER_SPEED and replace
it with calls to hub_is_superspeed().
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The hcd->flags are in a sorry state. Some of them are clearly specific to
the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
HCD_WAKEUP_PENDING), but some flags are related to PCI device state
(HCD_HW_ACCESSIBLE and HCD_SAW_IRQ). This is an issue when one PCI device
can have two roothubs that share the same IRQ line and hardware.
Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
serviced, or an URB is unlinked without an interrupt. (We can't tell if
the host actually serviced an interrupt for a particular bus, but we can
tell it serviced some interrupt.)
HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
roothubs as they are added, so it doesn't need to be modified.
HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
they are never set by the xHCI driver, since the roothub never needs to be
polled.
The usb_hcd's state field is a similar mess. Sometimes the state applies
to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
HC_STATE_QUIESCING. But sometimes the state refers to the roothub state:
HC_STATE_RESUMING and HC_STATE_SUSPENDED.
Alan Stern recently made the USB core not rely on the hcd->state variable.
Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
that code in. Remove all references to HC_STATE_HALT, since the xHCI
driver only sets and doesn't test those variables. We still have to set
HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
won't get registered if we don't set that.
Alan's patch made the USB core check a different variable when trying to
determine whether to suspend a roothub. The xHCI host has a split
roothub, where two buses are registered for one PCI device. Each bus in
the xHCI split roothub can be suspended separately, but both buses must be
suspended before the PCI device can be suspended. Therefore, make sure
that the USB core checks HCD_RH_RUNNING() for both roothubs before
suspending the PCI host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Introduce the notion of a PCI device that may be associated with more than
one USB host controller driver (struct usb_hcd). This patch is the start
of the work to separate the xHCI host controller into two roothubs: a USB
3.0 roothub with SuperSpeed-only ports, and a USB 2.0 roothub with
HS/FS/LS ports.
One usb_hcd structure is designated to be the "primary HCD", and a pointer
is added to the usb_hcd structure to keep track of that. A new function
call, usb_hcd_is_primary_hcd() is added to check whether the USB hcd is
marked as the primary HCD (or if it is not part of a roothub pair). To
allow the USB core and xHCI driver to access either roothub in a pair, a
"shared_hcd" pointer is added to the usb_hcd structure.
Add a new function, usb_create_shared_hcd(), that does roothub allocation
for paired roothubs. It will act just like usb_create_hcd() did if the
primary_hcd pointer argument is NULL. If it is passed a non-NULL
primary_hcd pointer, it sets usb_hcd->shared_hcd and usb_hcd->primary_hcd
fields. It will also skip the bandwidth_mutex allocation, and set the
secondary hcd's bandwidth_mutex pointer to the primary HCD's mutex.
IRQs are only allocated once for the primary roothub.
Introduce a new usb_hcd driver flag that indicates the host controller
driver wants to create two roothubs. If the HCD_SHARED flag is set, then
the USB core PCI probe methods will allocate a second roothub, and make
sure that second roothub gets freed during rmmod and in initialization
error paths.
When usb_hc_died() is called with the primary HCD, make sure that any
roothubs that share that host controller are also marked as being dead.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The xHCI driver essentially has both a USB 2.0 and a USB 3.0 roothub. So
setting the HCD_USB3 bits in the hcd->driver->flags is a bit misleading.
Add a new field to usb_hcd, bcdUSB. Store the result of
hcd->driver->flags & HCD_MASK in it. Later, when we have the xHCI driver
register the two roothubs, we'll set the usb_hcd->bcdUSB field to HCD_USB2
for the USB 2.0 roothub, and HCD_USB3 for the USB 3.0 roothub.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Change the bandwith_mutex in struct usb_hcd to a pointer. This will allow
the pointer to be shared across usb_hcds for the upcoming work to split
the xHCI driver roothub into a USB 2.0/1.1 and a USB 3.0 bus.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Refactor out the code in usb_add_hcd() to request the IRQ line for the
HCD. This will only need to be called once for the two xHCI roothubs, so
it's easier to refactor it into a function, rather than wrapping the long
if-else block into another if statement.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Make the labels for the goto statements in usb_hcd_pci_probe()
describe the cleanup they do, rather than being numbered err[1-4].
This makes it easier to add error handling later.
The error handling for this function looks a little fishy, since
set_hs_companion() isn't called until the very end of the function, and
clear_hs_companion() is called if this function fails earlier than that.
But it should be harmless to clear a NULL pointer, so leave the error
handling as-is.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Make the USB 3.0 roothub registered by the USB core have a SuperSpeed
Endpoint Companion Descriptor after the interrupt endpoint. All USB 3.0
devices are required to have this, and the USB 3.0 bus specification
(section 10.13.1) says which values the descriptor should have.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
In USB 3.0, there are two types of resets: a "hot" port reset and a "warm"
port reset. The hot port reset is always tried first, and involves
sending the reset signaling for a shorter amount of time. But sometimes
devices don't respond to the hot reset, and a "Bigger Hammer" is needed.
External hubs and roothubs will automatically try a warm reset when the
hot reset fails, and they will set a status change bit to indicate when
there is a "BH reset" change. Make sure the USB core clears that port
status change bit, or we'll get lots of status change notifications on the
interrupt endpoint of the USB 3.0 hub.
(Side note: you may be confused why the USB 3.0 spec calls the same type
of reset "warm reset" in some places and "BH reset" in other places. "BH"
reset is supposed to stand for "Big Hammer" reset, but it also stands for
"Brad Hosler". Brad died shortly after the USB 3.0 bus specification was
started, and they decided to name the reset after him. The suggestion was
made shortly before the spec was finalized, so the wording is a bit
inconsistent.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
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>
We would like to allow host controller drivers to stop using hcd->state.
Unfortunately, some host controller drivers use hcd->state as an
implicit way of telling the core that a controller has died. The
roothub registration functions must assume the host died if hcd->state
equals HC_STATE_HALT.
To facilitate drivers that don't want to set hcd->state to
HC_STATE_RUNNING in their initialization routines, we set the state to
running before calling the host controller's start function.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The irq enabling code is going to be refactored into a new function, so
clean up some checkpatch errors before moving it.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The PM core reacts badly when the return code from usb_runtime_suspend()
is not 0, -EAGAIN, or -EBUSY. The PM core regards this as a fatal error,
and refuses to run anymore PM helper functions. In particular,
usbfs_open() and other usbfs functions will fail because the PM core will
return an error code when usb_autoresume_device() is called. This causes
libusb and/or lsusb to either hang or segfault.
If a USB device cannot suspend for some reason (e.g. a hub doesn't report
it has remote wakeup capabilities), we still want lsusb and other
userspace programs to work. So return -EBUSY, which will fill people's
log files with failed tries, but will ensure userspace still works.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
On a laptop I see these errors on (most) resumes:
hub 3-0:1.0: over-current change on port 1
hub 3-0:1.0: over-current change on port 2
Since over-current conditions can disappear quite quickly it's better to
downgrade that message to debug level, recheck for an over-current
condition a little later and only print and over-current condition error
if that condition (still) exists when it's rechecked.
Add similar logic to hub over-current changes. (That code is untested,
as those changes do not occur on this laptop.)
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The hcd->state variable is a disaster. It's not clearly owned by
either usbcore or the host controller drivers, and they both change it
from time to time, potentially stepping on each other's toes. It's
not protected by any locks. And there's no mechanism to prevent it
from going through an invalid transition.
This patch (as1451) takes a first step toward fixing these problems.
As it turns out, usbcore uses hcd->state for essentially only two
things: checking whether the controller's root hub is running and
checking whether the controller has died. Therefore the patch adds
two new atomic bitflags to the hcd structure, to store these pieces of
information. The new flags are used only by usbcore, and a private
spinlock prevents invalid combinations (a dead controller's root hub
cannot be running).
The patch does not change the places where usbcore sets hcd->state,
since HCDs may depend on them. Furthermore, there is one place in
usb_hcd_irq() where usbcore still must use hcd->state: An HCD's
interrupt handler can implicitly indicate that the controller died by
setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a
big improvement over the current code.
The patch makes one other change. The hcd_bus_suspend() and
hcd_bus_resume() routines now check first whether the host controller
has died; if it has then they return immediately without calling the
HCD's bus_suspend or bus_resume methods.
This fixes the major problem reported in Bugzilla #29902: The system
fails to suspend after a host controller dies during system resume.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Alex Terekhov <a.terekhov@gmail.com>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Patch below removes one to many "n's" in a word..
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: linux-usb@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The USB stack historically has conflated device numbers (i.e., the
value of udev->devnum) with device addresses. This is understandable,
because until recently the two values were always the same.
But with USB-3.0 they aren't the same, so we should start calling
these things by their correct names. This patch (as1449b) changes many
of the references to "address" in the hub driver to "device number"
or "devnum".
The patch also removes some unnecessary or misleading comments.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Luben Tuikov <ltuikov@yahoo.com>
Reviewed-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If the device isn't reset, the XHCI HCD sends
SET ADDRESS to address 0 while the device is
already in Addressed state, and the request is
dropped on the floor as it is addressed to the
default address. This sequence of events, which this
patch fixes looks like this:
usb_reset_and_verify_device()
hub_port_init()
hub_set_address()
SET_ADDRESS to 0 with 1
usb_get_device_descriptor(udev, 8)
usb_get_device_descriptor(udev, 18)
descriptors_changed() --> goto re_enumerate:
hub_port_logical_disconnect()
kick_khubd()
And then:
hub_events()
hub_port_connect_change()
usb_disconnect()
usb_disable_device()
new device struct
sets device state to Powered
choose_address()
hub_port_init() <-- no reset, but SET ADDRESS to 0 with 1, timeout!
The solution is to always reset the device in
hub_port_init() to put it in a known state.
Note from Sarah Sharp:
This patch should be queued for stable trees all the way back to 2.6.34,
since that was the first kernel that supported configured device reset.
The code this patch touches has been there since 2.6.32, but the bug
would never be hit before 2.6.34 because the xHCI driver would
completely reject an attempt to reset a configured device under xHCI.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
This reverts commit 637d11bfb8. Sarah
wants to tweak it some more before it's applied to the tree.
Cc: Luben Tuikov <ltuikov@yahoo.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If the device isn't reset, the XHCI HCD sends
SET ADDRESS to address 0 while the device is
already in Addressed state, and the request is
dropped on the floor as it is addressed to the
default address. This sequence of events, which this
patch fixes looks like this:
usb_reset_and_verify_device()
hub_port_init()
hub_set_address()
SET_ADDRESS to 0 with 1
usb_get_device_descriptor(udev, 8)
usb_get_device_descriptor(udev, 18)
descriptors_changed() --> goto re_enumerate:
hub_port_logical_disconnect()
kick_khubd()
And then:
hub_events()
hub_port_connect_change()
usb_disconnect()
usb_disable_device()
new device struct
sets device state to Powered
choose_address()
hub_port_init() <-- no reset, but SET ADDRESS to 0 with 1, timeout!
The solution is to always reset the device in
hub_port_init() to put it in a known state.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
My Galaxy Spica needs this quirk when in modem mode, otherwise
it causes endless USB bus resets and is unusable in this mode.
Unfortunately Samsung decided to reuse ID of its old CDMA phone SGH-I500
for the modem part.
That's why in addition to this patch the visor driver must be prevented
from binding to SPH-I500 ID, so ACM driver can do that.
Signed-off-by: Maciej Szmigiero <mhej@o2.pl>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1448) adds a quirks entry for the Keytouch QWERTY Panel
firmware, used in the IEC 60945 keyboard. This device crashes during
enumeration when the computer asks for its configuration string
descriptor.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: kholis <nur.kholis.majid@gmail.com>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is needed to resolve some merge conflicts that were found
in the USB host controller patches, and reported by Stephen Rothwell.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Provide optional hooks for the host controller driver to override the
default DMA mapping and unmapping routines. In general, these shouldn't
be necessary unless the host controller has special DMA requirements,
such as alignment contraints. If these are not specified, the
general usb_hcd_(un)?map_urb_for_dma functions will be used instead.
Also, pass the status to unmap_urb_for_dma so it can know whether the
DMA buffer has been overwritten.
Finally, add a flag to be used by these implementations if they
allocated a temporary buffer so it can be freed properly when unmapping.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The convention is to prefix symbols exported from the USB HCD core with
"usb_hcd". This change makes unmap_urb_setup_for_dma() and
unmap_urb_for_dma() consistent with that.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The USB core keeps track of pending resume requests for root hubs, in
order to resolve races between wakeup requests and suspends. However
the code that does this is subject to another race (between wakeup
requests and resumes) because the WAKEUP_PENDING flag is cleared
before the resume occurs, leaving a window in which another wakeup
request might arrive.
This patch (as1447) fixes the problem by clearing the WAKEUP_PENDING
flag after the resume instead of before it.
This fixes Bugzilla #24952.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Paul Bender <pebender@san.rr.com>
Tested-by: warpme <warpme@o2.pl>
Cc: stable <stable@kernel.org> [.36+]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If anyone comes across a high-speed hub that (by mistake or by design)
claims to have no Transaction Translators, plugging a full- or
low-speed device into it will cause the USB stack to crash. This
patch (as1446) prevents the problem by ignoring such devices, since
the kernel has no way to communicate with them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Perry Neben <neben@vmware.com>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-usb-linus' of master.kernel.org:/pub/scm/linux/kernel/git/sarah/xhci:
xhci: Remove more doorbell-related reads
xHCI: fix printk_ratelimit() usage
xHCI: replace dev_dbg() with xhci_dbg()
xHCI: fix cycle bit set in giveback_first_trb()
xHCI: remove redundant parameter in giveback_first_trb()
xHCI: fix queue_trb in isoc transfer
xhci: Use GFP_NOIO during device reset.
usb: Realloc xHCI structures after a hub is verified.
xhci: Do not run xhci_cleanup_msix with irq disabled
xHCI: synchronize irq in xhci_suspend()
xhci: Resume bus on any port status change.
This converts error codes specific to USB to generic error codes
that can be returned to user space. Tests showed that it is so small
that it is better inlined.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The dev->power.async_suspend can only be set at the condition of
dev->power.status is DPM_ON. The dev->power.status will be initialized
as DPM_ON at device_initialize.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
is used to configure any non-standard kernel with a much larger scope than
only small devices.
This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
references to the option throughout the kernel. A new CONFIG_EMBEDDED
option is added that automatically selects CONFIG_EXPERT when enabled and
can be used in the future to isolate options that should only be
considered for embedded systems (RISC architectures, SLOB, etc).
Calling the option "EXPERT" more accurately represents its intention: only
expert users who understand the impact of the configuration changes they
are making should enable it.
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Acked-by: David Woodhouse <david.woodhouse@intel.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Greg KH <gregkh@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Robin Holt <holt@sgi.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When there's an xHCI host power loss after a suspend from memory, the USB
core attempts to reset and verify the USB devices that are attached to the
system. The xHCI driver has to reallocate those devices, since the
hardware lost all knowledge of them during the power loss.
When a hub is plugged in, and the host loses power, the xHCI hardware
structures are not updated to say the device is a hub. This is usually
done in hub_configure() when the USB hub is detected. That function is
skipped during a reset and verify by the USB core, since the core restores
the old configuration and alternate settings, and the hub driver has no
idea this happened. This bug makes the xHCI host controller reject the
enumeration of low speed devices under the resumed hub.
Therefore, make the USB core re-setup the internal xHCI hub device
information by calling update_hub_device() when hub_activate() is called
for a hub reset resume. After a host power loss, all devices under the
roothub get a reset-resume or a disconnect.
This patch should be queued for the 2.6.37 stable tree.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Synchronize the interrupts instead of free them in xhci_suspend(). This will
prevent a double free when the host is suspended and then the card removed.
Set the flag hcd->msix_enabled when using MSI-X, and check the flag in
suspend_common(). MSI-X synchronization will be handled by xhci_suspend(),
and MSI/INTx will be synchronized in suspend_common().
This patch should be queued for the 2.6.37 stable tree.
Reported-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
