After commit b2b49ccbdd (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so quite a few
depend on CONFIG_PM (or even dropped in some cases).
Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code
and documentation.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With this patch, USB activity can be signaled by blinking a LED. There
are two triggers, one for activity on USB host and one for USB gadget.
Both triggers should work with all host/device controllers. Tested only
with musb.
Performace: I measured performance overheads on ARM Cortex-A8 (TI
AM335x) running on 600 MHz.
Duration of usb_led_activity():
- with no LED attached to the trigger: 2 ± 1 µs
- with one GPIO LED attached to the trigger: 2 ± 1 µs or 8 ± 2 µs (two peaks in histogram)
Duration of functions calling usb_led_activity() (with this patch
applied and no LED attached to the trigger):
- __usb_hcd_giveback_urb(): 10 - 25 µs
- usb_gadget_giveback_request(): 2 - 6 µs
Signed-off-by: Michal Sojka <sojka@merica.cz>
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch creates a separate instance of the usb_address0 mutex for each USB
bus, and attaches it to the usb_bus device struct. This allows devices on
separate buses to be enumerated in parallel; saving time.
In the current code, there is a single, global instance of the usb_address0
mutex which is used for all devices on all buses. This isn't completely
necessary, as this mutex is only needed to prevent address0 collisions for
devices on the *same* bus (usb 2.0 spec, sec 4.6.1). This superfluous coverage
can cause additional delay in system resume on systems with multiple hosts
(up to several seconds depending on what devices are attached).
Signed-off-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here's the big USB pull request for 3.15-rc1.
The normal set of patches, lots of controller driver updates, and a
smattering of individual USB driver updates as well.
All have been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlM7AbcACgkQMUfUDdst+ymbZACgncdbZyPsVZ7ZUpBFNbO/vBVT
T9UAmwciojEzjh7b+x4ylsWH+O3LWVN3
=RpAF
-----END PGP SIGNATURE-----
Merge tag 'usb-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB patches from Greg KH:
"Here's the big USB pull request for 3.15-rc1.
The normal set of patches, lots of controller driver updates, and a
smattering of individual USB driver updates as well.
All have been in linux-next for a while"
* tag 'usb-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (249 commits)
xhci: Transition maintainership to Mathias Nyman.
USB: disable reset-resume when USB_QUIRK_RESET is set
USB: unbind all interfaces before rebinding any
usb: phy: Add ulpi IDs for SMSC USB3320 and TI TUSB1210
usb: gadget: tcm_usb_gadget: stop format strings
usb: gadget: f_fs: add missing spinlock and mutex unlock
usb: gadget: composite: switch over to ERR_CAST()
usb: gadget: inode: switch over to memdup_user()
usb: gadget: f_subset: switch over to PTR_RET
usb: gadget: lpc32xx_udc: fix wrong clk_put() sequence
USB: keyspan: remove dead debugging code
USB: serial: add missing newlines to dev_<level> messages.
USB: serial: add missing braces
USB: serial: continue to write on errors
USB: serial: continue to read on errors
USB: serial: make bulk_out_size a lower limit
USB: cypress_m8: fix potential scheduling while atomic
devicetree: bindings: document lsi,zevio-usb
usb: chipidea: add support for USB OTG controller on LSI Zevio SoCs
usb: chipidea: imx: Use dev_name() for ci_hdrc name to distinguish USBs
...
Since it is needed outside usbcore and exposed in include/linux/usb.h,
it conflicts with enum dev_state in rt2x00 wireless driver.
Mark it as usb specific to avoid conflicts in the future.
Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A device should not be able to be used concurrently both by
the server and the client. Claiming the port used by the
shared device ensures no interface drivers bind to it and
that it is not usable from the server.
Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is a preparation patch for adding support for bulk streams to usbfs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
So that it can be used in other places too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This reverts commit 35773dac5f. It's a
hack that caused regressions in the usb-storage and userspace USB
drivers that use usbfs and libusb. Commit 70cabb7d992f "xhci 1.0: Limit
arbitrarily-aligned scatter gather." should fix the issues seen with the
ax88179_178a driver on xHCI 1.0 hosts, without causing regressions.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org # 3.12
This driver was previously an interface driver. Since USB/IP
exports a whole device, not just an interface, it would make
sense to be a device driver.
This patch also modifies the way userspace sees and uses a
shared device:
* the usbip_status file is no longer created for interface 0, but for
the whole device (such as
/sys/devices/pci0000:00/0000:00:01.2/usb1/1-1/usbip_status).
* per interface information, such as interface class or protocol, is
no longer sent/received; only device specific information is
transmitted.
* since the driver was moved one level below in the USB architecture,
there is no need to bind/unbind each interface, just the device as a
whole.
Signed-off-by: Valentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Often, usb drivers need some driver_info to get a device to work. To
have access to driver_info when using new_id, allow to pass a reference
vendor:product tuple from which new_id will inherit driver_info.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
can only occur at a boundary between underlying USB frames (512 bytes for
high speed devices).
If this isn't done the USB frames aren't formatted correctly and, for example,
the USB3 ethernet ax88179_178a card will stop sending (while still receiving)
when running a netperf tcp transmit test with (say) and 8k buffer.
This should be a candidate for stable, the ax88179_178a driver defaults to
gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
Notes from Sarah:
Discussion: http://marc.info/?l=linux-usb&m=138384509604981&w=2
This patch fixes a long-standing xHCI driver bug that was revealed by a
change in 3.12 in the usb-net driver. Commit
638c5115a7 "USBNET: support DMA SG" added
support to use bulk endpoint scatter-gather (urb->sg). Only the USB
ethernet drivers trigger this bug, because the mass storage driver sends
sg list entries in page-sized chunks.
This patch only fixes the issue for bulk endpoint scatter-gather. The
problem will still occur for periodic endpoints, because hosts will
interpret no-op transfers as a request to skip a service interval, which
is not what we want.
Luckily, the USB core isn't set up for scatter-gather on isochronous
endpoints, and no USB drivers use scatter-gather for interrupt
endpoints. Document this known limitation so that developers won't try
to use urb->sg for interrupt endpoints until this issue is fixed. The
more comprehensive fix would be to allow link TRBs in the middle of the
endpoint ring and revert this patch, but that fix would touch too much
code to be allowed in for stable.
This patch should be backported to kernels as old as 3.12, that contain
the commit 638c5115a7 "USBNET: support DMA
SG". Without this patch, the USB network device gets wedged, and stops
sending packets. Mark Lord confirms this patch fixes the regression:
http://marc.info/?l=linux-netdev&m=138487107625966&w=2
Signed-off-by: David Laight <david.laight@aculab.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Mark Lord <mlord@pobox.com>
Cc: stable@vger.kernel.org
How it's supposed to work:
--------------------------
USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices
support. USB 3.0 devices certified by the USB-IF are required to
support it if they are plugged into a USB 2.0 only port, or a USB 2.0
cable is used. USB 2.0 Link PM requires both a USB device and a host
controller that supports USB 2.0 hardware-enabled LPM.
USB 2.0 Link PM is designed to be enabled once by software, and the host
hardware handles transitions to the L1 state automatically. The premise
of USB 2.0 Link PM is to be able to put the device into a lower power
link state when the bus is idle or the device NAKs USB IN transfers for
a specified amount of time.
...but hardware is broken:
--------------------------
It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by
setting the LPM bit in their USB 2.0 BOS descriptor), but they don't
actually implement it correctly. This manifests as the USB device
refusing to respond to transfers when it is plugged into a USB 2.0 only
port under the Haswell-ULT/Lynx Point LP xHCI host.
These devices pass the xHCI driver's simple test to enable USB 2.0 Link
PM, wait for the port to enter L1, and then bring it back into L0. They
only start to break when L1 entry is interleaved with transfers.
Some devices then fail to respond to the next control transfer (usually
a Set Configuration). This results in devices never enumerating.
Other mass storage devices (such as a later model Western Digital My
Passport USB 3.0 hard drive) respond fine to going into L1 between
control transfers. They ACK the entry, come out of L1 when the host
needs to send a control transfer, and respond properly to those control
transfers. However, when the first READ10 SCSI command is sent, the
device NAKs the data phase while it's reading from the spinning disk.
Eventually, the host requests to put the link into L1, and the device
ACKs that request. Then it never responds to the data phase of the
READ10 command. This results in not being able to read from the drive.
Some mass storage devices (like the Corsair Survivor USB 3.0 flash
drive) are well behaved. They ACK the entry into L1 during control
transfers, and when SCSI commands start coming in, they NAK the requests
to go into L1, because they need to be at full power.
Not all USB 3.0 devices advertise USB 2.0 link PM support. My Point
Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't
have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM. I
suspect that means the device isn't certified.
What do we do about it?
-----------------------
There's really no good way for the kernel to test these devices.
Therefore, the kernel needs to disable USB 2.0 Link PM by default, and
distros will have to enable it by writing 1 to the sysfs file
/sys/bus/usb/devices/../power/usb2_hardware_lpm. Rip out the xHCI Link
PM test, since it's not sufficient to detect these buggy devices, and
don't automatically enable LPM after the device is addressed.
This patch should be backported to kernels as old as 3.11, that
contain the commit a558ccdcc7 "usb: xhci:
add USB2 Link power management BESL support". Without this fix, some
USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
on Haswell-ULT systems.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
usb_wait_anchor_empty_timeout() should wait till the completion handler
has run. Both the zd1211rw driver and the uas driver (in its task mgmt) depend
on the completion handler having completed when usb_wait_anchor_empty_timeout()
returns, as they read state set by the completion handler after an
usb_wait_anchor_empty_timeout() call.
But __usb_hcd_giveback_urb() calls usb_unanchor_urb before calling the
completion handler. This is necessary as the completion handler may
re-submit and re-anchor the urb. But this introduces a race where the state
these drivers want to read has not been set yet by the completion handler
(this race is easily triggered with the uas task mgmt code).
I've considered adding an anchor_count to struct urb, which would be
incremented on anchor and decremented on unanchor, and then only actually
do the anchor / unanchor on 0 -> 1 and 1 -> 0 transtions, combined with
moving the unanchor call in hcd_giveback_urb to after calling the completion
handler. But this will only work if urb's are only re-anchored to the same
anchor as they were anchored to before the completion handler ran.
And at least one driver re-anchors to another anchor from the completion
handler (rtlwifi).
So I have come up with this patch instead, which adds the ability to
suspend wakeups of usb_wait_anchor_empty_timeout() waiters to the usb_anchor
functionality, and uses this in __usb_hcd_giveback_urb() to delay wake-ups
until the completion handler has run.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
And do so in a way which ensures that any fields added in the future will
also get properly zero-ed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The hcd-driver free_streams method can return an error, so lets properly
propagate that.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some host controllers(such as xHCI) can support building
packet from discontinuous buffers, so introduce one flag
and helper for this kind of host controllers, then the
feature can help some applications(such as usbnet) by
supporting arbitrary length of sg buffers.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When building the htmldocs (in verbose mode), scripts/kernel-doc reports the
following type of warnings:
Warning(drivers/usb/core/usb.c:76): No description found for return value of
'usb_find_alt_setting'
Fix them by:
- adding some missing descriptions of return values
- using "Return" sections for those descriptions
Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bInterval must be within the range 1 - 16
when running at High/Super speed, and within
the range 1 - 255 when running at Full/Low speed.
In order to catch drivers passing a too
large bInterval on Super/High speed scenarios
(thus overflowing urb->interval), let's clamp()
the argument to the allowed ranges.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB spec stats that short packet can only appear at the end
of transfer. Because lost of HC(EHCI/UHCI/OHCI/...) can't
build a full packet from discontinuous buffers, we introduce
the limit in usb_submit_urb() to avoid such kind of bad sg buffers
coming from driver.
The limit might be a bit strict:
- platform has iommu to do sg list mapping
- some host controllers may support to build full packet from
discontinuous buffers.
But considered that most of HCs don't support that, and driver
need work well or keep consistent on different HCs and ARCHs, we
have to introduce the limit.
Currently, only usbtest is reported to pass such sg buffers to HC,
and other users(mass storage, usbfs) don't have the problem.
We don't check it on USB wireless device, because:
- wireless devices can't be attached to common USB
bus(EHCI/UHCI/OHCI/...)
- the max packet size of endpoint may be odd, and often can't
devide 4KB which is a typical usage in usb mass storage application
Reported-by: Konstantin Filatov <kfilatov@parallels.com>
Reported-by: Denis V. Lunev <den@openvz.org>
Cc: Felipe Balbi <balbi@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USB_MAXCHILDREN symbol is used in include/uapi/linux/usb/ch11.h, a
user-mode header, even though it is defined in include/linux/usb.h,
which is kernel-only. This causes compile-time errors when user
programs try to #include linux/usb/ch11.h.
This patch fixes the problem by moving the definition of USB_MAXCHILDREN
into ch11.h. It also gets rid of unneeded parentheses.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adds abitilty to tune L1 timeout (inactivity timer for usb2 link sleep)
and BESL (best effort service latency)via sysfs.
This also adds a new usb2_lpm_parameters structure with those variables to
struct usb_device.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
usb 2.0 devices with link power managment (LPM) can describe their idle link
timeouts either in BESL or HIRD format, so far xHCI has only supported HIRD but
later xHCI errata add BESL support as well
BESL timeouts need to inform exit latency changes with an evaluate
context command the same way USB 3.0 link PM code does.
The same xhci_change_max_exit_latency() function is used as with USB3
but code is pulled out from #ifdef CONFIG_PM as USB2.0 BESL LPM
funcionality does not depend on CONFIG_PM.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The current EHCI code sleeps a flat 110ms in the resume path if there
was a USB 1.1 device connected to its companion controller during
suspend, waiting for the device to reappear and reset so that it can be
handed back to the companion. This is necessary if the device uses
persist, so that the companion controller can actually see it during its
own resume path.
However, if the device doesn't use persist, this is entirely
unnecessary. We might just as well ignore it and have the normal device
detection/reset/handoff code handle it asynchronously when it eventually
shows up. As USB 1.1 devices are almost exclusively HIDs these days (for
which persist has no value), this can allow distros to shave another
tenth of a second off their resume time.
In order to enable this optimization, the patch also adds a new
usb_for_each_dev() iterator that is exported by the USB core and wraps
bus_for_each_dev() with the logic to differentiate between struct
usb_device and struct usb_interface on the usb_bus_type bus.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially
replacing it everywhere with CONFIG_PM_RUNTIME (except for one place
in hub.c, where it is replaced with CONFIG_PM because the code needs
to be used in both runtime and system PM). The net result is code
shrinkage and simplification.
There's very little point in keeping CONFIG_USB_SUSPEND because almost
everybody enables it. The few that don't will find that the usbcore
module has gotten somewhat bigger and they will have to take active
measures if they want to prevent hubs from being runtime suspended.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case and let resume/reset_resume callback
handle the suspend failure if needed.
Also kerneldoc for usb_suspend_both() is updated with the
fact.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1649) adds a mechanism for host controller drivers to
inform usbcore when they have begun or ended resume signalling on a
particular root-hub port. The core will then make sure that the root
hub does not get runtime-suspended while the port resume is going on.
Since commit 596d789a21 (USB: set hub's
default autosuspend delay as 0), the system tries to suspend hubs
whenever they aren't in use. While a root-hub port is being resumed,
the root hub does not appear to be in use. Attempted runtime suspends
fail because of the ongoing port resume, but the PM core just keeps on
trying over and over again. We want to prevent this wasteful effort.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matching on device and interface class with with unspecified
subclass and protocol is sometimes useful. This is slightly
different from USB_DEVICE_AND_INTERFACE_INFO which requires
the full interface class/subclass/protocol triplet.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1620) speeds up USB root-hub resumes in the common case
where every enabled port has its suspend feature set (which currently
will be true for every runtime resume of the root hub). If all the
enabled ports are suspended then resuming the root hub won't resume
any of the downstream devices. In this case there's no need for a
Resume Recovery delay, because that delay is meant to give devices a
chance to get ready for active use.
To keep track of the port suspend features, the patch adds a
"port_is_suspended" flag to struct usb_device. This has to be tracked
separately from the device's state; it's entirely possible for a USB-2
device to be suspended while the suspend feature on its parent port is
clear. The reason is that devices will go into suspend whenever their
parent hub does.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1619) improves the interface to the "hub_for_each_child"
macro. The name clearly suggests that the macro iterates over child
devices; it does not suggest that the loop will also iterate over
unnconnected ports.
The patch changes the macro so that it will skip over unconnected
ports and iterate only the actual child devices. The two existing
call sites are updated to avoid testing for a NULL child pointer,
which is now unnecessary.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1611) updates the USB documentation and kerneldoc to
give a more precise meaning for the URB_ISO_ASAP flag and to explain
more of the details of scheduling for isochronous URBs.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Upcoming Intel systems will have an ACPI method to control whether a USB
port can be completely powered off. The implication of powering off a
USB port is that the device and host sees a physical disconnect, and
subsequent port connections and remote wakeups will be lost.
Add a new function, usb_acpi_power_manageable(), that can be used to
find whether the usb port has ACPI power resources that can be used to
power on and off the port on these machines. Also add a new function
called usb_acpi_set_power_state() that controls the port power via these
ACPI methods.
When the USB core calls into the xHCI hub driver to power off a port,
check whether the port can be completely powered off via this new ACPI
mechanism. If so, call into these new ACPI methods. Also use the ACPI
methods when the USB core asks to power on a port.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the upcoming USB port power off patches, we need to know whether a
USB port can ever see a disconnect event. Often USB ports are internal
to a system, and users can't disconnect USB devices from that port.
Sometimes those ports will remain empty, because the OEM chose not to
connect an internal USB device to that port.
According to ACPI Spec 9.13, PLD indicates whether USB port is
user visible and _UPC indicates whether a USB device can be connected to
the USB port (we'll call this "connectible"). Here's a matrix of the
possible combinations:
Visible Connectible
Name Example
-------------------------------------------------------------------------
Yes No Unknown (Invalid state.)
Yes Yes Hot-plug USB ports on the outside of a laptop.
A user could freely connect and disconnect
USB devices.
No Yes Hard-wired A USB modem hard-wired to a port on the
inside of a laptop.
No No Not used The port is internal to the system and
will remain empty.
Represent each of these four states with an enum usb_port_connect_type.
The four states are USB_PORT_CONNECT_TYPE_UNKNOWN,
USB_PORT_CONNECT_TYPE_HOT_PLUG, USB_PORT_CONNECT_TYPE_HARD_WIRED, and
USB_PORT_NOT_USED. When we get the USB port's acpi_handle, store the
state in connect_type in struct usb_port.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_device structure contains an array of usb_device "children".
This array is only valid if the usb_device is a hub, so it makes no
sense to store it there. Instead, store the usb_device child
in its parent usb_port structure.
Since usb_port is an internal USB core structure, add a new function to
get the USB device child, usb_hub_find_child(). Add a new macro,
usb_hub_get_each_child(), to iterate over all the children attached to a
particular USB hub.
Remove the printing the USB children array pointer from the usb-ip
driver, since it's really not necessary.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A lot of Broadcom Bluetooth devices provides vendor specific interface
class and we are getting flooded by patches adding new device support.
This change will help us enable support for any other Broadcom with vendor
specific device that arrives in the future.
Only the product id changes for those devices, so this macro would be
perfect for us:
{ USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) }
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Acked-by: Henrik Rydberg <rydberg@bitmath.se>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reorder elements in the usb_host_interface structure to remove 8 bytes
of padding on 64 bit builds , and so shrink it's size to 40 bytes.
usb_interface_descriptor is a odd size which leaves a gap that is not
big enough to hold a pointer, so moving extralen into that gap removes
the need for more padding.
Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB 3.0 devices can optionally support Latency Tolerance Messaging
(LTM). Add a new sysfs file in the device directory to show whether a
device is LTM capable. This file will be present for both USB 2.0 and
USB 3.0 devices.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
USB 3.0 devices may optionally support a new feature called Latency
Tolerance Messaging. If both the xHCI host controller and the device
support LTM, it should be turned on in order to give the system hardware
a better clue about the latency tolerance values of its PCI devices.
Once a Set Feature request to enable LTM is received, the USB 3.0 device
will begin to send LTM updates as its buffers fill or empty, and it can
tolerate more or less latency.
The USB 3.0 spec, section C.4.2 says that LTM should be disabled just
before the device is placed into suspend. Then the device will send an
updated LTM notification, so that the system doesn't think it should
remain in an active state in order to satisfy the latency requirements
of the suspended device.
The Set and Clear Feature LTM enable command can only be sent to a
configured device. The device will respond with an error if that
command is sent while it is in the Default or Addressed state. Make
sure to check udev->actconfig in usb_enable_ltm() and usb_disable_ltm(),
and don't send those commands when the device is unconfigured.
LTM should be enabled once a new configuration is installed in
usb_set_configuration(). If we end up sending duplicate Set Feature LTM
Enable commands on a switch from one installed configuration to another
configuration, that should be harmless.
Make sure that LTM is disabled before the device is unconfigured in
usb_disable_device(). If no drivers are bound to the device, it doesn't
make sense to allow the device to control the latency tolerance of the
xHCI host controller.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
hub_initiated_lpm_disable_count is not used by any code, so remove it.
This commit should be backported to kernels as old as 3.5, that contain
the commit 8306095fd2 "USB: Disable USB
3.0 LPM in critical sections."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
There are a few (new) usbdevfs capabilities which an application cannot
discover in any other way then checking the kernel version. There are 3
problems with this:
1) It is just not very pretty.
2) Given the tendency of enterprise distros to backport stuff it is not
reliable.
3) As discussed in length on the mailinglist, USBDEVFS_URB_BULK_CONTINUATION
does not work as it should when combined with USBDEVFS_URB_SHORT_NOT_OK
(which is its intended use) on devices attached to an XHCI controller.
So the availability of these features can be host controller dependent,
making depending on them based on the kernel version not a good idea.
This patch besides adding the new ioctl also adds flags for the following
existing capabilities:
USBDEVFS_CAP_ZERO_PACKET, available since 2.6.31
USBDEVFS_CAP_BULK_CONTINUATION, available since 2.6.32, except for XHCI
USBDEVFS_CAP_NO_PACKET_SIZE_LIM, available since 3.3
Note that this patch only does not advertise the USBDEVFS_URB_BULK_CONTINUATION
cap for XHCI controllers, bulk transfers with this flag set will still be
accepted when submitted to XHCI controllers.
Returning -EINVAL for them would break existing apps, and in most cases the
troublesome scenario wrt USBDEVFS_URB_SHORT_NOT_OK urbs on XHCI controllers
will never get hit, so this would break working use cases.
The disadvantage of not returning -EINVAL is that cases were it is causing
real trouble may go undetected / the cause of the trouble may be unclear,
but this is the best we can do.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some composite USB devices provide multiple interfaces
with different functions, all using "vendor-specific"
for class/subclass/protocol. Another OS use interface
numbers to match the driver and interface. It seems
these devices are designed with that in mind - using
static interface numbers for the different functions.
This adds support for matching against the
bInterfaceNumber, allowing such devices to be supported
without having to resort to testing against interface
number whitelists and/or blacklists in the probe.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When CONFIG_PM=n, make sure that the usb_[unlocked_][en/dis]able_lpm
declarations are visible in include/linux/usb.h, and exported from
drivers/usb/core/hub.c.
Before this patch, if CONFIG_USB_SUSPEND was turned off, it would cause
build errors:
drivers/usb/core/hub.c: In function 'usb_disable_lpm':
drivers/usb/core/hub.c:3394:2: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/hub.c: At top level:
drivers/usb/core/hub.c:3424:6: warning: conflicting types for 'usb_enable_lpm' [enabled by default]
drivers/usb/core/hub.c:3394:2: note: previous implicit declaration of 'usb_enable_lpm' was here
drivers/usb/core/driver.c: In function 'usb_probe_interface':
drivers/usb/core/driver.c:339:2: error: implicit declaration of function 'usb_unlocked_disable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/driver.c:364:3: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c: In function 'usb_set_interface':
drivers/usb/core/message.c:1314:2: error: implicit declaration of function 'usb_disable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c:1323:3: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration]
drivers/usb/core/message.c:1368:2: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration]
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Chen Peter-B29397 <B29397@freescale.com>
There are several places where the USB core needs to disable USB 3.0
Link PM:
- usb_bind_interface
- usb_unbind_interface
- usb_driver_claim_interface
- usb_port_suspend/usb_port_resume
- usb_reset_and_verify_device
- usb_set_interface
- usb_reset_configuration
- usb_set_configuration
Use the new LPM disable/enable functions to temporarily disable LPM
around these critical sections.
We need to protect the critical section around binding and unbinding USB
interface drivers. USB drivers may want to disable hub-initiated USB
3.0 LPM, which will change the value of the U1/U2 timeouts that the xHCI
driver will install. We need to disable LPM completely until the driver
is bound to the interface, and the driver has a chance to enable
whatever alternate interface setting it needs in its probe routine.
Then re-enable USB3 LPM, and recalculate the U1/U2 timeout values.
We also need to disable LPM in usb_driver_claim_interface,
because drivers like usbfs can bind to an interface through that
function. Note, there is no way currently for userspace drivers to
disable hub-initiated USB 3.0 LPM. Revisit this later.
When a driver is unbound, the U1/U2 timeouts may change because we are
unbinding the last driver that needed hub-initiated USB 3.0 LPM to be
disabled.
USB LPM must be disabled when a USB device is going to be suspended.
The USB 3.0 spec does not define a state transition from U1 or U2 into
U3, so we need to bring the device into U0 by disabling LPM before we
can place it into U3. Therefore, call usb_unlocked_disable_lpm() in
usb_port_suspend(), and call usb_unlocked_enable_lpm() in
usb_port_resume(). If the port suspend fails, make sure to re-enable
LPM by calling usb_unlocked_enable_lpm(), since usb_port_resume() will
not be called on a failed port suspend.
USB 3.0 devices lose their USB 3.0 LPM settings (including whether USB
device-initiated LPM is enabled) across device suspend. Therefore,
disable LPM before the device will be reset in
usb_reset_and_verify_device(), and re-enable LPM after the reset is
complete and the configuration/alt settings are re-installed.
The calculated U1/U2 timeout values are heavily dependent on what USB
device endpoints are currently enabled. When any of the enabled
endpoints on the device might change, due to a new configuration, or new
alternate interface setting, we need to first disable USB 3.0 LPM, add
or delete endpoints from the xHCI schedule, install the new interfaces
and alt settings, and then re-enable LPM. Do this in usb_set_interface,
usb_reset_configuration, and usb_set_configuration.
Basically, there is a call to disable and then enable LPM in all
functions that lock the bandwidth_mutex. One exception is
usb_disable_device, because the device is disconnecting or otherwise
going away, and we should not care about whether USB 3.0 LPM is enabled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
There are various functions within the USB core that will need to
disable USB 3.0 link power states. For example, when a USB device
driver is being bound to an interface, we need to disable USB 3.0 LPM
until we know if the driver will allow hub-initiated LPM transitions.
Another example is when the USB core is switching alternate interface
settings. The USB 3.0 timeout values are dependent on what endpoints
are enabled, so we want to ensure that LPM is disabled until the new alt
setting is fully installed.
Multiple functions need to disable LPM, and those functions can even be
nested. For example, usb_bind_interface() could disable LPM, and then
call into the driver probe function, which may attempt to switch to a
different alt setting. Therefore, we need to keep a count of the number
of functions that require LPM to be disabled at any point in time.
Introduce two new USB core API calls, usb_disable_lpm() and
usb_enable_lpm(). These functions increment and decrement a new
variable in the usb_device, lpm_disable_count. If usb_disable_lpm()
fails, it will call usb_enable_lpm() in order to balance the
lpm_disable_count.
These two new functions must be called with the bandwidth_mutex locked.
If the bandwidth_mutex is not already held by the caller, it should
instead call usb_unlocked_disable_lpm() and usb_enable_lpm(), which take
the bandwidth_mutex before calling usb_disable_lpm() and
usb_enable_lpm(), respectively.
Introduce a new variable (timeout) in the usb3_lpm_params structure to
keep track of the currently enabled U1/U2 timeout values. When
usb_disable_lpm() is called, and the USB device has the U1 or U2
timeouts set to a non-zero value (meaning either device-initiated or
hub-initiated LPM is enabled), attempt to disable LPM, regardless of the
state of the lpm_disable_count. We want to ensure that all callers can
be guaranteed that LPM is disabled if usb_disable_lpm() returns zero.
Otherwise the following scenario could occur:
1. Driver A is being bound to interface 1. usb_probe_interface()
disables LPM. Driver A doesn't care if hub-initiated LPM is enabled, so
even though usb_disable_lpm() fails, the probe of the driver continues,
and the bandwidth mutex is dropped.
2. Meanwhile, Driver B is being bound to interface 2.
usb_probe_interface() grabs the bandwidth mutex and calls
usb_disable_lpm(). That call should attempt to disable LPM, even
though the lpm_disable_count is set to 1 by Driver A.
For usb_enable_lpm(), we attempt to enable LPM only when the
lpm_disable_count is zero. If some step in enabling LPM fails, it will
only have a minimal impact on power consumption, and all USB device
drivers should still work properly. Therefore don't bother to return
any error codes.
Don't enable device-initiated LPM if the device is unconfigured. The
USB device will only accept the U1/U2_ENABLE control transfers in the
configured state. Do enable hub-initiated LPM in that case, since
devices are allowed to accept the LGO_Ux link commands in any state.
Don't enable or disable LPM if the device is marked as not being LPM
capable. This can happen if:
- the USB device doesn't have a SS BOS descriptor,
- the device's parent hub has a zeroed bHeaderDecodeLatency value, or
- the xHCI host doesn't support LPM.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
USB 3.0 Link Power Management (LPM) is designed to allow individual
links in the bus to go into lower power states. There are two ways a
link can enter a lower power state:
1. Device-initiated LPM. When a USB device decides it can go into a
lower power link state, it sends a message to the parent hub, telling it
to go into either U1 or U2. Device-initiated LPM is good for devices
that send data to the host, like communications devices.
2. Hub-initiated LPM. After the link has been idle for a specific
amount of time, the parent hub will request that the child go into a
lower power state. The child can refuse that request. For example, a
USB modem may want to refuse the LPM request if it is in the middle of
receiving a text message. Hub-initiated LPM is good for devices where
only the host initiates the data transfer, like USB printers or USB mass
storage devices.
Links will be automatically placed into higher power states by the USB
hubs and roothubs whenever the host starts a USB transmission.
Introduce a new usb_driver flag, disable_hub_initiated_lpm, that allows
drivers to disable hub-initiated LPM.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: Hansjoerg Lipp <hjlipp@web.de>
Cc: Tilman Schmidt <tilman@imap.cc>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Oliver Neukum <oliver@neukum.name>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Jan Dumon <j.dumon@option.com>
Cc: Petko Manolov <petkan@users.sourceforge.net>
Cc: Steve Glendinning <steve.glendinning@smsc.com>
Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Roland Vossen <rvossen@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
Cc: Kan Yan <kanyan@broadcom.com>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: Ivo van Doorn <IvDoorn@gmail.com>
Cc: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Chaoming Li <chaoming_li@realsil.com.cn>
Cc: Daniel Drake <dsd@gentoo.org>
Cc: Ulrich Kunitz <kune@deine-taler.de>
Cc: linux-bluetooth@vger.kernel.org
Cc: gigaset307x-common@lists.sourceforge.net
Cc: netdev@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: ath9k-devel@lists.ath9k.org
Cc: libertas-dev@lists.infradead.org
Cc: users@rt2x00.serialmonkey.com
There are several different exit latencies associated with coming out of
the U1 or U2 lower power link state.
Device Exit Latency (DEL) is the maximum time it takes for the USB
device to bring its upstream link into U0. That can be found in the
SuperSpeed Extended Capabilities BOS descriptor for the device. The
time it takes for a particular link in the tree to exit to U0 is the
maximum of either the parent hub's U1/U2 DEL, or the child's U1/U2 DEL.
Hubs introduce a further delay that effects how long it takes a child
device to transition to U0. When a USB 3.0 hub receives a header
packet, it takes some time to decode that header and figure out which
downstream port the packet was destined for. If the port is not in U0,
this hub header decode latency will cause an additional delay for
bringing the child device to U0. This Hub Header Decode Latency is
found in the USB 3.0 hub descriptor.
We can use DEL and the header decode latency, along with additional
latencies imposed by each additional hub tier, to figure out the exit
latencies for both host-initiated and device-initiated exit to U0.
The Max Exit Latency (MEL) is the worst-case time it will take for a
host-initiated exit to U0, based on whether U1 or U2 link states are
enabled. The ping or packet must traverse the path to the device, and
each hub along the way incurs the hub header decode latency in order to
figure out which device the transfer was bound for. We say worst-case,
because some hubs may not be in the lowest link state that is enabled.
See the examples in section C.2.2.1.
Note that "HSD" is a "host specific delay" that the power appendix
architect has not been able to tell me how to calculate. There's no way
to get HSD from the xHCI registers either, so I'm simply ignoring it.
The Path Exit Latency (PEL) is the worst-case time it will take for a
device-initiate exit to U0 to place all the links from the device to the
host into U0.
The System Exit Latency (SEL) is another device-initiated exit latency.
SEL is useful for USB 3.0 devices that need to send data to the host at
specific intervals. The device may send an NRDY to indicate it isn't
ready to send data, then put its link into a lower power state. If it
needs to have that data transmitted at a specific time, it can use SEL
to back calculate when it will need to bring the link back into U0 to
meet its deadlines.
SEL is the worst-case time from the device-initiated exit to U0, to when
the device will receive a packet from the host controller. It includes
PEL, the time it takes for an ERDY to get to the host, a host-specific
delay for the host to process that ERDY, and the time it takes for the
packet to traverse the path to the device. See Figure C-2 in the USB
3.0 bus specification.
Note: I have not been able to get good answers about what the
host-specific delay to process the ERDY should be. The Intel HW
developers say it will be specific to the platform the xHCI host is
integrated into, and they say it's negligible. Ignore this too.
Separate from these four exit latencies are the U1/U2 timeout values we
program into the parent hubs. These timeouts tell the hub to attempt to
place the device into a lower power link state after the link has been
idle for that amount of time.
Create two arrays (one for U1 and one for U2) to store mel, pel, sel,
and the timeout values. Store the exit latency values in nanosecond
units, since that's the smallest units used (DEL is in us, but the Hub
Header Decode Latency is in ns).
If a USB 3.0 device doesn't have a SuperSpeed Extended Capabilities BOS
descriptor, it's highly unlikely it will be able to handle LPM requests
properly. So it's best to disable LPM for devices that don't have this
descriptor, and any children beneath it, if it's a USB 3.0 hub. Warn
users when that happens, since it means they have a non-compliant USB
3.0 device or hub.
This patch assumes a simplified design where links deep in the tree will
not have U1 or U2 enabled unless all their parent links have the
corresponding LPM state enabled. Eventually, we might want to allow a
different policy, and we can revisit this patch when that happens.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Rafael J. Wysocki