This patch (as1607) fixes a race that can occur if a USB host
controller is removed while a process is reading the
/sys/kernel/debug/usb/devices file.
The usb_device_read() routine uses the bus->root_hub pointer to
determine whether or not the root hub is registered. The is not a
valid test, because the pointer is set before the root hub gets
registered and remains set even after the root hub is unregistered and
deallocated. As a result, usb_device_read() or usb_device_dump() can
access freed memory, causing an oops.
The patch changes the test to use the hcd->rh_registered flag, which
does get set and cleared at the appropriate times. It also makes sure
to hold the usb_bus_list_lock mutex while setting the flag, so that
usb_device_read() will become aware of new root hubs as soon as they
are registered.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Don Zickus <dzickus@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit ca9c9d0c92.
Rafael wants more time to work on the user api to handle port power
issues, so let's just revert the sysfs changes for now.
Reported-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Lan Tianyu <tianyu.lan@intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As discussed at the kernel summit this year, CONFIG_EXPERIMENTAL means
nothing, so let's get rid of it.
Acked-by: Felipe Balbi <balbi@ti.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: David Herrmann <dh.herrmann@googlemail.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Neil Zhang <zhangwm@marvell.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
retval is 0, and carefully assigned - and tested as non zero.
This is not useful. While we are at it remove some other bogus initialisation
in the function
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This resolves the merge problems with:
drivers/usb/dwc3/gadget.c
drivers/usb/musb/tusb6010.c
that had been seen in linux-next.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It's not needed, and commented out, so just remove it.
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit ff823c79a5 ("usb: move children
to struct usb_port") forgot to consider the hub_disconnect sequence,
which releases ports before quiescing the hub, which will lead to a
use-after-free, since hub_quiesce() will try to disconnect ports'
children, which are already deallocated. Simple modprobe dummy_hcd &&
rmmod dummy_hcd will illustrate the problem.
This patch moves deallocation of hub's ports after hub_quiesce() call
in hub_disconnect().
Cc: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Because the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated and in hardirq context the interrupt is disabled.
so in usb/host code:
Removing the usage of flag IRQF_DISABLED;
Removing the calling local_irq save/restore actions in irq
handler usb_hcd_irq();
Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds two sysfs files for each usb hub port to allow userspace
to control the port power policy.
For an upcoming Intel xHCI roothub, this will translate into ACPI calls
to completely power off or power on the port. As a reminder, when these
ports are completely powered off, the USB host and device will see a
physical disconnect. All future USB device connections will be lost,
and the device will not be able to signal a remote wakeup.
The control sysfs file can be written to with two options:
"on" - port power must be on.
"off" - port must be off.
The state sysfs file reports usb port's power state:
"on" - powered on
"off" - powered off
"error" - can't get power state
For now, let userspace dictate the port power off policy. Future
patches may add an in-kernel policy.
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>
Alan Stern pointed out that a USB port could potentially get powered off
when the attached USB device is in the middle of enumerating, due to
race conditions:
http://marc.info/?l=linux-usb&m=134130616707548&w=2
If that happens, we need to ensure the enumeration fails. If a call to
usb_get_descriptor() fails for a reason other than a Stall, return an
error. That should handle the case where the port is powered off.
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>
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>
In the ACPI DSDT table, only usb root hub and usb ports are ACPI device
nodes. Originally, we bound the usb port's ACPI node to the usb device
attached to the port. However, we want to access those ACPI port
methods when the port is empty, and there's no usb_device associated
with that port.
Now that the usb port is a real device, we can bind the port's ACPI node
to struct usb_port instead.
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>
This patch turns each USB port on a hub into a new struct device. This
new device has the USB hub interface device as its parent. The port
devices are stored in a new structure (usb_port), and an array of
usb_ports are dynamically allocated once we know how many ports the USB
hub has.
Move the port_owner variable out of usb_hub and into this new structure.
A new file will be created in the hub interface sysfs directory, so
add documentation.
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>
The kernel's version number is used as decimal in the bcdDevice field of
the RH descriptor. For kernel version v3.12 we would see 3.0c in lsusb.
I am not sure how important it is to stick with bcd values since this is
this way since we started git history and nobody complained (however back
then we reported only 2.6).
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Apps which deal with devices which also have a kernel driver, need to do
the following:
1) Check which driver is attached, so as to not detach the wrong driver
(ie detaching usbfs while another instance of the app is using the device)
2) Detach the kernel driver
3) Claim the interface
Where moving from one step to the next for both 1-2 and 2-3 consists of
a (small) race window. So currently such apps are racy and people just live
with it.
This patch adds a new ioctl which makes it possible for apps to do this
in a race free manner. For flexibility apps can choose to:
1) Specify the driver to disconnect
2) Specify to disconnect any driver except for the one named by the app
3) Disconnect any driver
Note that if there is no driver attached, the ioctl will just act like the
regular claim-interface ioctl, this is by design, as returning an error for
this condition would open a new bag of race-conditions.
Changes in v2:
-Fix indentation of if blocks where the condition spans multiple lines
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1604) adds a CONFIG_INTF_STRINGS quirk for the Joss
infrared touchboard device. The device doesn't like to be asked for
its interface strings.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: adam ? <adam3337@wp.pl>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since the attribute avoid_reset_quirk is work for all devices including
those devices that can't morph, convert USB_QUIRK_RESET_MORPHS to
USB_QUIRK_RESET.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For following the way the rest of the usb core does, this patch is to change
the place of setting release callback.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In USB, the word "config" already has aseparate meaning. So it will
cause confusion if use "config" as variable's name for other purposes.
This patch is to convert the "config" to "val"
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
from interrupts for /dev/random and /dev/urandom. The goal is to
addresses weaknesses discussed in the paper "Mining your Ps and Qs:
Detection of Widespread Weak Keys in Network Devices", by Nadia
Heninger, Zakir Durumeric, Eric Wustrow, J. Alex Halderman, which will
be published in the Proceedings of the 21st Usenix Security Symposium,
August 2012. (See https://factorable.net for more information and an
extended version of the paper.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABCAAGBQJQF/0DAAoJENNvdpvBGATwIowQAOep9QKtLrBvb2lwIRVmeiy8
lRf7V/tYZnz4FePbR0W92JQfKYkCV8yyOO0bmeRzWL3v4m+lRwDTSyA1DDyQMoH+
LOMzvDKSLJMSXTXdSOIr1WYACphViCR/9CrbMBCKSkYfZLJ1MdaEDxT3rcpTGD0T
6iknUweiSkHHhkerU5yQL7FKzD5kYUe0hsF47w7QVlHRHJsW2fsZqkFoh+RpnhNw
03u+djxNGBo9qV81vZ9D1b0vA9uRlEjoWOOEG2XE4M2iq6TUySueA72dQnCwunfi
3kG/u1Swv2dgq6aRrP3H7zdwhYSourGxziu3jNhEKwKEohrxYY7xjNX3RVeTqP67
AzlKsOTWpRLIDrzjSLlb8VxRQiZewu8Unex3e1G+eo20sbcIObHGrxNp7K00zZvd
QZiMHhOwItwFTe4lBO+XbqH2JKbL9/uJmwh5EipMpQTraKO9E6N3CJiUHjzBLo2K
iGDZxRMKf4gVJRwDxbbP6D70JPVu8ZJ09XVIpsXQ3Z1xNqaMF0QdCmP3ty56q1o0
NvkSXxPKrijZs8Sk0rVDqnJ3ll8PuDnXMv5eDtL42VT818I5WxESn9djjwEanGv0
TYxbFub/NRxmPEE5B2Js5FBpqsLf5f282OSMeS/5WLBbnHJR1OoPoAhGVpHvxntC
bi5FC1OolqhvzVIdsqgt
=u7KM
-----END PGP SIGNATURE-----
Merge tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random
Pull random subsystem patches from Ted Ts'o:
"This patch series contains a major revamp of how we collect entropy
from interrupts for /dev/random and /dev/urandom.
The goal is to addresses weaknesses discussed in the paper "Mining
your Ps and Qs: Detection of Widespread Weak Keys in Network Devices",
by Nadia Heninger, Zakir Durumeric, Eric Wustrow, J. Alex Halderman,
which will be published in the Proceedings of the 21st Usenix Security
Symposium, August 2012. (See https://factorable.net for more
information and an extended version of the paper.)"
Fix up trivial conflicts due to nearby changes in
drivers/{mfd/ab3100-core.c, usb/gadget/omap_udc.c}
* tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random: (33 commits)
random: mix in architectural randomness in extract_buf()
dmi: Feed DMI table to /dev/random driver
random: Add comment to random_initialize()
random: final removal of IRQF_SAMPLE_RANDOM
um: remove IRQF_SAMPLE_RANDOM which is now a no-op
sparc/ldc: remove IRQF_SAMPLE_RANDOM which is now a no-op
[ARM] pxa: remove IRQF_SAMPLE_RANDOM which is now a no-op
board-palmz71: remove IRQF_SAMPLE_RANDOM which is now a no-op
isp1301_omap: remove IRQF_SAMPLE_RANDOM which is now a no-op
pxa25x_udc: remove IRQF_SAMPLE_RANDOM which is now a no-op
omap_udc: remove IRQF_SAMPLE_RANDOM which is now a no-op
goku_udc: remove IRQF_SAMPLE_RANDOM which was commented out
uartlite: remove IRQF_SAMPLE_RANDOM which is now a no-op
drivers: hv: remove IRQF_SAMPLE_RANDOM which is now a no-op
xen-blkfront: remove IRQF_SAMPLE_RANDOM which is now a no-op
n2_crypto: remove IRQF_SAMPLE_RANDOM which is now a no-op
pda_power: remove IRQF_SAMPLE_RANDOM which is now a no-op
i2c-pmcmsp: remove IRQF_SAMPLE_RANDOM which is now a no-op
input/serio/hp_sdc.c: remove IRQF_SAMPLE_RANDOM which is now a no-op
mfd: remove IRQF_SAMPLE_RANDOM which is now a no-op
...
Most Logitech UVC webcams (both early models that don't advertise UVC
compatibility and newer UVC-advertised devices) require the RESET_RESUME
quirk. Instead of listing each and every model, match the devices based
on the UVC interface information.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a whole class of devices (possibly from a specific vendor, or
across multiple vendors) require a quirk, explictly listing all devices
in the class make the quirks table unnecessarily large. Fix this by
allowing matching devices based on interface information.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Phy may need to change settings when port connect change.
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Tested-by: Subodh Nijsure <snijsure@grid-net.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi Greg,
Here's four bug fix patches for Link PM (LPM), which are marked for
3.5-stable. There's also three patches that turn on Latency Tolerance
Messaging (LTM) for xHCI host controllers and USB 3.0 devices that support
this low power feature.
Please queue for 3.6.
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJP/WCWAAoJEBMGWMLi1Gc5AjEQAIYHfWi3rhkoTpyhTyYhmzqM
/ZhAaeJXDe5VE1isfWK0mnzBz/X05MgpIxCck9CKMkcKZySJNkQFmK7iz6puGPVh
GnMQ3QkDo+9JSa7TKEX77ZG+bMkEHcAO2XbZjQs2IDfTuz+BJmQ8gFdjQGfAt/l3
KOU3k83Ci1gdtNgxqifQPBuo3o2l0L5Hn2E7XqFWQ8WUYYu1LWd2bZa/5dznq0hD
4n+ylcK0gDPa9pl7vRsLT79misdLTsJoBfjvooOE2Ms/5QXeFWRppsYRFOla8V4K
P2MjiXOCtZHN7GuxdLW776s5dZZyGZnbYNtTOSu0cOjheTC25KpmCm5XW/h5xMt3
saM6mhkSq5ZweDaLXvqV5O+WTQ2ePnubBpqR7/tVWkeUxJoK06ENKZ10dhsqfZw9
Wqcs4ze667Y3wjbBmAaF4b1bmEbhsJR/iAO2z3TLrfiAfYW3S5/4xCUCYujAXuff
n1gD75pnJJK1g4hfwFKDDNxWJtXIVqOaLMvD1x5AcGCnCG43mteruFfcS9q66LfI
uckf/PnQFAuqEx/J3dIava+yzZhNr0TMQp6aPtSCQUKgBukNf+/RRyB/pDGmYbC1
XBwqIYtv7yQ4w0DVPKd4edPP8zB8E5XMlAY/a1xvxcIa/tFBBDbVh8efXKeKrJEL
+smfSepLPwPzETe8YMNR
=G1bL
-----END PGP SIGNATURE-----
Merge tag 'for-usb-next-2012-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next
USB: Link PM fixes and Latency Tolerance Messaging
Hi Greg,
Here's four bug fix patches for Link PM (LPM), which are marked for
3.5-stable. There's also three patches that turn on Latency Tolerance
Messaging (LTM) for xHCI host controllers and USB 3.0 devices that support
this low power feature.
Please queue for 3.6.
Sarah Sharp
Send the USB device's serial, product, and manufacturer strings to the
/dev/random driver to help seed its pools.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Greg KH <greg@kroah.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.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>
When a user runs `echo 0 > bConfigurationValue` for a USB 3.0 device,
usb_disable_device() is called. This function disables all drivers,
deallocates interfaces, and sets the device configuration value to 0
(unconfigured).
With the new scheme to ensure that unconfigured devices have LPM
disabled, usb_disable_device() must call usb_unlocked_disable_lpm() once
it unconfigures the device.
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
The USB 3.0 Set/Clear Feature U1/U2 Enable cannot be sent to a device in
the Default or Addressed state. It can only be sent to a configured
device. Change the USB core to initialize the LPM disable count to 1
(disabled), which reflects this limitation.
Change usb_set_configuration() to ensure that if the device is
unconfigured on entry, usb_lpm_disable() is not called. This avoids
sending the Clear Feature U1/U2 when the device is in the Addressed
state. When usb_set_configuration() exits with a successfully installed
configuration, usb_lpm_enable() will be called.
Once the new configuration is installed, make sure
usb_set_configuration() only calls usb_enable_lpm() if the device moved
to the Configured state. If we have unconfigured the device by sending
it a Set Configuration for config 0, don't enable LPM.
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
The USB 3.0 specification says that sending a Set Feature or Clear
Feature for U1/U2 Enable is not a valid request when the device is in
the Default or Addressed state. It is only valid when the device is in
the Configured state.
The original LPM patch attempted to disable LPM after the device had
been reset by hub_port_init(), before it had the configuration
reinstalled. The TI hub I tested with did not fail the Clear Feature
U1/U2 Enable request that khubd sent while it was in the addressed
state, which is why I didn't catch it.
Move the LPM disable before the device reset, so that we can send the
Clear Feature U1/U2 Enable successfully, and balance the LPM disable
count.
Also delete any calls to usb_enable_lpm() on error paths that lead to
re-enumeration. The calls will fail because the device isn't
configured, and it's not useful to balance the LPM disable count because
the usb_device is about to be destroyed before re-enumeration.
Fix the early exit path ("done" label) to call usb_enable_lpm() to
balance the LPM disable count.
Note that calling usb_reset_and_verify_device() with an unconfigured
device may fail on the first call to usb_disable_lpm(). That's because
the LPM disable count is initialized to 0 (LPM enabled), and
usb_disable_lpm() will attempt to send a Clear Feature U1/U2 request to
a device in the Addressed state. The next patch will fix that.
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
We don't support sg for isoc transfers, enforce this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is to convert port_owners type from void * to struct dev_state *
in order to make code more readable.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When using urb->transfer_buffer we need to allocate physical contiguous buffers
for the entire transfer, which is pretty much guaranteed to fail with large
transfers.
Currently userspace works around this by breaking large transfers into multiple
urbs. For large bulk transfers this leads to all kind of complications.
This patch makes it possible for userspace to reliable submit large bulk
transfers to scatter-gather capable host controllers in one go, by using a
scatterlist to break the transfer up in managable chunks.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>
iso data buffers may have holes in them if some packets were short, so for
iso urbs we should always copy the entire buffer, just like the regular
processcompl does.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The host controller port status register supports CAS (Cold Attach
Status) bit. This bit could be set when USB3.0 device is connected
when system is in Sx state. When the system wakes to S0 this port
status with CAS bit is reported and this port can't be used by any
device.
When CAS bit is set the port should be reset by warm reset. This
was not supported by xhci driver.
The issue was found when pendrive was connected to suspended
platform. The link state of "Compliance Mode" was reported together
with CAS bit. This link state was also not supported by xhci and
core/hub.c.
The CAS bit is defined only for xhci root hub port and it is
not supported on regular hubs. The link status is used to force
warm reset on port. Make the USB core issue a warm reset when port
is in ether the 'inactive' or 'compliance mode'. Change the xHCI driver
to report 'compliance mode' when the CAS is set. This force warm reset
on the root hub port.
This patch should be backported to stable kernels as old as 3.2, that
contain the commit 10d674a82e "USB: When
hot reset for USB3 fails, try warm reset."
Signed-off-by: Stanislaw Ledwon <staszek.ledwon@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
This lets us catch the USB fixes that went into 3.5-rc3 into this branch,
as we want them here as well.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
TEAC's UD-H01 (and probably other devices) have a gap in the interface
number allocation of their descriptors:
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 220
bNumInterfaces 3
[...]
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
[...]
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 2
bInterfaceCount 2
bFunctionClass 1 Audio
bFunctionSubClass 0
bFunctionProtocol 32
iFunction 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
[...]
Once a configuration is selected, usb_set_configuration() walks the
known interfaces of a given configuration and calls find_iad() on
each of them to set the interface association pointer the interface
is included in.
The problem here is that the loop variable is taken for the interface
number in the comparison logic that gathers the association. Which is
fine as long as the descriptors are sane.
In the case above, however, the logic gets out of sync and the
interface association fields of all interfaces beyond the interface
number gap are wrong.
Fix this by passing the interface's bInterfaceNumber to find_iad()
instead.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-by: bEN <ml_all@circa.be>
Reported-by: Ivan Perrone <ivanperrone@hotmail.com>
Tested-by: ivan perrone <ivanperrone@hotmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi Greg,
Here's five bug fixes for 3.5. They fix some memory leaks in the
bandwidth calculation code, fix a couple bugs in the USB3 Link PM
patchset, and make system suspend and resume work on platforms with the
AsMedia ASM1042 xHCI host controller.
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJP2SkLAAoJEBMGWMLi1Gc5J08P/3+jxbPAC49miW8QXau993Ud
Ng8glY9hSavl06mLzf63Eke2SnQNJ9cq+FaqVyYOX5AVcNRCcgsyqJpllF2Eu8iU
e6Icomst4m1Jmk/38CSEo+eL3fBME4cfhT9zhzmR2dhJnzGx4HnCmAh8I+TqvGSy
osXWq0RQ6k6yUSBLH+nKeeCY1Nn4QYyBI1Ix4jKDKiZQSAfd1ppzh8bszOTFSE9b
y9BoB6lWVO7xnbofOlD+SqSSd8TLg9nyTekp2iVRLzY9Df83Xn8+Vu2YYJCJGB4V
1bLemY4hwP//TBAf45/KLDluIJb+JJ/Dzwa+W0YiogeD8munL8G21biXayB4G/11
rLnbHxmvBn/DC7s+aT2ie++Cn97ZV+WJW4p9x2hYnMJayukzV9+GqF4F+uD55NP7
WtfvIgmc4H4qAX2wEAYyJRUAL+tfGsBDjr/ItKiKaj15xsN2YPEE3fFx0s8Ht46M
aRQN1AJghK1MD/pQHRm9uP4GB3lZtcKwMgpkT7cYsXaBtf1Fn3VfHExpuZ4bvFNB
I+6B+WVF5PE//h+fdB1GGvLKv2FTR1DjvU6+tVv5KnBAm4Vmfnw+vrqMhG8KMZpF
NEVmiTN53tMyLC9ez7uBgzwVARE4RbqdiWHJIjj8CEjkbknDe0+keYBZ2egoQW6d
olNSuH3khQ/hoRYutqcK
=oodF
-----END PGP SIGNATURE-----
Merge tag 'for-usb-linus-2012-06-13' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
xhci: Bug fixes for 3.5
Hi Greg,
Here's five bug fixes for 3.5. They fix some memory leaks in the
bandwidth calculation code, fix a couple bugs in the USB3 Link PM
patchset, and make system suspend and resume work on platforms with the
AsMedia ASM1042 xHCI host controller.
Sarah Sharp
We check "u1_params" instead of checking "u2_params".
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Ensure that intfdata always is NULL if no driver is bound:
1) drvdata is for a driver to store a pointer to driver specific data
2) If no driver is bound, there is no driver specific data associated with
the device
3) Thus logically drvdata should be NULL if no driver is bound.
We already set intfdata to NULL when a driver is unbound, to ensure that
intfdata will be NULL even if the drivers disconnect method does not properly
clear it. This ensures that intfdata will also be NULL after a failed probe,
even if the driver's probe method left a (likely dangling) pointer in there.
Signed-off-by: Hans de Goede <hdegoede@redhat.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>
This class was not named properly years ago, and it turns out that tools
like udev can't properly see the devices in this class after booting due
to the fact that there is a bus with the same name in the system.
Changing this to "usbmisc" fixes this problem, and it solves the problem
for the future when we want to unify classes and busses.
Reported-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1558) fixes a problem affecting several ASUS computers:
The machine crashes or corrupts memory when going into suspend if the
ehci-hcd driver is bound to any controllers. Users have been forced
to unbind or unload ehci-hcd before putting their systems to sleep.
After extensive testing, it was determined that the machines don't
like going into suspend when any EHCI controllers are in the PCI D3
power state. Presumably this is a firmware bug, but there's nothing
we can do about it except to avoid putting the controllers in D3
during system sleep.
The patch adds a new flag to indicate whether the problem is present,
and avoids changing the controller's power state if the flag is set.
Runtime suspend is unaffected; this matters only for system suspend.
However as a side effect, the controller will not respond to remote
wakeup requests while the system is asleep. Hence USB wakeup is not
functional -- but of course, this is already true in the current state
of affairs.
A similar patch has already been applied as commit
151b612847 (USB: EHCI: fix crash during
suspend on ASUS computers). The patch supersedes that one and reverts
it. There are two differences:
The old patch added the flag at the USB level; this patch
adds it at the PCI level.
The old patch applied to all chipsets with the same vendor,
subsystem vendor, and product IDs; this patch makes an
exception for a known-good system (based on DMI information).
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Dâniel Fraga <fragabr@gmail.com>
Tested-by: Andrey Rahmatullin <wrar@wrar.name>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here's the driver core, and other driver subsystems, pull request for
the 3.5-rc1 merge window.
Outside of a few minor driver core changes, we ended up with the
following different subsystem and core changes as well, due to
interdependancies on the driver core:
- hyperv driver updates
- drivers/memory being created and some drivers moved into it
- extcon driver subsystem created out of the old Android staging switch
driver code
- dynamic debug updates
- printk rework, and /dev/kmsg changes
All of this has been tested in the linux-next releases for a few weeks
with no reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEABECAAYFAk+7q28ACgkQMUfUDdst+ykXmwCfcPASzC+/bDkuqdWsqzxlWZ7+
VOQAnAriySv397St36J6Hz5bMQZwB1Yq
=SQc+
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg Kroah-Hartman:
"Here's the driver core, and other driver subsystems, pull request for
the 3.5-rc1 merge window.
Outside of a few minor driver core changes, we ended up with the
following different subsystem and core changes as well, due to
interdependancies on the driver core:
- hyperv driver updates
- drivers/memory being created and some drivers moved into it
- extcon driver subsystem created out of the old Android staging
switch driver code
- dynamic debug updates
- printk rework, and /dev/kmsg changes
All of this has been tested in the linux-next releases for a few weeks
with no reported problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
Fix up conflicts in drivers/extcon/extcon-max8997.c where git noticed
that a patch to the deleted drivers/misc/max8997-muic.c driver needs to
be applied to this one.
* tag 'driver-core-3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (90 commits)
uio_pdrv_genirq: get irq through platform resource if not set otherwise
memory: tegra{20,30}-mc: Remove empty *_remove()
printk() - isolate KERN_CONT users from ordinary complete lines
sysfs: get rid of some lockdep false positives
Drivers: hv: util: Properly handle version negotiations.
Drivers: hv: Get rid of an unnecessary check in vmbus_prep_negotiate_resp()
memory: tegra{20,30}-mc: Use dev_err_ratelimited()
driver core: Add dev_*_ratelimited() family
Driver Core: don't oops with unregistered driver in driver_find_device()
printk() - restore prefix/timestamp printing for multi-newline strings
printk: add stub for prepend_timestamp()
ARM: tegra30: Make MC optional in Kconfig
ARM: tegra20: Make MC optional in Kconfig
ARM: tegra30: MC: Remove unnecessary BUG*()
ARM: tegra20: MC: Remove unnecessary BUG*()
printk: correctly align __log_buf
ARM: tegra30: Add Tegra Memory Controller(MC) driver
ARM: tegra20: Add Tegra Memory Controller(MC) driver
printk() - restore timestamp printing at console output
printk() - do not merge continuation lines of different threads
...
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>
