Here's the big USB merge for the 3.4-rc1 merge window.
Lots of gadget driver reworks here, driver updates, xhci changes, some
new drivers added, usb-serial core reworking to fix some bugs, and other
various minor things.
There are some patches touching arch code, but they have all been acked
by the various arch maintainers.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk9njL8ACgkQMUfUDdst+ylQ9wCfbBOnIT01lGOorkaE9pom0hhk
HfMAoKq1xzCR2B+OS3UMyUQffk+Ri9Ri
=KIQ2
-----END PGP SIGNATURE-----
Merge tag 'usb-3.3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB merge for 3.4-rc1 from Greg KH:
"Here's the big USB merge for the 3.4-rc1 merge window.
Lots of gadget driver reworks here, driver updates, xhci changes, some
new drivers added, usb-serial core reworking to fix some bugs, and
other various minor things.
There are some patches touching arch code, but they have all been
acked by the various arch maintainers."
* tag 'usb-3.3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (302 commits)
net: qmi_wwan: add support for ZTE MF820D
USB: option: add ZTE MF820D
usb: gadget: f_fs: Remove lock is held before freeing checks
USB: option: make interface blacklist work again
usb/ub: deprecate & schedule for removal the "Low Performance USB Block" driver
USB: ohci-pxa27x: add clk_prepare/clk_unprepare calls
USB: use generic platform driver on ath79
USB: EHCI: Add a generic platform device driver
USB: OHCI: Add a generic platform device driver
USB: ftdi_sio: new PID: LUMEL PD12
USB: ftdi_sio: add support for FT-X series devices
USB: serial: mos7840: Fixed MCS7820 device attach problem
usb: Don't make USB_ARCH_HAS_{XHCI,OHCI,EHCI} depend on USB_SUPPORT.
usb gadget: fix a section mismatch when compiling g_ffs with CONFIG_USB_FUNCTIONFS_ETH
USB: ohci-nxp: Remove i2c_write(), use smbus
USB: ohci-nxp: Support for LPC32xx
USB: ohci-nxp: Rename symbols from pnx4008 to nxp
USB: OHCI-HCD: Rename ohci-pnx4008 to ohci-nxp
usb: gadget: Kconfig: fix typo for 'different'
usb: dwc3: pci: fix another failure path in dwc3_pci_probe()
...
Non-hub device has no child, and even a real USB hub has ports far
less than USB_MAXCHILDREN, so there is no need using a fix array for
child devices, just allocate it dynamically according real port
number.
Signed-off-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The kernel doc entry for usb_unlink_urb() contains the phrase "This
request is always asynchronous.". The "always" leads to the assumption
that the ->complete() callback is not called from within
usb_unlink_urb(). This is not true. The HCD is allowed to call the
->complete() from within ->urb_dequeue() if it is appropriate for the
hardware.
This patch updates the kernel doc so usb-device driver authors make sure
to drop all locks (and make sure it is okay to drop them) which are
acquired by the complete callback before calling usb_unlink_urb().
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There's really no point in having hcd->irq as a
signed integer when we consider the fact that
IRQ 0 means NO_IRQ. In order to avoid confusion,
make hcd->irq unsigned and fix users who were
passing -1 as the IRQ number to usb_add_hcd.
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shows up on ia64 builds (and possibly elsewhere) for configs that
don't set PM_RUNTIME or PM_SLEEP as follows:
drivers/usb/core/hcd-pci.c:383:12: warning: 'suspend_common' defined but not used
drivers/usb/core/hcd-pci.c:438:12: warning: 'resume_common' defined but not used
As per above, the functions are only used if RUNTIME/SLEEP are set,
so make the two functions conditional on these Kconfig values.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is to pull in the xhci changes and the other fixes and device id
updates that were done in Linus's tree.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The superspeed device attached to a USB 3.0 hub(such as VIA's)
doesn't respond the address device command after resume. The
root cause is the superspeed hub will miss the Hub Depth value
that is used as an offset into the route string to locate the
bits it uses to determine the downstream port number after
reset, and all packets can't be routed to the device attached
to the superspeed hub.
Hub driver sends a Set Hub Depth request to the superspeed hub
except for USB 3.0 root hub when the hub is initialized and
doesn't send the request again after reset due to the resume
process. So moving the code that sends the Set Hub Depth request
to the superspeed hub from hub_configure() to hub_activate()
is to cover those situations include initialization and reset.
The patch should be backported to kernels as old as 2.6.39.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
Now that USB 3.0 hub remote wakeup on port status changes is enabled,
and USB 3.0 device remote wakeup is handled in the USB core properly,
let's turn on auto-suspend for all USB 3.0 hubs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch takes care of the race condition between the Function Wake
Device Notification and the auto-suspend timeout for this situation:
Roothub
| (U3)
hub A
| (U3)
hub B
| (U3)
device C
When device C signals a resume, the xHCI driver will set the wakeup_bits
for the roothub port that hub A is attached to. However, since USB 3.0
hubs do not set a link state change bit on device-initiated resume, hub
A will not indicate a port event when polled. Without this patch, khubd
will notice the wakeup-bits are set for the roothub port, it will resume
hub A, and then it will poll the events bits for hub A and notice that
nothing has changed. Then it will be suspended after 2 seconds.
Change hub_activate() to look at the port link state for each USB 3.0
hub port, and set hub->change_bits if the link state is U0, indicating
the device has finished resume. Change the resume function called by
hub_events(), hub_handle_remote_wakeup(), to check the link status
for resume instead of just the port's wakeup_bits.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Refactor the code to check for a remote wakeup on a port into its own
function. Keep the behavior the same, and set connect_change in
hub_events if the device disconnected on resume. Cleanup references to
hdev->children[i-1] to use a common variable.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
USB 3.0 hubs have a different remote wakeup policy than USB 2.0 hubs.
USB 2.0 hubs, once they have remote wakeup enabled, will always send
remote wakes when anything changes on a port.
However, USB 3.0 hubs have a per-port remote wake up policy that is off
by default. The Set Feature remote wake mask can be changed for any
port, enabling remote wakeup for a connect, disconnect, or overcurrent
event, much like EHCI and xHCI host controller "wake on" port status
bits. The bits are cleared to zero on the initial hub power on, or
after the hub has been reset.
Without this patch, when a USB 3.0 hub gets suspended, it will not send
a remote wakeup on device connect or disconnect. This would show up to
the user as "dead ports" unless they ran lsusb -v (since newer versions
of lsusb use the sysfs files, rather than sending control transfers).
Change the hub driver's suspend method to enable remote wake up for
disconnect, connect, and overcurrent for all ports on the hub. Modify
the xHCI driver's roothub code to handle that request, and set the "wake
on" bits in the port status registers accordingly.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The USB 3.0 bus specification introduces a new type of power management
called function suspend. The idea is to be able to suspend different
functions (i.e. a scanner or an SD card reader on a USB printer)
independently. A device can be in U0, but have one or more functions
suspended. Thus, signaling a function resume with the standard device
remote wake signaling was not possible.
Instead, a device will (without prompt from the host) send a "device
notification" for the function remote wake. A new Set Feature Function
Remote Wake was developed to turn remote wake up on and off for each
function.
USB 3.0 devices can still go into device suspend (U3), and signal a
remote wakeup to bring the link back into U1. However, they now use the
function remote wake device notification to allow the host to know which
function woke the device from U3.
The spec is a bit ambiguous about whether a function is allowed to
signal a remote wakeup if the function has been enabled for remote
wakeup, but not placed in function suspend before the device is placed
into U3.
Section 9.2.5.1 says "Suspending a device with more than one function
effectively suspends all the functions within the device." I interpret
that to mean that putting a device in U3 suspends all functions, and
thus if the host has previously enabled remote wake for those functions,
it should be able to signal a remote wake up on port status changes.
However, hub vendors may have a different interpretation, and it can't
hurt to put the function into suspend before putting the device into U3.
I cannot get an answer out of the USB 3.0 spec architects about this
ambiguity, so I'm erring on the safe side and always suspending the
first function before placing the device in U3. Note, this code should
be fixed if we ever find any USB 3.0 devices that have more than one
function.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
When the USB 3.0 hub support went in, I disabled selective suspend for
all external USB 3.0 hubs because they used a different mechanism to
enable remote wakeup. In fact, other USB 3.0 devices that could signal
remote wakeup would have been prevented from going into suspend because
they would have stalled the SetFeature Device Remote Wakeup request.
This patch adds support for the USB 3.0 way of enabling remote wake up
(with a SetFeature Function Suspend request), and enables selective
suspend for all hubs during hub_probe. It assumes that all USB 3.0 have
only one "function" as defined by the interface association descriptor,
which is true of all the USB 3.0 devices I've seen so far. FIXME if
that turns out to change later.
After a device signals a remote wakeup, it is supposed to send a Device
Notification packet to the host controller, signaling which function
sent the remote wakeup. The host can then put any other functions back
into function suspend. Since we don't have support for function suspend
(and no devices currently support it), we'll just assume the hub
function will resume the device properly when it received the port
status change notification, and simply ignore any device notification
events from the xHCI host controller.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Intel has a PCI USB xhci host controller on a new platform. It doesn't
have a line IRQ definition in BIOS. The Linux driver refuses to
initialize this controller, but Windows works well because it only depends
on MSI.
Actually, Linux also can work for MSI. This patch avoids the line IRQ
checking for USB3 HCDs in usb core PCI probe. It allows the xHCI driver
to try to enable MSI or MSI-X first. It will fail the probe if MSI
enabling failed and there's no legacy PCI IRQ.
This patch should be backported to kernels as old as 2.6.32.
Signed-off-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
Hubs have a flag to indicate whether a given port carries removable devices
or not. This is not strictly accurate in that some built-in devices
will be flagged as removable, but followup patches will make use of platform
data to make this more reliable.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Userspace may want to make policy decisions based on whether or not a
given USB device is removable. Add a per-device member and support
for exposing it in sysfs. Information sources to populate it will be
added later.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
People have complained that debugging code shouldn't alter the flow of
control; it should restrict itself to printing out warnings and error
messages. Bowing to popular opinion, this patch (as1518) changes the
debugging checks in usb_submit_urb() to follow this guideline.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Keith Packard <keithp@keithp.com>
CC: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1514) cleans up some places where new_id and remove_id
sysfs attributes are created and deleted. Handling both attributes in
a single routine rather than a pair of routines makes the code
smaller. It also prevents certain kinds of errors, like one we
currently have in the USB subsystem: The removeid attribute is often
created even when newid isn't (because the driver's no_dynamid_id flag
is set).
In the case of the PCMCIA subsystem, the newid attribute is created
but never explicitly deleted. The patch adds a deletion routine.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
As part of the removal of get_driver()/put_driver(), this patch
(as1511) changes all the places that add dynamic IDs for drivers.
Since these additions are done by writing to the drivers' sysfs
attribute files, and the attributes are removed when the drivers are
unregistered, there is no reason to take an extra reference to the
drivers.
The one exception is the pci-stub driver, which calls pci_add_dynid()
as part of its registration. But again, there's no reason to take an
extra reference here, because the driver can't be unloaded while it is
being registered.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: Jiri Kosina <jkosina@suse.cz>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This eliminates the last instance of a function's behavior
controlled by a parameter as Linus hates such things.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Do the cleanup to avoid behaviorial parameters Linus
requested.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.
It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
both callers of device_get_devnode() are only interested in lower 16bits
and nobody tries to return anything wider than 16bit anyway.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
If a driver does not support the suspend/resume callbacks
it will be forcibly disconnected. There is no reason to check
for support of the callbacks after that.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Guillemot Webcam Hercules Dualpix Exchange camera
has been reported with a second ID.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch is in succession of previous patch
commit c842114792
xHCI: Adding #define values used for hub descriptor
Hub descriptors characteristics #defines values are added in
hub_configure() in place of magic numbers as asked by Alan Stern.
And the indentation for switch and case is changed to be same.
Some #defines values are added in ch11.h for defining hub class
protocols and used in hub.c and hcd.c in which magic values were
used for hub class protocols.
Signed-off-by: Aman Deep <amandeep3986@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add a new field num_mapped_sgs to struct urb so that we have a place to
store the number of mapped entries and can also retain the original
value of entries in num_sgs. Previously, usb_hcd_map_urb_for_dma()
would overwrite this with the number of mapped entries, which would
break dma_unmap_sg() because it requires the original number of entries.
This fixes warnings like the following when using USB storage devices:
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695()
ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1]
Modules linked in: ohci_hcd ehci_hcd
Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319
Call Trace:
<IRQ> [<ffffffff81036d3b>] warn_slowpath_common+0x80/0x98
[<ffffffff81036de7>] warn_slowpath_fmt+0x41/0x43
[<ffffffff811fa5ae>] check_unmap+0x4e4/0x695
[<ffffffff8105e92c>] ? trace_hardirqs_off+0xd/0xf
[<ffffffff8147208b>] ? _raw_spin_unlock_irqrestore+0x33/0x50
[<ffffffff811fa84a>] debug_dma_unmap_sg+0xeb/0x117
[<ffffffff8137b02f>] usb_hcd_unmap_urb_for_dma+0x71/0x188
[<ffffffff8137b166>] unmap_urb_for_dma+0x20/0x22
[<ffffffff8137b1c5>] usb_hcd_giveback_urb+0x5d/0xc0
[<ffffffffa0000d02>] ehci_urb_done+0xf7/0x10c [ehci_hcd]
[<ffffffffa0001140>] qh_completions+0x429/0x4bd [ehci_hcd]
[<ffffffffa000340a>] ehci_work+0x95/0x9c0 [ehci_hcd]
...
---[ end trace f29ac88a5a48c580 ]---
Mapped at:
[<ffffffff811faac4>] debug_dma_map_sg+0x45/0x139
[<ffffffff8137bc0b>] usb_hcd_map_urb_for_dma+0x22e/0x478
[<ffffffff8137c494>] usb_hcd_submit_urb+0x63f/0x6fa
[<ffffffff8137d01c>] usb_submit_urb+0x2c7/0x2de
[<ffffffff8137dcd4>] usb_sg_wait+0x55/0x161
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This pulls in the latest USB bugfixes and helps a few of the drivers
merge nicer in the future due to changes in both branches.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The 16-MB global limit on memory used by usbfs isn't suitable for all
people. It's a reasonable default, but there are applications
(especially for SuperSpeed devices) that need a lot more.
This patch (as1498) creates a writable module parameter for usbcore to
control the global limit. The default is still 16 MB, but users can
change it at runtime, even after usbcore has been loaded. As a
special case, setting the value to 0 is treated the same as the hard
limit of 2047 MB.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
For a long time people have complained about the limitations imposed
by usbfs. URBs coming from userspace are not allowed to have transfer
buffers larger than a more-or-less arbitrary maximum.
While it is generally a good idea to avoid large transfer buffers
(because the data has to be bounced to/from a contiguous kernel-space
buffer), it's not the kernel's job to enforce such limits. Programs
should be allowed to submit URBs as large as they like; if there isn't
sufficient contiguous memory available then the submission will fail
with a simple ENOMEM error.
On the other hand, we would like to prevent programs from submitting a
lot of small URBs and using up all the DMA-able kernel memory. To
that end, this patch (as1497) replaces the old limits on individual
transfer buffers with a single global limit on the total amount of
memory in use by usbfs. The global limit is set to 16 MB as a nice
compromise value: not too big, but large enough to hold about 300 ms
of data for high-speed transfers.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1496) unifies the error-return pathways of several
functions in the usbfs driver. This is not a very important change by
itself; it merely prepares the way for the next patch in this series.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Move usb_translate_errors from usb core to linux/usb.h as it is meant to
be accessed from drivers.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
When adding the ID of a composite device dynamically to a driver, all
hitherto unbound interfaces are bound to this driver regardless of their
class, which may not be intended.
The patch adds the option to tell the targeted interface class to a driver
via the "new_id" attribute, in addition to the device ID.
Also, it appends the ABI documentation accordingly.
Example:
$ echo "1234 2a2a ff" >/sys/bus/usb-serial/drivers/option1/new_id
will bind only vendor-specific interfaces to the 3G driver.
Signed-off-by: Josua Dietze <digidietze@draisberghof.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The HCD_FLAG_SAW_IRQ flag was introduced in order to catch IRQ routing
errors: If an URB was unlinked and the host controller hadn't gotten
any IRQs, it seemed likely that the IRQs were directed to the wrong
vector.
This warning hasn't come up in many years, as far as I know; interrupt
routing now seems to be well under control. Therefore there's no
reason to keep the flag around any more. This patch (as1495) finally
removes it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The following patch contains additional affected webcam models, on top of the
patches commited to linux-next 2394d67e44
and 5b253d88cc
Signed-off-by: sordna <sordna@gmail.com>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6:
spi / PM: Support dev_pm_ops
PM: Prototype the pm_generic_ operations
PM / Runtime: Generic resume shouldn't set RPM_ACTIVE unconditionally
PM: Use dev_name() in core device suspend and resume routines
PM: Permit registration of parentless devices during system suspend
PM: Replace the device power.status field with a bit field
PM: Remove redundant checks from core device resume routines
PM: Use a different list of devices for each stage of device suspend
PM: Avoid compiler warning in pm_noirq_op()
PM: Use pm_wakeup_pending() in __device_suspend()
PM / Wakeup: Replace pm_check_wakeup_events() with pm_wakeup_pending()
PM: Prevent dpm_prepare() from returning errors unnecessarily
PM: Fix references to basic-pm-debugging.txt in drivers-testing.txt
PM / Runtime: Add synchronous runtime interface for interrupt handlers (v3)
PM / Hibernate: When failed, in_suspend should be reset
PM / Hibernate: hibernation_ops->leave should be checked too
Freezer: Fix a race during freezing of TASK_STOPPED tasks
PM: Use proper ccflag flag in kernel/power/Makefile
PM / Runtime: Fix comments to match runtime callback code
* 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (144 commits)
USB: add support for Dream Cheeky DL100B Webmail Notifier (1d34:0004)
USB: serial: ftdi_sio: add support for TIOCSERGETLSR
USB: ehci-mxc: Setup portsc register prior to accessing OTG viewport
USB: atmel_usba_udc: fix freeing irq in usba_udc_remove()
usb: ehci-omap: fix tll channel enable mask
usb: ohci-omap3: fix trivial typo
USB: gadget: ci13xxx: don't assume that PAGE_SIZE is 4096
USB: gadget: ci13xxx: fix complete() callback for no_interrupt rq's
USB: gadget: update ci13xxx to work with g_ether
USB: gadgets: ci13xxx: fix probing of compiled-in gadget drivers
Revert "USB: musb: pm: don't rely fully on clock support"
Revert "USB: musb: blackfin: pm: make it work"
USB: uas: Use GFP_NOIO instead of GFP_KERNEL in I/O submission path
USB: uas: Ensure we only bind to a UAS interface
USB: uas: Rename sense pipe and sense urb to status pipe and status urb
USB: uas: Use kzalloc instead of kmalloc
USB: uas: Fix up the Sense IU
usb: musb: core: kill unneeded #include's
DA8xx: assign name to MUSB IRQ resource
usb: gadget: g_ncm added
...
Manually fix up trivial conflicts in USB Kconfig changes in:
arch/arm/mach-omap2/Kconfig
arch/sh/Kconfig
drivers/usb/Kconfig
drivers/usb/host/ehci-hcd.c
and annoying chip clock data conflicts in:
arch/arm/mach-omap2/clock3xxx_data.c
arch/arm/mach-omap2/clock44xx_data.c
Protect d_subdirs and d_child with d_lock, except in filesystems that aren't
using dcache_lock for these anyway (eg. using i_mutex).
Note: if we change the locking rule in future so that ->d_child protection is
provided only with ->d_parent->d_lock, it may allow us to reduce some locking.
But it would be an exception to an otherwise regular locking scheme, so we'd
have to see some good results. Probably not worthwhile.
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Protect d_unhashed(dentry) condition with d_lock. This means keeping
DCACHE_UNHASHED bit in synch with hash manipulations.
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Linus Torvalds