Now that devtmpfs is caring about uid/gid, we need to use the correct
internal types so users who have USER_NS enabled will have things work
properly for them.
Thanks to Eric for pointing this out, and the patch review.
Reported-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Kay Sievers <kay@vrfy.org>
Cc: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch removes the depends on USB from all config symbols in
drivers/usb/host/Kconfig and replace that with an if USB / endif block
as suggested by Alan Stern. Some source ... Kconfig lines have been
shuffled around to permit a better regroupment of the Kconfig files
depending on "config USB" item. No functionnal change is introduced.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some drivers want to tell userspace what uid and gid should be used for
their device nodes, so allow that information to percolate through the
driver core to userspace in order to make this happen. This means that
some systems (i.e. Android and friends) will not need to even run a
udev-like daemon for their device node manager and can just rely in
devtmpfs fully, reducing their footprint even more.
Signed-off-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the call to dev_pm_qos_hide_flags(), added by commit 6e30d7cb
"usb: Add driver/usb/core/(port.c,hub.h) files", from
usb_port_device_release(), because (1) it is completely unnecessary
(the flags have been removed already by the PM core during the
unregistration of the device object) and (2) it triggers a NULL
pointer dereference in sysfs_find_dirent() (dev->kobj.sd is NULL at
this point).
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
when suspend, it need check 'udev->actconfig'.
so when process failure, also need check it.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 9214d1d8 set the USB persist flag as a default for all devices.
This might be desirable for some distributions, but it certainly has its
trade-offs... most importantly, it can significantly increase system
resume time, because the kernel blocks on resuming (and sometimes
resetting) USB devices before it unfreezes userspace.
This patch introduces a new config option CONFIG_USB_DEFAULT_PERSIST,
which allows distributions to make this decision on their own without
the need to carry a custom patch or revert the kernel's setting in
userspace.
[edited the Kconfig help text a bit - gregkh]
Signed-off-by: Julius Werner <jwerner@chromium.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It seems to be getting more common recently for EHCI host controllers
to be probed after their companion UHCI or OHCI controllers. This may
be caused partly by splitting the ehci-pci driver out from ehci-hcd,
or it may be caused by changes in the way the kernel does driver
probing.
Regardless, it has a tendency to cause problems. When an EHCI
controller is initialized, it takes ownership of all the ports away
from the companions. In effect, it forcefully disconnects all the USB
devices that may already be using a companion controller.
This patch (as1672b) tries to make the transition more orderly by
deconfiguring the root hubs for all the companion controllers before
initializing the EHCI controller, and reconfiguring them afterward.
The result is a soft disconnect rather than a hard one.
Internally, the patch refactors the code involved in associating EHCI
controllers with their companions. The old approach, in which a
single function is called with an argument telling it what to do (the
companion_action enum), has been replaced with a scheme using multiple
callback functions, each performing a single task.
This patch won't solve all the problems people encounter when their
EHCI controllers start up, but it will at least reduce the number of
error messages generated by the unexpected disconnections.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
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 (as1674) speeds up system sleep transitions by not
suspending each individual device on a USB-1.1 or USB-2 bus. The
devices will automatically go into suspend when their root hubs are
suspended (i.e., stop sending out Start-Of-Frame packets) -- this is
what the USB spec calls "global suspend".
Since this is what we do already when CONFIG_USB_SUSPEND isn't
enabled, it shouldn't cause any problems.
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 (as1673) reduces the amount of log spew from the hub driver
by removing a bunch of error messages in the case where the device in
question is already known to have been disconnected. Since the
disconnect event itself appears in the log, there's no need for other
error messages.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Jenya Y <jy.gerstmaier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The calls to usb_poison_urb and usb_unpoison_urb are expected to be
balanced. However, if an urb that has not yet been submitted is
poisoned, its reject counter will not be increased as its ep-field is
NULL. A consecutive call to unpoison will thus in fact poison the urb
as its reject counter will be decremented to a negative value,
effectively preventing the urb from being submitted.
Note that there are currently no in-kernel drivers affected by this.
Cc: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Return an error if hub->descriptor->bNbrPorts==0. Without this additional
check, we can end up doing a "hub->ports = kzalloc(0, GFP_KERNEL)".
This hub->ports pointer will therefore be non-NULL and will be used.
Example of dmesg:
INIT: usb 1-1: New USB device found, idVendor=0424, idProduct=2512
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
hub 1-1:1.0: USB hub found
version 2.86 bootinghub 1-1:1.0: 0 ports detected
Unable to handle kernel NULL pointer dereference at virtual address 00000010
Signed-off-by: David Linares <dlinares.linux@gmail.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 is to bind xhci root hub usb port with its acpi node.
The port num in the acpi table matches with the sequence in the xhci
extended capabilities table. So call usb_hcd_find_raw_port_number() to
transfer hub port num into raw port number which associates with
the sequence in the xhci extended capabilities table before binding.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xhci driver divides the root hub into two logical hubs which work
respectively for usb 2.0 and usb 3.0 devices. They are independent
devices in the usb core. But in the ACPI table, it's one device node
and all usb2.0 and usb3.0 ports are under it. Binding usb port with
its acpi node needs the raw port number which is reflected in the xhci
extended capabilities table. This patch is to add find_raw_port_number
callback to struct hc_driver(), fill it with xhci_find_raw_port_number()
which will return raw port number and add a wrap usb_hcd_find_raw_port_number().
Otherwise, refactor xhci_find_real_port_number(). Using
xhci_find_raw_port_number() to get real index in the HW port status
registers instead of scanning through the xHCI roothub port array.
This can help to speed up.
All addresses in xhci->usb2_ports and xhci->usb3_ports array are
kown good ports and don't include following bad ports in the extended
capabilities talbe.
(1) root port that doesn't have an entry
(2) root port with unknown speed
(3) root port that is listed twice and with different speeds.
So xhci_find_raw_port_number() will only return port num of good ones
and never touch bad ports above.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
xhci has its own interrupt enabling routine, which will try to
use MSI-X/MSI if present. So the usb core shouldn't try to enable
legacy interrupts; on some machines the xhci legacy IRQ setting
is invalid.
v3: Be careful to not break XHCI_BROKEN_MSI workaround (by trenn)
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Frederik Himpe <fhimpe@vub.ac.be>
Cc: David Haerdeman <david@hardeman.nu>
Cc: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reviewed-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB uses the .find_bridge() callback from struct acpi_bus_type
incorrectly, because as a result of the way it is used by USB every
device in the system that doesn't have a bus type or parent is
passed to usb_acpi_find_device() for inspection.
What USB actually needs, though, is to call usb_acpi_find_device()
for USB ports that don't have a bus type defined, but have
usb_port_device_type as their device type, as well as for USB
devices.
To fix that replace the struct bus_type pointer in struct
acpi_bus_type used for matching devices to specific subsystems
with a .match() callback to be used for this purpose and update
the users of struct acpi_bus_type, including USB, accordingly.
Define the .match() callback routine for USB, usb_acpi_bus_match(),
in such a way that it will cover both USB devices and USB ports
and remove the now redundant .find_bridge() callback pointer from
usb_acpi_bus.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Jeff Garzik <jgarzik@pobox.com>
Pull vfs pile (part one) from Al Viro:
"Assorted stuff - cleaning namei.c up a bit, fixing ->d_name/->d_parent
locking violations, etc.
The most visible changes here are death of FS_REVAL_DOT (replaced with
"has ->d_weak_revalidate()") and a new helper getting from struct file
to inode. Some bits of preparation to xattr method interface changes.
Misc patches by various people sent this cycle *and* ocfs2 fixes from
several cycles ago that should've been upstream right then.
PS: the next vfs pile will be xattr stuff."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (46 commits)
saner proc_get_inode() calling conventions
proc: avoid extra pde_put() in proc_fill_super()
fs: change return values from -EACCES to -EPERM
fs/exec.c: make bprm_mm_init() static
ocfs2/dlm: use GFP_ATOMIC inside a spin_lock
ocfs2: fix possible use-after-free with AIO
ocfs2: Fix oops in ocfs2_fast_symlink_readpage() code path
get_empty_filp()/alloc_file() leave both ->f_pos and ->f_version zero
target: writev() on single-element vector is pointless
export kernel_write(), convert open-coded instances
fs: encode_fh: return FILEID_INVALID if invalid fid_type
kill f_vfsmnt
vfs: kill FS_REVAL_DOT by adding a d_weak_revalidate dentry op
nfsd: handle vfs_getattr errors in acl protocol
switch vfs_getattr() to struct path
default SET_PERSONALITY() in linux/elf.h
ceph: prepopulate inodes only when request is aborted
d_hash_and_lookup(): export, switch open-coded instances
9p: switch v9fs_set_create_acl() to inode+fid, do it before d_instantiate()
9p: split dropping the acls from v9fs_set_create_acl()
...
If one storage interface or usb network interface(iSCSI case) exists in
current configuration, memory allocation with GFP_KERNEL during
usb_device_reset() might trigger I/O transfer on the storage interface
itself and cause deadlock because the 'us->dev_mutex' is held in
.pre_reset() and the storage interface can't do I/O transfer when the
reset is triggered by other interface, or the error handling can't be
completed if the reset is triggered by the storage itself (error
handling path).
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Decotigny <david.decotigny@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.de>
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This pulls in a bunch of fixes that are in Linus's tree because we need them
here for testing and development.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
for NUL terminated string, better notice '\0' in the end.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 88bb965ed7.
The linux-next branch of linux-pm tree has replaced
acpi_power_resource_(un)register_device() with new routines.
Commit 88bb965 will cause conflict in the linux-next tree.
So revert it and this will not affect other functions. Will
send a new patch with new routines after 3.9 merge window.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.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>
This patch is to set power.async_suspend for usb port in order
to allow it to be suspended and resumed asynchronously during
system sleep transitions.
The power.async_suspend flag is also set for devices that don't have
suspend or resume callbacks, because otherwise they would make the
main suspend/resume thread wait for their "asynchronous" children
(during suspend) or parents (during resume), effectively negating the
possible gains from executing these devices' suspend and resume
callbacks asynchronously.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is to expose usb port's pm qos flags(pm_qos_no_power_off,
pm_qos_remote_wakeup) to user space. User can set pm_qos_no_power_off
flag to prohibit the port from being powered off.
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>
This patch is to add usb port auto power off mechanism.
When usb device is suspending, usb core will suspend usb port and
usb port runtime pm callback will clear PORT_POWER feature to
power off port if all conditions were met. These conditions are
remote wakeup disable, pm qos NO_POWER_OFF flag clear and persist
enable. When it resumes, power on port again.
Add did_runtime_put in the struct usb_port to ensure
pm_runtime_get/put(portdev) to be called pairedly. Set did_runtime_put
to true when call pm_runtime_put(portdev) during suspending. The
pm_runtime_get(portdev) only will be called when did_runtime_put
is set to true during resuming. Set did_runtime_put to false after
calling pm_runtime_get(portdev).
Make clear_port_feature() and hdev_to_hub() as global symbol.
Rename clear_port_feature() to usb_clear_port_feature() and
hdev_to_hub() to usb_hub_to_struct_hub().
Extend hub_port_debounce() with the fuction of debouncing to
be connected. Add two wraps: hub_port_debounce_be_connected()
and hub_port_debouce_be_stable().
Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb ssds
needs around 1.5 or more to make the hub port status to be
connected steadily after being powered off and powered on.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is to add runtime pm callback for usb port device.
Set/clear PORT_POWER feature in the resume/suspend callback.
Add portnum for struct usb_port to record port number. Do
pm_rumtime_get_sync/put(portdev) when a device is plugged/unplugged
to prevent it from being powered off when it is active.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is to register usb port's acpi power resources. Create
link between usb port device and its acpi power resource.
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>
This patch (as1646) fixes a long-standing bug in the USB hub driver.
Upon conversion from char to unsigned long, the bytes in the status
buffer are subject to unwanted sign extension. The bytes should be
declared as u8 rather than char, to prevent this.
This effects of this bug are minimal. The hub driver may end up doing
a little unnecessary extra work because it thinks events have occurred
on some ports when they really haven't.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Usb3.0 device defines function remote wakeup which is only for interface
recipient rather than device recipient. This is different with usb2.0 device's
remote wakeup feature which is defined for device recipient. According usb3.0
spec 9.4.5, the function remote wakeup can be modified by the SetFeature()
requests using the FUNCTION_SUSPEND feature selector. This patch is to use
correct way to disable usb3.0 device's function remote wakeup after suspend
error and resuming.
This should be backported to kernels as old as 3.4, that contain the
commit 623bef9e03 "USB/xhci: Enable remote
wakeup for USB3 devices."
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
ACPI provide "_PLD" and "_UPC" aml methods to describe usb port
visibility and connectability. This patch is to add usb_hub_adjust_DeviceRemovable()
to adjust usb hub port's DeviceRemovable according ACPI information and invoke it in
the rh_call_control(). When hub descriptor request is issued at first time,
usb port device isn't created and usb port is not bound with acpi. So first
hub descriptor request is not changed based on ACPI information. After usb
port devices being created, call usb_hub_adjust_DeviceRemovable in the hub_configure()
and then set hub port's DeviceRemovable according ACPI information and this also works
for non-root hub.
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>
To show the relationship between usb port and child device,
add link file "port" under usb device's sysfs directoy and
"device" under usb port device's sysfs directory. They are linked
to each other.
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>
Some platforms provide usb port connect types through ACPI. This
patch is to add this new attribute to expose these information
to user space.
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>
This patch is to fix compilation error and warning on the arm and blackfin.
Add linux/slab.h head file to driver/usb/core/port.c. These are reported
from 0-DAY kernel build testing backend.
head: 6e30d7cba9
commit: 6e30d7cba9 [26/26] usb: Add driver/usb/core/(port.c,hub.h) files
config: make ARCH=arm at91_dt_defconfig
All error/warnings:
drivers/usb/core/port.c: In function 'usb_port_device_release':
>> drivers/usb/core/port.c:25:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
drivers/usb/core/port.c: In function 'usb_hub_create_port_device':
>> drivers/usb/core/port.c:38:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration]
>> drivers/usb/core/port.c:38:40: error: 'GFP_KERNEL' undeclared (first use in this function)
drivers/usb/core/port.c:38:40: note: each undeclared identifier is reported only once for each function it appears in
cc1: some warnings being treated as errors
head: 6e30d7cba9
commit: 6e30d7cba9 [26/26] usb: Add driver/usb/core/(port.c,hub.h) files
config: make ARCH=blackfin BF526-EZBRD_defconfig
All warnings:
drivers/usb/core/port.c: In function 'usb_port_device_release':
drivers/usb/core/port.c:25:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
drivers/usb/core/port.c: In function 'usb_hub_create_port_device':
drivers/usb/core/port.c:38:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration]
>> drivers/usb/core/port.c:38:11: warning: assignment makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
Reported-by: Fengguang Wu <wfg@linux.intel.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is to create driver/usb/core/(port.c,hub.h) files and move usb
port related code into port.c.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sarah pointed out that the USB3.0 spec also updates the amount of power
that may be consumed by the device and quoted 9.2.5.1:
|"The amount of current draw for SuperSpeed devices are increased to 150
|mA for low-power devices and 900 mA for high-power"
This patch tries to update all users to use the larger values for
SuperSpeed devices and use the "old" ones for everything else.
While here, two other changes suggested by Alan:
- the comment referering to 7.2.1.1 has been updated to 7.2.1 which is
the correct source of the action.
- the check for hubs with zero ports has been removed.
- compute bus power by full_load * num_ports on root hubs
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USB 2.0 specification says that bMaxPower is the maximum power
consumption expressed in 2 mA units and the USB 3.0 specification says
that it is expressed in 8 mA units.
This patch adds a helper function usb_get_max_power() which computes the
value based on config & usb_device's speed value. The the device descriptor
dump computes the value on its own.
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some touchscreens have buggy firmware which claims
remote wakeup to be enabled after a reset. They nevertheless
crash if the feature is cleared by the host.
Add a check for reset resume before checking for
an enabled remote wakeup feature. On compliant
devices the feature must be cleared after a reset anyway.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Refactor hub_port_wait_reset into a small loop to wait for the port
reset to be complete, and then a larger block to deal with the final
port status. This patch should not change any current behavior.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Change the code that manually issues a Set Port Feature(Link State) to
use the new helper function hub_set_port_link_state().
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
A USB 3.0 device can transition to the Inactive state if a U1 or U2 exit
transition fails. The current code in hub_events simply issues a warm
reset, but does not call any pre-reset or post-reset driver methods (or
unbind/rebind drivers without them). Therefore the drivers won't know
their device has just been reset.
hub_events should instead call usb_reset_device. This means
hub_port_reset now needs to figure out whether it should issue a warm
reset or a hot reset.
Remove the FIXME note about needing disconnect() for a NOTATTACHED
device. This patch fixes that.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
When a hot reset fails on a USB 3.0 port, the current port reset code
recursively calls hub_port_reset inside hub_port_wait_reset. This isn't
ideal, since we should avoid recursive calls in the kernel, and it also
doesn't allow us to issue multiple warm resets on reset failures.
Rip out the recursive call. Instead, add code to hub_port_reset to
issue a warm reset if the hot reset fails, and try multiple warm resets
before giving up on the port.
In hub_port_wait_reset, remove the recursive call and re-indent. The
code is basically the same, except:
1. It bails out early if the port has transitioned to Inactive or
Compliance Mode after the reset completed.
2. It doesn't consider a connect status change to be a failed reset. If
multiple warm resets needed to be issued, the connect status may have
changed, so we need to ignore that and look at the port link state
instead. hub_port_reset will now do that.
3. It unconditionally sets udev->speed on all types of successful
resets. The old recursive code would set the port speed when the second
hub_port_reset returned.
The old code did not handle connected devices needing a warm reset well.
There were only two situations that the old code handled correctly: an
empty port needing a warm reset, and a hot reset that migrated to a warm
reset.
When an empty port needed a warm reset, hub_port_reset was called with
the warm variable set. The code in hub_port_finish_reset would skip
telling the USB core and the xHC host that the device was reset, because
otherwise that would result in a NULL pointer dereference.
When a USB 3.0 device reset migrated to a warm reset, the recursive call
made the call stack look like this:
hub_port_reset(warm = false)
hub_wait_port_reset(warm = false)
hub_port_reset(warm = true)
hub_wait_port_reset(warm = true)
hub_port_finish_reset(warm = true)
(return up the call stack to the first wait)
hub_port_finish_reset(warm = false)
The old code didn't want to notify the USB core or the xHC host of device reset
twice, so it only did it in the second call to hub_port_finish_reset,
when warm was set to false. This was necessary because
before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
would pay attention to the xHC Reset Device command error status, and
the second call would always fail.
Now that we no longer have the recursive call, and warm can change from
false to true in hub_port_reset, we need to have hub_port_finish_reset
unconditionally notify the USB core and the xHC of the device reset.
In hub_port_finish_reset, unconditionally clear the connect status
change (CSC) bit for USB 3.0 hubs when the port reset is done. If we
had to issue multiple warm resets for a device, that bit may have been
set if the device went into SS.Inactive and then was successfully warm
reset.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
The next patch will refactor the hub port code to rip out the recursive
call to hub_port_reset on a failed hot reset. In preparation for that,
make sure all code paths can deal with being called with a NULL udev.
The usb_device will not be valid if warm reset was issued because a port
transitioned to the Inactive or Compliance Mode on a device connect.
This patch should have no effect on current behavior.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
The EHCI host controller needs to prevent EHCI initialization when the
UHCI or OHCI companion controller is in the middle of a port reset. It
uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under
an EHCI host controller, so it makes no sense to down the semaphore for
USB 3.0 hubs. It also makes the warm port reset code more complex.
Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
An empty port can transition to either Inactive or Compliance Mode if a
newly connected USB 3.0 device fails to link train. In that case, we
issue a warm reset. Some devices, such as John's Roseweil eusb3
enclosure, slip back into Compliance Mode after the warm reset.
The current warm reset code does not check for device connect status on
warm reset completion, and it incorrectly reports the warm reset
succeeded. This causes the USB core to attempt to send a Set Address
control transfer to a port in Compliance Mode, which will always fail.
Make hub_port_wait_reset check the current connect status and link state
after the warm reset completes. Return a failure status if the device
is disconnected or the link state is Compliance Mode or SS.Inactive.
Make hub_events disable the port if warm reset fails. This will disable
the port, and then bring it back into the RxDetect state. Make the USB
core ignore the connect change until the device reconnects.
Note that this patch does NOT handle connected devices slipping into the
Inactive state very well. This is a concern, because devices can go
into the Inactive state on U1/U2 exit failure. However, the fix for
that case is too large for stable, so it will be submitted in a separate
patch.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
The port reset code bails out early if the current connect status is
cleared (device disconnected). If we're issuing a hot reset, it may
also look at the link state before the reset is finished.
Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the
Error state or Resetting state, the port connection bit retains the
value from the previous state. Therefore we can't trust it until the
reset finishes. Also, the xHCI spec section 4.19.1.2.5 says software
shall ignore the link state while the port is resetting, as it can be in
an unknown state.
The port state during reset is also unknown for USB 2.0 hubs. The hub
sends a reset signal by driving the bus into an SE0 state. This
overwhelms the "connect" signal from the device, so the port can't tell
whether anything is connected or not.
Fix the port reset code to ignore the port link state and current
connect bit until the reset finishes, and USB_PORT_STAT_RESET is
cleared.
Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case,
because it's redundant. When the warm reset finishes, the port reset
bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set.
Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit
in the code to deal with the finished reset.
This patch should be backported to all stable kernels.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
John's NEC 0.96 xHCI host controller needs a longer timeout for a warm
reset to complete. The logs show it takes 650ms to complete the warm
reset, so extend the hub reset timeout to 800ms to be on the safe side.
This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
If hot and warm reset fails, or a port remains in the Compliance Mode,
the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0
ports, once the port is placed into the Disabled link state, it will not
report any new device connects. To get device connect notifications, we
need to put the link into the Disabled state, and then the RxDetect
state.
The xHCI driver needs to atomically clear all change bits on USB 3.0
port disable, so that we get Port Status Change Events for future port
changes. We could technically do this in the USB core instead of in the
xHCI roothub code, since the port state machine can't advance out of the
disabled state until we set the link state to RxDetect. However,
external USB 3.0 hubs don't need this code. They are level-triggered,
not edge-triggered like xHCI, so they will continue to send interrupt
events when any change bit is set. Therefore it doesn't make sense to
put this code in the USB core.
This patch is part of a series to fix several reports of infinite loops
on device enumeration failure. This includes John, when he boots with
a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96
host controller. The fix requires warm reset support, so it does not
make sense to backport this patch to stable kernels without warm reset
support.
This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72ab "usbcore: refine warm
reset logic"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: John Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
When the USB core finishes reseting a USB device, the xHCI driver sends
a Reset Device command to the host. The xHC then updates its internal
representation of the USB device to the 'Default' device state. If the
device was already in the Default state, the xHC will complete the
command with an error status.
If a device needs to be reset several times during enumeration, the
second reset will always fail because of the xHCI Reset Device command.
This can cause issues during enumeration.
For example, usb_reset_and_verify_device calls into hub_port_init in a
loop. Say that on the first call into hub_port_init, the device is
successfully reset, but doesn't respond to several set address control
transfers. Then the port will be disabled, but the udev will remain in
tact. usb_reset_and_verify_device will call into hub_port_init again.
On the second call into hub_port_init, the device will be reset, and the
xHCI driver will issue a Reset Device command. This command will fail
(because the device is already in the Default state), and
usb_reset_and_verify_device will fail. The port will be disabled, and
the device won't be able to enumerate.
Fix this by ignoring the return value of the HCD reset_device callback.
This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
USB 3.0 hubs and roothubs will automatically transition a failed hot
reset to a warm (BH) reset. In that case, the warm reset change bit
will be set, and the link state change bit may also be set. Change
hub_port_finish_reset to unconditionally clear those change bits for USB
3.0 hubs. If these bits are not cleared, we may lose port change events
from the roothub.
This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab "usbcore: refine
warm reset logic".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
Pull trivial branch from Jiri Kosina:
"Usual stuff -- comment/printk typo fixes, documentation updates, dead
code elimination."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits)
HOWTO: fix double words typo
x86 mtrr: fix comment typo in mtrr_bp_init
propagate name change to comments in kernel source
doc: Update the name of profiling based on sysfs
treewide: Fix typos in various drivers
treewide: Fix typos in various Kconfig
wireless: mwifiex: Fix typo in wireless/mwifiex driver
messages: i2o: Fix typo in messages/i2o
scripts/kernel-doc: check that non-void fcts describe their return value
Kernel-doc: Convention: Use a "Return" section to describe return values
radeon: Fix typo and copy/paste error in comments
doc: Remove unnecessary declarations from Documentation/accounting/getdelays.c
various: Fix spelling of "asynchronous" in comments.
Fix misspellings of "whether" in comments.
eisa: Fix spelling of "asynchronous".
various: Fix spelling of "registered" in comments.
doc: fix quite a few typos within Documentation
target: iscsi: fix comment typos in target/iscsi drivers
treewide: fix typo of "suport" in various comments and Kconfig
treewide: fix typo of "suppport" in various comments
...
'new_interfaces' should be freed to avoid memory leak.
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove conditional code based on CONFIG_HOTPLUG being false. It's
always on now in preparation of it going away as an option.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This resolves a conflict with these files:
drivers/usb/early/ehci-dbgp.c
drivers/usb/host/ehci-ls1x.c
drivers/usb/host/ohci-xls.c
drivers/usb/musb/ux500.c
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The old parameter "port" is useless for phy notify, as one usb
phy is only for one usb port. New parameter "speed" stands for
the device's speed which is on the port, this "speed" parameter
is needed at some platforms which will do some phy operations
according to device's speed.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Mike Thompson <mpthompson@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
At commit 925aa46ba9, Richard Zhao
<richard.zhao@freescale.com> adds the phy notification callback
when port change occurs. In fact, this phy notification should
be added according to below rules:
1. Only set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
during high speed host mode.
2. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
during the reset and speed negotiation period.
3. Do not set HW_USBPHY_CTRL.ENHOSTDISCONDETECT
during host suspend/resume sequence.
Please refer: i.mx23RM(page: 413) for below rules.
http://www.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf
Freescale i.MX SoC, i.mx23, i.mx28 and i.mx6(i.mx6SL does not
need to follow the 3rd rule) need to follow above rules.
Current code set connect notification (HW_USBPHY_CTRL.ENHOSTDISCONDETECT)
at hub_port_connect_change, it conflicts with above the 2th rule.
The correct notification setting method should be:
1. Set connect notify after the second bus reset.
2. Set disconnect notify after disconnection.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Mike Thompson <mpthompson@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It looks like I've run into some inconsistency in the USB stack behavior.
The USB stack maintains, among others, two states for the attach
USB device: authorized and owned. Authorization state is accessible to
the user space code through correspondent sysfs files, the ownership
can be set by claiming the hub's port with ioctl call. Both state may
be set before the device is attached, by access the hub settings. When
the new device is attached, both authorization and ownership prevent
the kernel USB stack from setting the newly attached device
configuration, but when the device is authorized, the ownership state
is ignored. It looks like ignoring the ownership state on
authorization make the stack behavior inconsistent; it also prevents
the user space code from completely overriding configuration
selection, important for implementing workarounds for bugs in the
device configuration selection.
The following patch makes the stack behavior more consistent, by
moving ownership test into usb_choose_configuration - the later
function is used both by generic_probe and usb_authorize_device
Signed-off-by: Joseph Hindin <hindin@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 73d4066055.
Martin Steigerwald reported that this change caused a hard lockup when
using USB if threadirqs are enabled. Thomas pointed out that this patch
is incorrect, and can cause problems. So revert it to get the
previously working functionality back.
Reported-by: Martin Steigerwald <Martin@lichtvoll.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chuansheng Liu <chuansheng.liu@intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1633) changes slightly the way usbcore handled
submissions of URBs that are already active. It will now return
-EBUSY rather than -EINVAL, and it will call WARN_ONCE to draw
people's attention to the bug.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1631) fixes a bug that shows up when a config change
fails for a device under an xHCI controller. The controller needs to
be told to disable the endpoints that have been enabled for the new
config. The existing code does this, but before storing the
information about which endpoints were enabled! As a result, any
second attempt to install the new config is doomed to fail because
xhci-hcd will refuse to enable an endpoint that is already enabled.
The patch optimistically initializes the new endpoints' device
structures before asking the device to switch to the new config. If
the request fails then the endpoint information is already stored, so
we can use usb_hcd_alloc_bandwidth() to disable the endpoints with no
trouble. The rest of the error path is slightly more complex now; we
have to disable the new interfaces and call put_device() rather than
simply deallocating them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Matthias Schniedermeyer <ms@citd.de>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1621) removes the limit on the number of loops allowed
in hub_tt_work(). The value is arbitrary, and it's silly to have a
limit in the first place -- anything beyond the limit would not get
handled.
Besides, it's most unlikely that we'll ever need to clear more than a
couple of TT buffers at any time.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dev_<level> calls take less code than dev_printk(KERN_<LEVEL>
and reducing object size is good.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This pulls in all of the USB changes in 3.7-rc3 into usb-next and
resolves the merge issue with:
drivers/usb/misc/ezusb.c
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch sets hub device's default autosuspend delay as 0 to
speedup bus suspend, see comments in code for details.
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 hub status endpoint has a long 'bInterval', which is 255ms
for FS/LS device and 256ms for HS device according to USB 2.0 spec,
so the device connection change may be reported later more than 255ms
via status pipe.
The connection change in hub may have been happened already on the
downstream ports, but no status URB completes when it is killed
in hub_suspend(auto), so the connection change may be missed by some
buggy hub devices, which won't generate remote wakeup signal after
their remote wakeup is enabled and they are put into suspend state.
The problem can be observed at least on the below Genesys Logic, Inc.
hub devices:
0x05e3,0x0606
0x05e3,0x0608
In theory, there is no way to fix the problem completely, but we
can make it less likely to occur by this patch.
This patch introduces one quirk of HUB_QUIRK_CHECK_PORTS_AUTOSUSPEND
to check ports' change during hub_suspend(auto) for the buggy
devices. If ports' change is found, terminate the auto suspend and
return to working state.
So for the buggy hubs, if the connection change happend before
the ports' check, it can be handled correctly. If it happens between
the ports' check and enabling remote wakeup/entering suspend, it
will be missed. Considered the interval is quite short, it is very
less likely to happen during the window.
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 (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>
We defined bus_to_hdc for that, use it.
Signed-off-by: Yuanhan Liu <yliu.null@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
flush_work_sync and flush_work are now the same and flush_work_sync
has been deprecated. This fixes the following warning:
drivers/usb/core/hub.c: In function hub_quiesce:
drivers/usb/core/hub.c:1216:3: warning: flush_work_sync is deprecated (declared at include/linux/workqueue.h:448) [-Wdeprecated-declarations]
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
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>
The handling of large output bulk transfers is broken; the same user
page is read over and over again. Fixed with this patch.
Cc: stable <stable@vger.kernel.org>
Acked-by: Peter Stuge <peter@stuge.se>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi Greg,
Here's four fixes for the USB 3.0 Link Power Management code. They
work around some USB 3.0 devices that don't support LPM, like the
Western Digital My Passport hard drive. They also fix an LPM disable
ref count bug that would cause LPM to remain disabled for a device
after a failed probe.
Please queue for 3.7 after the merge window closes. Several patches are
marked for stable.
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQdzkvAAoJEBMGWMLi1Gc5GyYP/1RoDNMNVS+AZVxaoC6t6FhT
rWyg74vWZqnfrf6XKnZshELjJ5rK52ZvKykmnAjIXT0y9D9bOKxkxi0008GMeGNO
UulYZH5TAxlCsIqjzYmb87lJ42+CzNOhWrCNwQdn5BdM/gypDHcKx7kb2b+Jljky
Xe6mdSDo+KGScBRLJPPvAIuk/IsZIFarcZruYP55PPJ44Q9LWR4Uq8zm6t8qJYkP
0s8KNHYXeKZBg2z50iILo7WWRoNIHvAH9xJigU5T2QQCSzBeE/ILkNzkkSrBfoJp
0DAV9fpdkYLhx1aSp628uorcn4D0lOCSoCasVdgeUSdi/XVpJWU1DbAPljfPK7lH
JBS4ba3s6/25Dl+BRgz+MUq6PBbAexmqg+5jhTkP2GKU8nSsXI1ZkahjRFgAgWxC
FRHhNINTq56rnY3s3Ts30pjtZ9tai7BnWVKU9/0cNeaks8OMZ0ANBr/j2qkm+Jjg
lBZtyxsg73yt/PDLZuJPnULMJ1QQZoIsJXZcBxLNcYtpCC/0AdH8bl/PdCjAcnUt
RL1BLcWLLqIki90LHx/aPx2UCmhtOv8JWzJ5vgysh89BqNLWFhuJHF615nlSkwQj
UkjcLWmVwT52+00gkD/cWWgueOkTx0Aokb6l3tYckyWk3d4BOshaWQL54haTvqQL
5fz9MQUslawTDjv7igT+
=n/bA
-----END PGP SIGNATURE-----
Merge tag 'for-usb-linus-2012-10-11' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
USB 3.0 Link PM fixes.
Hi Greg,
Here's four fixes for the USB 3.0 Link Power Management code. They
work around some USB 3.0 devices that don't support LPM, like the
Western Digital My Passport hard drive. They also fix an LPM disable
ref count bug that would cause LPM to remain disabled for a device
after a failed probe.
Please queue for 3.7 after the merge window closes. Several patches are
marked for stable.
Sarah Sharp
SEL and PEL are in microseconds, not milliseconds. Also, fix a split
string that will trigger checkpatch warnings.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The Set SEL control transfer tells a device the exit latencies
associated with a device-initated U1 or U2 exit. Since a parent hub may
initiate a transition to U1 soon after a downstream port's U1 timeout is
set, we need to make sure the device receives the Set SEL transfer
before the parent hub timeout is set.
This patch should be backported to kernels as old as 3.5, that contain
the commit 1ea7e0e8e3 "USB: Add support to
enable/disable USB3 link states."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
Some USB 3.0 devices signal that they don't implement Link PM by having
all zeroes in the U1/U2 exit latencies in their SuperSpeed BOS
descriptor. Don found that a Western Digital device he has experiences
transfer errors when LPM is enabled. The lsusb shows the U1/U2 exit
latencies are set to zero:
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 22
bNumDeviceCaps 2
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
Latency Tolerance Messages (LTM) Supported
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 1
Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat 0 micro seconds
bU2DevExitLat 0 micro seconds
The fix is to not enable LPM for a particular link state if we find its
corresponding exit latency is zero.
This patch should be backported to kernels as old as 3.5, that contain
the commit 1ea7e0e8e3 "USB: Add support to
enable/disable USB3 link states."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Don Zickus <dzickus@redhat.com>
Tested-by: Don Zickus <dzickus@redhat.com>
Cc: stable@vger.kernel.org
Before a driver is probed, we want to disable USB 3.0 Link Power
Management (LPM), in case the driver needs hub-initiated LPM disabled.
After the probe finishes, we want to attempt to re-enable LPM, order to
balance the LPM ref count.
When a probe fails (such as when libusual doesn't want to bind to a USB
3.0 mass storage device), make sure to balance the LPM ref counts by
re-enabling LPM.
This patch 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
Pul ACPI & Power Management updates from Len Brown:
- acpidump utility added
- intel_idle driver now supports IVB Xeon
- turbostat utility can now count SMIs
- ACPI can now bind to USB3 hubs
- misc fixes
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: (49 commits)
ACPI: Add new sysfs interface to export device description
ACPI: Harden acpi_table_parse_entries() against BIOS bug
tools/power/turbostat: add option to count SMIs, re-name some options
tools/power turbostat: add [-d MSR#][-D MSR#] options to print counter deltas
intel_idle: enable IVB Xeon support
tools/power turbostat: add [-m MSR#] option
tools/power turbostat: make -M output pretty
tools/power turbostat: print more turbo-limit information
tools/power turbostat: delete unused line
tools/power turbostat: run on IVB Xeon
tools/power/acpi/acpidump: create acpidump(8), local make install targets
tools/power/acpi/acpidump: version 20101221 - find dynamic tables in sysfs
ACPI: run _OSC after ACPI_FULL_INITIALIZATION
tools/power/acpi/acpidump: create acpidump(8), local make install targets
tools/power/acpi/acpidump: version 20101221 - find dynamic tables in sysfs
tools/power/acpi/acpidump: version 20071116
tools/power/acpi/acpidump: version 20070714
tools/power/acpi/acpidump: version 20060606
tools/power/acpi/acpidump: version 20051111
xo15-ebook: convert to module_acpi_driver()
...
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 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>
acpi_get_physical_device_location()'s 2nd argument has been changed
in ACPI implementaion, so need a follow-on change in
usb_acpi_check_pld().
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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>
Greg Kroah-Hartman