This introduces an attribute for each interface to
authorize (1) or deauthorize (0) it:
/sys/bus/usb/devices/INTERFACE/authorized
Signed-off-by: Stefan Koch <skoch@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The kernel supports the device authorization because of wireless USB.
These is usable for wired USB devices, too.
These new interface authorization allows to enable or disable
individual interfaces instead a whole device.
If a deauthorized interface will be authorized so the driver probing must
be triggered manually by writing INTERFACE to /sys/bus/usb/drivers_probe
Signed-off-by: Stefan Koch <skoch@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Driver probings and interface claims get rejected
if an interface is not authorized.
Signed-off-by: Stefan Koch <skoch@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Interfaces are allowed per default.
This can disabled or enabled (again) by writing 0 or 1 to
/sys/bus/usb/devices/usbX/interface_authorized_default
Signed-off-by: Stefan Koch <skoch@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix one occurrence of the checkpatch.pl error:
ERROR: do not use assignment in if condition
The semantic patch that makes this change is:
// <smpl>
@@
identifier i;
expression E, E2, E3;
statement S1, S2;
binary operator b;
@@
+ i = E;
if (
- (i = E)
+ i
b
... && E2 && E3 ) S1 else S2
// </smpl>
Signed-off-by: Kris Borer <kborer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix one occurrence of the checkpatch error:
ERROR: code indent should use tabs where possible
Signed-off-by: Kris Borer <kborer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix one occurrence of the checkpatch error:
ERROR: space prohibited before open square bracket '['
Signed-off-by: Kris Borer <kborer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Removed some checkpatch.pl warnings saying there was an unwanted space between
function names and their arguments.
Signed-off-by: Chase Metzger <chasemetzger15@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix two occurrences of the checkpatch.pl error:
ERROR: space prohibited before that ',' (ctx:WxW)
Fix one occurrence of the checkpatch error:
ERROR: space required before the open parenthesis '('
Signed-off-by: Kris Borer <kborer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix five occurrences of the checkpatch.pl error:
ERROR: do not use assignment in if condition
The semantic patch that makes this change is:
// <smpl>
@@
identifier i;
expression E;
statement S1, S2;
@@
+ i = E;
if (
- (i = E)
+ i
) S1 else S2
@@
identifier i;
expression E;
statement S;
constant c;
binary operator b;
@@
+ i = E;
if (
- (i = E)
+ i
b
c ) S
// </smpl>
Signed-off-by: Kris Borer <kborer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a sysfs node to make it easier to verify if LPM is supported and being
enabled for USB 3.0 devices.
Signed-off-by: Kevin Strasser <kevin.strasser@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix four occurrences of checkpatch.pl error:
ERROR: do not use assignment in if condition
The semantic patch that makes this change is:
// <smpl>
@@
identifier i;
expression E;
statement S;
constant c;
binary operator b;
@@
+ i = E;
if (
- (i = E)
+ i
b
c ) S
@@
identifier i, i2;
expression E1, E2;
constant c;
@@
+ if( E1->i ) {
+ i2 = E2;
+ if (i2 < c) {
- if( E1->i && (i2 = E2) < c ) {
...
- }
+ }
+ }
// </smpl>
Signed-off-by: Kris Borer <kborer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 25cd2882e2 ("usb/xhci: Change how we indicate a host supports
Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
internal field, a.k.a. lpm_capable, and let usb core to set it by
checking U1 and U2 exit latency values in the descriptor.
Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately,
root hub is a special usb device as it has no parent. Hub_port_init()
will never be called for a root hub device. That means lpm_capable will
by no means be set for the root hub. As the result, lpm isn't functional
at all in Linux kernel.
This patch add the code to check and set lpm_capable when registering a
root hub device. It could be back-ported to kernels as old as v3.15,
that contains the Commit 25cd2882e2 ("usb/xhci: Change how we indicate
a host supports Link PM.").
Cc: stable@vger.kernel.org # 3.15
Reported-by: Kevin Strasser <kevin.strasser@linux.intel.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- dwc2 adds hibernation support
- preparation for sunxi glue to musb driver
- new ULPI bus
- new ULPI PHY driver for TUSB1210
- musb patches to support multiple DMA engines on same binary
- support for R-Car E2 on renesas_usbhs
Signed-off-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVaIsMAAoJEIaOsuA1yqREQXQP/2tYG5H2f71mpYAuOKu1KcYi
DnFH5bKgVQZwl+Dafa41B7P40qub7goCULQSmAgErKboHQvzf7GhzbH22jG3cUg+
icowa+pEstXxzcwQGOMVIOZ3jAIQCZFFOizolfAaCHrnYNGwaCKq+5809EdMyXHc
IdYnkYFYdOVGjTPypzoHf8fjpMoCfMx+TLh2ZV4ICj4o5cVXkr9oXNAA8/B/dn+T
MLK02IPmMOVNJs2gYFQSsGYy03YVR+y62jrYXa+bIa1lzYr4v2yx5SymYTcCWMsH
c6szhMxCOoL3CGzONCT52b+ogfpCzefl0HV6yvpAQmRcgbAiRuVt3caq1TBpvMq0
NJVChEfFtOaUR+UGNkBUzh7/CjcVlH8516NQlCIdPemB8HzqBfRMv9MjHsGt1rXC
SHQMQSTOBw2fbdG5zvi06BOO2hCStqXLNCHARJ2Z5YjP7mLrwteO+wYg2FG9zhTp
ShGZlHPqP/U+50WuzorHEpr/pRTJh3LhDlYJ6CBwyd4+vg17PrYYbkf82d9WDEDL
BFH9qe7jfOwZiWHJvNFeHLriKzj/k3i9/DoRaqtm7QwJgafzBz7l+319jvruupnG
8oxhr+gt74uDPIzxWWv+eFOtO+Uu/q8C3dSp0H/0sY4soBELIgf+QtOkwn596rFp
mBLSkru+oEN62IQbTKDK
=Jqzf
-----END PGP SIGNATURE-----
Merge tag 'usb-for-v4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
Felipe writes:
usb: patches for v4.2 merge window
- dwc2 adds hibernation support
- preparation for sunxi glue to musb driver
- new ULPI bus
- new ULPI PHY driver for TUSB1210
- musb patches to support multiple DMA engines on same binary
- support for R-Car E2 on renesas_usbhs
Signed-off-by: Felipe Balbi <balbi@ti.com>
Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.
Dissolve the function hub_port_finish_reset() completely and divide the
actions to be taken into those which need to be done after each reset
attempt and those which need to be done after the full procedure is
complete, and place them in the appropriate places in hub_port_reset().
Also, remove an unneeded forward declaration of hub_port_reset().
Verbose Problem Description:
USB 3.0 devices may be "lost for good" during a hub port reset.
This makes Linux unable to boot from USB 3.0 devices in certain
constellations of host controllers and devices, because the USB device is
lost during initialization, preventing the rootfs from being mounted.
The underlying problem is that in the affected constellations, during the
processing inside hub_port_reset(), the hub link state goes from 0 to
SS.inactive after the initial reset, and back to 0 again only after the
following "warm" reset.
However, hub_port_finish_reset() is called after each reset attempt and
sets the state the connected USB device based on the "preliminary" status
of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
the following warm reset is complete and hub_port_finish_reset() is
called again, its call to set the device to USB_STATE_DEFAULT is blocked
by usb_set_device_state() which does not allow taking USB devices out of
USB_STATE_NOTATTACHED state.
Thanks to Alan Stern for guiding me to the proper solution and how to
submit it.
Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27
Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Static checkers complain that the current condition is never true. It
seems pretty likely that it's a typo and "URB" was intended instead of
"USB".
Fixes: 3d97ff63f8 ('usbdevfs: Use scatter-gather lists for large bulk transfers')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
UTMI+ Low Pin Interface (ULPI) is a commonly used PHY
interface for USB 2.0. The ULPI specification describes a
standard set of registers which the vendors can extend for
their specific needs. ULPI PHYs provide often functions
such as charger detection and ADP sensing and probing.
There are two major issues that the bus type is meant to
tackle:
Firstly, ULPI registers are accessed from the controller.
The bus provides convenient method for the controller
drivers to share that access with the actual PHY drivers.
Secondly, there are already platforms that assume ULPI PHYs
are runtime detected, such as many Intel Baytrail based
platforms. They do not provide any kind of hardware
description for the ULPI PHYs like separate ACPI device
object that could be used to enumerate a device from.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: David Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
We should not be doing assignments within an if () block
so fix up the code to not do this.
change was created using Coccinelle.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
CC: Dan Williams <dan.j.williams@intel.com>
CC: Petr Mladek <pmladek@suse.cz>
CC: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
We should not be doing assignments within an if () block
so fix up the code to not do this.
change was created using Coccinelle.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
CC: Dan Williams <dan.j.williams@intel.com>
CC: Antoine Tenart <antoine.tenart@free-electrons.com>
CC: Petr Mladek <pmladek@suse.cz>
CC: Michal Sojka <sojka@merica.cz>
CC: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
CC: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Fixed two warnings sizeof name and Blank line after declaration
Signed-off-by: Nizam Haider <nizamhaider786@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I've had the same issue as described in commit
c68929f75d
Except my touchscreen's ID is
ID 04f3:0125 Elan Microelectronics Corp.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB 2.01+ full-speed devices can have extended descriptor as well
and can support LPM.
Signed-off-by: Rupesh Tatiya <rtatiya@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Microsoft document "Using ACPI to Configure USB Ports on a Computer"
makes it clear that the removable flag will be cleared on ports that are
marked as unused by the firmware. Handle this case to match.
Signed-off-by: Matthew Garrett <mjg59@coreos.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Windows appears to pay more attention to the ACPI values than any hub
configuration, so prefer the firmware's opinion on whether a port is
fixed or removable before falling back to the hub values.
Signed-off-by: Matthew Garrett <mjg59@coreos.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ran checkpatch.pl on file and removed a warning about an unwanted space before
a tab.
Signed-off-by: Chase Metzger <chasemetzger15@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This part 2 pull request contains only the patches
which make sure everybody on linux uses the same
resume timeout value.
Signed-off-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVJEivAAoJEIaOsuA1yqREV6QP/1oJVdBxzOeQVXyGZsZT4k0E
T8SKmTIJmaCdSjgazSXAhqF7IR992sTM7urHZ2hww3tftODNVHvfFkgDlSguHwkr
GV95YpNv99ash7spjod3xVOt8lDvrt6FHs7Foj4b0yQZ1yXUZsOH4j8G4gMYOgTd
bq1mO2/NaaM7xiddzPMCGpSkL6NcsWrurJ8JiOlBXaUIkSR+Cwe9+8vzEDrxfSM+
6yBTLQCdvR0ammqV0YMNsF9dGLO8yiDotC6b104i3yCqpAZnyj0RJQ3riH7ESxsG
eSKkCXXGY0OWDGDcnWTskYEHJ7iDfg5MrlzBJyneMjauGKNeIoJRRYWP/f6NSV9m
GHxRV1ITKC61Dtt3w+Oy2a16UpAbq7/w1q/SkQl4YtJ8l0P1PUb+TfOZpTOsCLLF
cLXUKJufGWhuGbo+e2m6GizNCsDi5LlfdZcjIjVKRXpyiZI0peqyGj16mTm70UUY
/A9nsLtE7c6bqHMTcFQFRx4d2iHmkilyzQqOvx4ulo1rovNMafgmZJF7Kq0LY7ZO
Uj4s2rEAjqbELbOiEIf8HzGP+J/QuECG4SHyPEQsiG0drYyoCOqGR1S3kV7aJgFz
krl4zTvXR8EOk2IpPa8PDzmMr7YCYzlXOxzmSoJiZhqqpLH7cHYkDiRTmyxn+eB3
lEjEzBA8J9CG4iRIFjk3
=RqsO
-----END PGP SIGNATURE-----
Merge tag 'usb-for-v4.1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-testing
Felipe writes:
usb: generic resume timeout for v4.1
This part 2 pull request contains only the patches
which make sure everybody on linux uses the same
resume timeout value.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
Move usb_disabled() and module_param()/core_param() towards the top of the file,
where 'nousb' is defined, as they are all related.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
At few places we have used usb_disabled() and at other places used 'nousb'
directly. Lets be consistent and use usb_disabled();
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a signal is delivered, the information in the siginfo structure
is copied to userspace. Good security practice dicatates that the
unused fields in this structure should be initialized to 0 so that
random kernel stack data isn't exposed to the user. This patch adds
such an initialization to the two places where usbfs raises signals.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Dave Mielke <dave@mielke.cc>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here's the big pull request for the USB driver tree for 3.20-rc1.
Nothing major happening here, just lots of gadget driver updates, new
device ids, and a bunch of cleanups.
All of these have been in linux-next for a while with no reported
issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlTgtrcACgkQMUfUDdst+yn0tACgygJPNvu1l3ukNJCCpWuOErIj
3KsAnjiEXv90DLYJiVLJ4EbLPw0V9wAv
=DrJx
-----END PGP SIGNATURE-----
Merge tag 'usb-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB patches from Greg KH:
"Here's the big pull request for the USB driver tree for 3.20-rc1.
Nothing major happening here, just lots of gadget driver updates, new
device ids, and a bunch of cleanups.
All of these have been in linux-next for a while with no reported
issues"
* tag 'usb-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (299 commits)
usb: musb: fix device hotplug behind hub
usb: dwc2: Fix a bug in reading the endpoint directions from reg.
staging: emxx_udc: fix the build error
usb: Retry port status check on resume to work around RH bugs
Revert "usb: Reset USB-3 devices on USB-3 link bounce"
uhci-hub: use HUB_CHAR_*
usb: kconfig: replace PPC_OF with PPC
ehci-pci: disable for Intel MID platforms (update)
usb: gadget: Kconfig: use bool instead of boolean
usb: musb: blackfin: remove incorrect __exit_p()
USB: fix use-after-free bug in usb_hcd_unlink_urb()
ehci-pci: disable for Intel MID platforms
usb: host: pci_quirks: joing string literals
USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)
USB: usbfs: allow URBs to be reaped after disconnection
cdc-acm: kill unnecessary messages
cdc-acm: add sanity checks
usb: phy: phy-generic: Fix USB PHY gpio reset
usb: dwc2: fix USB core dependencies
usb: renesas_usbhs: fix NULL pointer dereference in dma_release_channel()
...
In commit ceb6c9c862 ("USB / PM: Drop CONFIG_PM_RUNTIME from the
USB core"), all occurrences of CONFIG_PM_RUNTIME in the USB core
code were replaced by CONFIG_PM. This created the following structure
of #ifdef blocks in drivers/usb/core/hub.c:
[...]
#ifdef CONFIG_PM
#ifdef CONFIG_PM
/* always on / undead */
#else
/* dead */
#endif
[...]
This patch removes unnecessary inner "#ifdef CONFIG_PM" as well as
the corresponding dead #else block. This inconsistency was found using
the undertaker-checkpatch tool.
Signed-off-by: Andreas Ruprecht <rupran@einserver.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The EHCI controller on the RK3288 SoC is violating basic parts of the
USB spec and thereby unable to properly resume a suspended port. It does
not start SOF generation within 3ms of finishing resume signaling, so
the attached device will drop of the bus again. This is a particular
problem with runtime PM, where accessing the device will trigger a
resume that immediately makes it unavailable (and reenumerate with a new
handle).
Thankfully, the persist feature is generally able to work around stuff
like that. Unfortunately, it doesn't quite work in this particular case
because the controller will turn off the CurrentConnectStatus bit for an
instant while the device is reconnecting, which causes the kernel to
conclude that it permanently disappeared. This patch adds a tiny retry
mechanism to the core port resume code which will catch this case and
shouldn't have any notable impact on other controllers.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This revert a82b76f7fa.
The commit causes an extra reset in remote wakeup as described in:
http://www.spinics.net/lists/linux-usb/msg119080.html
Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_hcd_unlink_urb() routine in hcd.c contains two possible
use-after-free errors. The dev_dbg() statement at the end of the
routine dereferences urb and urb->dev even though both structures may
have been deallocated.
This patch fixes the problem by storing urb->dev in a local variable
(avoiding the dereference of urb) and moving the dev_dbg() up before
the usb_put_dev() call.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Currently the USB stack assumes that all host controller drivers are
capable of receiving wakeup requests from downstream devices.
However, this isn't true for the isp1760-hcd driver, which means that
it isn't safe to do a runtime suspend of any device attached to a
root-hub port if the device requires wakeup.
This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure
and sets the flag in isp1760-hcd. The core is modified to prevent a
direct child of the root hub from being put into runtime suspend with
wakeup enabled if the flag is set.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Nicolas Pitre <nico@linaro.org>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
The usbfs API has a peculiar hole: Users are not allowed to reap their
URBs after the device has been disconnected. There doesn't seem to be
any good reason for this; it is an ad-hoc inconsistency.
The patch allows users to issue the USBDEVFS_REAPURB and
USBDEVFS_REAPURBNDELAY ioctls (together with their 32-bit counterparts
on 64-bit systems) even after the device is gone. If no URBs are
pending for a disconnected device then the ioctls will return -ENODEV
rather than -EAGAIN, because obviously no new URBs will ever be able
to complete.
The patch also adds a new capability flag for
USBDEVFS_GET_CAPABILITIES to indicate that the reap-after-disconnect
feature is supported.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Chris Dickens <christopher.a.dickens@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
OTG device shall support this device for allowing compliance automated testing.
The modification is derived from Pavankumar and Vijayavardhans' previous work.
Signed-off-by: Macpaul Lin <macpaul@gmail.com>
Cc: Pavankumar Kondeti <pkondeti@codeaurora.org>
Cc: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently if port power is turned off by user on hub port
using USBDEVFS then port power is turned back ON
by hub driver.
This commit modifies hub reset logic in hub_port_connect() to prevent
hub driver from turning back the port power ON if port is not owned
by kernel.
Signed-off-by: Deepak Das <deepakdas.linux@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USB stack provides a mechanism for drivers to request an
asynchronous device reset (usb_queue_reset_device()). The mechanism
uses a work item (reset_ws) embedded in the usb_interface structure
used by the driver, and the reset is carried out by a work queue
routine.
The asynchronous reset can race with driver unbinding. When this
happens, we try to cancel the queued reset before unbinding the
driver, on the theory that the driver won't care about any resets once
it is unbound.
However, thanks to the fact that lockdep now tracks work queue
accesses, this can provoke a lockdep warning in situations where the
device reset causes another interface's driver to be unbound; see
http://marc.info/?l=linux-usb&m=141893165203776&w=2
for an example. The reason is that the work routine for reset_ws in
one interface calls cancel_queued_work() for the reset_ws in another
interface. Lockdep thinks this might lead to a work routine trying to
cancel itself. The simplest solution is not to cancel queued resets
when unbinding drivers.
This means we now need to acquire a reference to the usb_interface
when queuing a reset_ws work item and to drop the reference when the
work routine finishes. We also need to make sure that the
usb_interface structure doesn't outlive its parent usb_device; this
means acquiring and dropping a reference when the interface is created
and destroyed.
In addition, cancelling a queued reset can fail (if the device is in
the middle of an earlier reset), and this can cause usb_reset_device()
to try to rebind an interface that has been deallocated (see
http://marc.info/?l=linux-usb&m=142175717016628&w=2 for details).
Acquiring the extra references prevents this failure.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
Reported-by: Olivier Sobrie <olivier@sobrie.be>
Tested-by: Olivier Sobrie <olivier@sobrie.be>
Cc: stable <stable@vger.kernel.org> # 3.19
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
the following error pops up during "testusb -a -t 10"
| musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128, f134e000/be842000 (bad dma)
hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
might by identified by buffer_offset() as another buffer. This means the
buffer which is on a 32 byte boundary will not get freed, instead it
tries to free another buffer with the error message.
This patch fixes the issue by creating the smallest DMA buffer with the
size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is
smaller). This might be 32, 64 or even 128 bytes. The next three pools
will have the size 128, 512 and 2048.
In case the smallest pool is 128 bytes then we have only three pools
instead of four (and zero the first entry in the array).
The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
we would end up with 8KiB buffer in case we have 16KiB pages.
Instead I think it makes sense to have a common size(s) and extend them
if there is need to.
There is a BUILD_BUG_ON() now in case someone has a minalign of more than
128 bytes.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Fix a regression in leds-gpio introduced by a recent commit that
inadvertently changed the name of one of the properties used by
the driver (Fabio Estevam).
- Fix a regression in the ACPI backlight driver introduced by a
recent fix that missed one special case that had to be taken
into account (Aaron Lu).
- Drop the level of some new kernel messages from the ACPI core
introduced by a recent commit to KERN_DEBUG which they should
have used from the start and drop some other unuseful KERN_ERR
messages printed by ACPI (Rafael J Wysocki).
- Revert an incorrect commit modifying the cpupower tool
(Prarit Bhargava).
- Fix two regressions introduced by recent commits in the OPP
library and clean up some existing minor issues in that code
(Viresh Kumar).
- Continue to replace CONFIG_PM_RUNTIME with CONFIG_PM throughout
the tree (or drop it where that can be done) in order to make
it possible to eliminate CONFIG_PM_RUNTIME (Rafael J Wysocki,
Ulf Hansson, Ludovic Desroches). There will be one more
"CONFIG_PM_RUNTIME removal" batch after this one, because some
new uses of it have been introduced during the current merge
window, but that should be sufficient to finally get rid of it.
- Make the ACPI EC driver more robust against race conditions
related to GPE handler installation failures (Lv Zheng).
- Prevent the ACPI device PM core code from attempting to
disable GPEs that it has not enabled which confuses ACPICA
and makes it report errors unnecessarily (Rafael J Wysocki).
- Add a "force" command line switch to the intel_pstate driver
to make it possible to override the blacklisting of some
systems in that driver if needed (Ethan Zhao).
- Improve intel_pstate code documentation and add a MAINTAINERS
entry for it (Kristen Carlson Accardi).
- Make the ACPI fan driver create cooling device interfaces
witn names that reflect the IDs of the ACPI device objects
they are associated with, except for "generic" ACPI fans
(PNP ID "PNP0C0B"). That's necessary for user space thermal
management tools to be able to connect the fans with the
parts of the system they are supposed to be cooling properly.
From Srinivas Pandruvada.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJUk0IDAAoJEILEb/54YlRx7fgP/3+yF/0TnEW93j2ALDAQFiLF
tSv2A2vQC8vtMJjjWx0z/HqPh86gfaReEFZmUJD/Q/e2LXEnxNZJ+QMjcekPVkDM
mTvcIMc2MR8vOA/oMkgxeaKregrrx7RkCfojd+NWZhVukkjl+mvBHgAnYjXRL+NZ
unDWGlbHG97vq/3kGjPYhDS00nxHblw8NHFBu5HL5RxwABdWoeZJITwqxXWyuPLw
nlqNWlOxmwvtSbw2VMKz0uof1nFHyQLykYsMG0ZsyayCRdWUZYkEqmE7GGpCLkLu
D6yfmlpen6ccIOsEAae0eXBt50IFY9Tihk5lovx1mZmci2SNRg29BqMI105wIn0u
8b8Ej7MNHp7yMxRpB5WfU90p/y7ioJns9guFZxY0CKaRnrI2+BLt3RscMi3MPI06
Cu2/WkSSa09fhDPA+pk+VDYsmWgyVawigesNmMP5/cvYO/yYywVRjOuO1k77qQGp
4dSpFYEHfpxinejZnVZOk2V9MkvSLoSMux6wPV0xM0IE1iD0ulVpHjTJrwp80ph4
+bfUFVr/vrD1y7EKbf1PD363ZKvJhWhvQWDgETsM1vgLf21PfWO7C2kflIAsWsdQ
1ukD5nCBRlP4K73hG7bdM6kRztXhUdR0SHg85/t0KB/ExiVqtcXIzB60D0G1lENd
QlKbq3O4lim1WGuhazQY
=5fo2
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull more ACPI and power management updates from Rafael Wysocki:
"These are regression fixes (leds-gpio, ACPI backlight driver,
operating performance points library, ACPI device enumeration
messages, cpupower tool), other bug fixes (ACPI EC driver, ACPI device
PM), some cleanups in the operating performance points (OPP)
framework, continuation of CONFIG_PM_RUNTIME elimination, a couple of
minor intel_pstate driver changes, a new MAINTAINERS entry for it and
an ACPI fan driver change needed for better support of thermal
management in user space.
Specifics:
- Fix a regression in leds-gpio introduced by a recent commit that
inadvertently changed the name of one of the properties used by the
driver (Fabio Estevam).
- Fix a regression in the ACPI backlight driver introduced by a
recent fix that missed one special case that had to be taken into
account (Aaron Lu).
- Drop the level of some new kernel messages from the ACPI core
introduced by a recent commit to KERN_DEBUG which they should have
used from the start and drop some other unuseful KERN_ERR messages
printed by ACPI (Rafael J Wysocki).
- Revert an incorrect commit modifying the cpupower tool (Prarit
Bhargava).
- Fix two regressions introduced by recent commits in the OPP library
and clean up some existing minor issues in that code (Viresh
Kumar).
- Continue to replace CONFIG_PM_RUNTIME with CONFIG_PM throughout the
tree (or drop it where that can be done) in order to make it
possible to eliminate CONFIG_PM_RUNTIME (Rafael J Wysocki, Ulf
Hansson, Ludovic Desroches).
There will be one more "CONFIG_PM_RUNTIME removal" batch after this
one, because some new uses of it have been introduced during the
current merge window, but that should be sufficient to finally get
rid of it.
- Make the ACPI EC driver more robust against race conditions related
to GPE handler installation failures (Lv Zheng).
- Prevent the ACPI device PM core code from attempting to disable
GPEs that it has not enabled which confuses ACPICA and makes it
report errors unnecessarily (Rafael J Wysocki).
- Add a "force" command line switch to the intel_pstate driver to
make it possible to override the blacklisting of some systems in
that driver if needed (Ethan Zhao).
- Improve intel_pstate code documentation and add a MAINTAINERS entry
for it (Kristen Carlson Accardi).
- Make the ACPI fan driver create cooling device interfaces witn
names that reflect the IDs of the ACPI device objects they are
associated with, except for "generic" ACPI fans (PNP ID "PNP0C0B").
That's necessary for user space thermal management tools to be able
to connect the fans with the parts of the system they are supposed
to be cooling properly. From Srinivas Pandruvada"
* tag 'pm+acpi-3.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (32 commits)
MAINTAINERS: add entry for intel_pstate
ACPI / video: update the skip case for acpi_video_device_in_dod()
power / PM: Eliminate CONFIG_PM_RUNTIME
NFC / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
SCSI / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
ACPI / EC: Fix unexpected ec_remove_handlers() invocations
Revert "tools: cpupower: fix return checks for sysfs_get_idlestate_count()"
tracing / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
x86 / PM: Replace CONFIG_PM_RUNTIME in io_apic.c
PM: Remove the SET_PM_RUNTIME_PM_OPS() macro
mmc: atmel-mci: use SET_RUNTIME_PM_OPS() macro
PM / Kconfig: Replace PM_RUNTIME with PM in dependencies
ARM / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
sound / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
phy / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
video / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
tty / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
spi: Replace CONFIG_PM_RUNTIME with CONFIG_PM
ACPI / PM: Do not disable wakeup GPEs that have not been enabled
ACPI / utils: Drop error messages from acpi_evaluate_reference()
...
Here's the big set of USB and PHY patches for 3.19-rc1.
The normal churn in the USB gadget area is in here, as well as xhci and
other individual USB driver updates. The PHY tree is also in here, as
there were dependancies on the USB tree.
All of these have been in linux-next.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlSOEHcACgkQMUfUDdst+ykziQCgsm1D/af2nac6CTF2pov8VMIY
ywgAnRi8LtZ2WassrwTNxY86Avaqryis
=UVp8
-----END PGP SIGNATURE-----
Merge tag 'usb-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB updates from Greg KH:
"Here's the big set of USB and PHY patches for 3.19-rc1.
The normal churn in the USB gadget area is in here, as well as xhci
and other individual USB driver updates. The PHY tree is also in
here, as there were dependancies on the USB tree.
All of these have been in linux-next"
* tag 'usb-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (351 commits)
arm: omap3: twl: remove usb phy init data
usbip: fix error handling in stub_probe()
usb: gadget: udc: missing curly braces
USB: mos7720: delete some unneeded code
wusb: replace memset by memzero_explicit
usbip: remove unneeded structure
usb: xhci: fix comment for PORT_DEV_REMOVE
xhci: don't use the same variable for stopped and halted rings current TD
xhci: clear extra bits from slot context when setting max exit latency
xhci: cleanup finish_td function
USB: adutux: NULL dereferences on disconnect
usb: chipidea: fix platform_no_drv_owner.cocci warnings
usb: chipidea: Fixed a few typos in comments
Documentation: bindings: add doc for the USB2 ChipIdea USB driver
usb: chipidea: add a usb2 driver for ci13xxx
usb: chipidea: fix phy handling
usb: chipidea: remove duplicate dev_set_drvdata for host_start
usb: chipidea: parameter 'mode' isn't needed for hw_device_reset
usb: chipidea: add controller reset API
usb: chipidea: remove flag CI_HDRC_REQUIRE_TRANSCEIVER
...
After commit b2b49ccbdd (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so Kconfig options
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
Replace PM_RUNTIME with PM in Kconfig dependencies throughout the
tree.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Tejun Heo <tj@kernel.org>
Pull HID updates from Jiri Kosina:
- i2c-hid race condition fix from Jean-Baptiste Maneyrol
- Logitech driver now supports vendor-specific HID++ protocol, allowing
us to deliver a full multitouch support on wider range of Logitech
touchpads. Written by Benjamin Tissoires
- MS Surface Pro 3 Type Cover support added by Alan Wu
- RMI touchpad support improvements from Andrew Duggan
- a lot of updates to Wacom driver from Jason Gerecke and Ping Cheng
- various small fixes all over the place
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (56 commits)
HID: rmi: The address of query8 must be calculated based on which query registers are present
HID: rmi: Check for additional ACM registers appended to F11 data report
HID: i2c-hid: prevent buffer overflow in early IRQ
HID: logitech-hidpp: disable io in probe error path
HID: logitech-hidpp: add boundary check for name retrieval
HID: logitech-hidpp: check name retrieval return code
HID: logitech-hidpp: do not return the name length
HID: wacom: Report input events for each finger on generic devices
HID: wacom: Initialize MT slots for generic devices at post_parse_hid
HID: wacom: Update maximum X/Y accounding to outbound offset
HID: wacom: Add support for DTU-1031X
HID: wacom: add defines for new Cintiq and DTU outbound tracking
HID: wacom: fix freeze on open when autosuspend is on
HID: wacom: re-add accidentally dropped Lenovo PID
HID: make hid_report_len as a static inline function in hid.h
HID: wacom: Consult the application usage when determining field type
HID: wacom: PAD is independent with pen/touch
HID: multitouch: Add quirk for VTL touch panels
HID: i2c-hid: fix race condition reading reports
HID: wacom: Add angular resolution data to some ABS axes
...
After commit b2b49ccbdd (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so quite a few
depend on CONFIG_PM (or even dropped in some cases).
Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code
and documentation.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This time, a very pull request with 216 non-merge
commits. Most of the commits contained here are
sparse or coccinelle fixes ranging from missing
'static' to returning 0 in case of errors.
More importantly, we have the removal the now
unnecessary 'driver' argument to ->udc_stop().
DWC2 learned about Dual-Role builds. Users of
this IP can now have a single driver built for
host and device roles.
DWC3 got support for two new HW platforms: Exynos7
and AMD.
The Broadcom USB 3.0 Device Controller IP is now
supported and so is PLX USB338x, which means DWC3
has lost is badge as the only USB 3.0 peripheral
IP supported on Linux.
Thanks for Tony Lindgren's work, we can now have
a distro-like kernel where all MUSB glue layers
can be built into the same kernel (statically
or dynamically linked) and it'll work in PIO (DMA
will come probably on v3.20).
Other than these, the usual set of cleanups and
non-critical fixes.
Signed-off-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUdJoNAAoJEIaOsuA1yqREqDoP/iwVojhk1qb2PQAJvLkl8To4
R34RM8zt8IRhE+yWIW8hm8xvsLiwvujBMgsphUmyu2k0X/NtPl1ElrDvObWwO0N8
ouyLISRw/wLUs8hJwsNVhIX0VjPxDQ6648C3OZYjySTtNtsh0rBw84ALX+IWkDye
Thb823xEunGYVwjhq8WrfT94q6LjyPp00XHlA4mf3XgSpXC2tKBFGmIcfmwObzYI
LkON7kJTp14XEeIYGYJO+7MBpo8s7YFmnpsDOV2QYlz/i0pRdjLwaKMN5T7D7DO5
YdvcQFQUM53dvq+tiw2k2iW4gmn9ktHHlckn8W5hhQZCs4ujSzYy/vP4GcbNEaTf
CuDocJGTr7ieU2IqYiTM+wRYavBoHLq9V5AHZmgsZ/pVF8lvG0hcX0fmd7XXScjv
GaKJqyQMaKZ9tRF9RZdMZeOrICp1X1X+KcqdG7yXoOtsVdn0O3zHdxYcZcVa29X/
cXuttoTywQgfrlI/uWWwpkYlqiHeawK1EooZ/6fYQDviLm4lrLPp94vF/5MqGM1j
f2tNpG63iOzLUUYJa+YgPqs6RrZLM3soZcf3bFAEt9sA99gc3ExwCYXurBEnTONr
XUowTfNKxPaVjNPZ1evGwF5F+WLEK4s88weB9lArd2S3NFP3DQV1cRpWj8rLYE72
lX6aWEWUDqnUHmwJUgIb
=WYyZ
-----END PGP SIGNATURE-----
Merge tag 'usb-for-v3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
Felipe writes:
usb: patches for v3.19 merge window
This time, a very pull request with 216 non-merge
commits. Most of the commits contained here are
sparse or coccinelle fixes ranging from missing
'static' to returning 0 in case of errors.
More importantly, we have the removal the now
unnecessary 'driver' argument to ->udc_stop().
DWC2 learned about Dual-Role builds. Users of
this IP can now have a single driver built for
host and device roles.
DWC3 got support for two new HW platforms: Exynos7
and AMD.
The Broadcom USB 3.0 Device Controller IP is now
supported and so is PLX USB338x, which means DWC3
has lost is badge as the only USB 3.0 peripheral
IP supported on Linux.
Thanks for Tony Lindgren's work, we can now have
a distro-like kernel where all MUSB glue layers
can be built into the same kernel (statically
or dynamically linked) and it'll work in PIO (DMA
will come probably on v3.20).
Other than these, the usual set of cleanups and
non-critical fixes.
Signed-off-by: Felipe Balbi <balbi@ti.com>
This wireless mouse receiver needs a reset-resume quirk to properly come
out of reset.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1165206
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The touchscreen needs the same quirk as the other models.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Reported-by: Bryan Poling <poli0048@umn.edu>
CC: stable@vger.kernel.org
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
It is safe to call notify disconnect when the usb core
thinks the device is disconnected.
This commit also fixes one bug found at below situation:
we have not enabled usb wakeup, we do system suspend when
there is an usb device at the port, after suspend, we plug out
the usb device, then plug in device again. At that time,
the nofity disconnect was not called at current code, as
the controller doesn't know the usb device was disconnected
during the suspend, but USB core knows the port has changed
during that periods.
So to fix this problem, and let the usb core call notify disconnect.
Cc: 3.17+ <stable@vger.kernel.org>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since we notify disconnecting based on the usb device is existed
(port_dev->child, the child device at roothub is not NULL), we
need to notify connect after device has been registered.
This fixes a bug that do fast plug in/out test, and the notify_disconnect
is not called due to roothub child is NULL and the enumeration has failed.
Cc: v3.17+ <stable@vger.kernel.org>
Signed-off-by: Tony Zheng <Tony.Zheng@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
the integer variable 'feature' was not being used anywhere in the function.
so it is safe to remove the variable.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch modifies the usb_authorize_device() function such as that it does
not reload the device descriptor for wired devices. The reasons for this
are as follows:
* Some devices dislike the master requesting the descriptor from them twice,
failing on the usb_get_device_descriptor() call with -ETIMEOUT. Observed this
on my Pretec 16GB flash drive (4146:ba65).
* Malicious device could send two different descriptors - one before
authorization, used by userspace to determine whether to authorize it and
second to be actually used by the kernel when determining which drivers to
bind.
Signed-off-by: Josef Gajdusek <atx@atx.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently this quirk is enabled for the model with the device id 0x0089, it
is needed for the 0x009b model, which is found on the Fujitsu Lifebook u904
as well.
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit fixes the following oops:
[10238.622067] scsi host3: uas_eh_bus_reset_handler start
[10240.766164] usb 3-4: reset SuperSpeed USB device number 3 using xhci_hcd
[10245.779365] usb 3-4: device descriptor read/8, error -110
[10245.883331] usb 3-4: reset SuperSpeed USB device number 3 using xhci_hcd
[10250.897603] usb 3-4: device descriptor read/8, error -110
[10251.058200] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
[10251.058244] IP: [<ffffffff815ac6e1>] xhci_check_streams_endpoint+0x91/0x140
<snip>
[10251.059473] Call Trace:
[10251.059487] [<ffffffff815aca6c>] xhci_calculate_streams_and_bitmask+0xbc/0x130
[10251.059520] [<ffffffff815aeb5f>] xhci_alloc_streams+0x10f/0x5a0
[10251.059548] [<ffffffff810a4685>] ? check_preempt_curr+0x75/0xa0
[10251.059575] [<ffffffff810a46dc>] ? ttwu_do_wakeup+0x2c/0x100
[10251.059601] [<ffffffff810a49e6>] ? ttwu_do_activate.constprop.111+0x66/0x70
[10251.059635] [<ffffffff815779ab>] usb_alloc_streams+0xab/0xf0
[10251.059662] [<ffffffffc0616b48>] uas_configure_endpoints+0x128/0x150 [uas]
[10251.059694] [<ffffffffc0616bac>] uas_post_reset+0x3c/0xb0 [uas]
[10251.059722] [<ffffffff815727d9>] usb_reset_device+0x1b9/0x2a0
[10251.059749] [<ffffffffc0616f42>] uas_eh_bus_reset_handler+0xb2/0x190 [uas]
[10251.059781] [<ffffffff81514293>] scsi_try_bus_reset+0x53/0x110
[10251.059808] [<ffffffff815163b7>] scsi_eh_bus_reset+0xf7/0x270
<snip>
The problem is the following call sequence (simplified):
1) usb_reset_device
2) usb_reset_and_verify_device
2) hub_port_init
3) hub_port_finish_reset
3) xhci_discover_or_reset_device
This frees xhci->devs[slot_id]->eps[ep_index].ring for all eps but 0
4) usb_get_device_descriptor
This fails
5) hub_port_init fails
6) usb_reset_and_verify_device fails, does not restore device config
7) uas_post_reset
8) xhci_alloc_streams
NULL deref on the free-ed ring
This commit fixes this by not allowing usb_alloc_streams to continue if
the device is not configured.
Note that we do allow usb_free_streams to continue after a (logical)
disconnect, as it is necessary to explicitly free the streams at the xhci
controller level.
Cc: stable@vger.kernel.org
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 modify the generic code handling PHYs to allow them to be
supplied from the drivers. This adds checks to ensure no PHY was already
there when looking for one in the generic code. This also makes sure we
do not modify its state in the generic HCD functions, it was provided by
the driver.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Add the generic PHY support, analogous to the USB PHY support. Intended it to be
used with the PCI EHCI/OHCI drivers and the xHCI platform driver.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
This is in preparation to adding the generic PHY support.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
[Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects,
updated changelog.]
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The current code only returns -ENOTSUPP for OTG host, but in fact,
embedded host also needs to returns -ENOTSUPP if the peripheral
is not at TPL.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 0cce2eda19
USB: fix LANGID=0 regression
defaults to a langid of 0x0409 if it's not properly implemented by the
device. Explain with a higher level error message what this means.
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With this patch, USB activity can be signaled by blinking a LED. There
are two triggers, one for activity on USB host and one for USB gadget.
Both triggers should work with all host/device controllers. Tested only
with musb.
Performace: I measured performance overheads on ARM Cortex-A8 (TI
AM335x) running on 600 MHz.
Duration of usb_led_activity():
- with no LED attached to the trigger: 2 ± 1 µs
- with one GPIO LED attached to the trigger: 2 ± 1 µs or 8 ± 2 µs (two peaks in histogram)
Duration of functions calling usb_led_activity() (with this patch
applied and no LED attached to the trigger):
- __usb_hcd_giveback_urb(): 10 - 25 µs
- usb_gadget_giveback_request(): 2 - 6 µs
Signed-off-by: Michal Sojka <sojka@merica.cz>
Acked-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It seems that only choose_devnum() was not ready to process more hub
events at the same time.
All should be fine if we take bus->usb_address0_mutex there. It will
make sure that more devnums will not be chosen for the given bus and
the related devices at the same time.
Signed-off-by: Petr Mladek <pmladek@suse.cz>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB hub has started to use a workqueue instead of kthread. Let's update
the documentation and comments here and there.
This patch mostly just replaces "khubd" with "hub_wq". There are only few
exceptions where the whole sentence was updated. These more complicated
changes can be found in the following files:
Documentation/usb/hotplug.txt
drivers/net/usb/usbnet.c
drivers/usb/core/hcd.c
drivers/usb/host/ohci-hcd.c
drivers/usb/host/xhci.c
Signed-off-by: Petr Mladek <pmladek@suse.cz>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB hub started to use a workqueue instead of kthread. Let's make it clear from
the function names.
Signed-off-by: Petr Mladek <pmladek@suse.cz>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is no need to have separate kthread for handling USB hub events.
It is more elegant to use the workqueue framework.
The workqueue is allocated as freezable because the original thread was
freezable as well.
Also it is allocated as ordered because the code is not ready for parallel
processing of hub events, see choose_devnum().
struct usb_hub is passed via the work item. Therefore we do not need
hub_event_list.
Also hub_thread() is not longer needed. It would call only hub_event().
The rest of the code did manipulate the kthread and it is handled by the
workqueue framework now.
kick_khubd is renamed to kick_hub_wq() to make the function clear. And the
protection against races is done another way, see below.
hub_event_lock has been removed. It cannot longer be used to protect struct
usb_hub between hub_event() and hub_disconnect(). Instead we need to get
hub->kref already in kick_hub_wq().
The lock is not really needed for the other scenarios as well. queue_work()
returns whether it succeeded. We could revert the needed operations
accordingly. This is enough to avoid duplicity and inconsistencies.
Yes, the removed lock causes that there is not longer such a strong
synchronization between scheduling the work and manipulating
hub->disconnected.
But kick_hub_wq() must never be called together with hub_disconnect()
otherwise even the original code would have failed. Any callers are
responsible for this.
Therefore the only problem is that hub_disconnect() could be called in parallel
with hub_event(). But this was possible even in the past. struct usb_hub is
still guarded by hub->kref and released in hub_events() when needed.
Note that the source file is still full of the obsolete "khubd" strings.
Let's remove them in a follow up patch. This patch already is complex enough.
Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful
tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to
allocate the workqueue.
Signed-off-by: Petr Mladek <pmladek@suse.cz>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We would like to convert khubd kthread to a workqueue. As a result hub_events()
will handle only one event per call.
In fact, we could do this already now because there is another cycle in
hub_thread(). It calls hub_events() until hub_event_list is empty.
This patch renames the function to hub_event(), removes the while cycle, and
renames the goto targets from loop* to out*.
When touching the code, it fixes also formatting of dev_err() and dev_dbg()
calls to make checkpatch.pl happy :-)
Signed-off-by: Petr Mladek <pmladek@suse.cz>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is just a small optimization of the fix from the commit c605f3cdff
("usb: hub: take hub->hdev reference when processing from eventlist).
We do not need to take the reference for each event. Instead we could get it
when struct usb_hub is allocated and put it when it is released. By other words,
we could handle it the same way as the reference for hub->intfdev.
The motivation is that it will make the life easier when switching from khubd
kthread to a workqueue.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Petr Mladek <pmladek@suse.cz>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This full-speed USB device generates spurious remote wakeup event
as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result,
Linux can't enter system suspend and S0ix power saving modes once
this keyboard is used.
This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk.
With this quirk set, wakeup capability will be ignored during
device configure.
This patch could be back-ported to kernels as old as 2.6.39.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixed typos in comments of various drivers/usb files
Signed-off-by: Mickael Maison <mickael.maison@gmail.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Update configuration for USB_OTG_WHITELIST, any targeted hosts
(non PC-hosts) can have TPL (Targered Peripheral List).
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
According to On-The-Go and Embedded Host Supplement to the USB Revision
2.0 Specification, the targeted hosts (non-PC hosts) include both
embedded hosts and otg, and each targeted host product defines the
set of supported peripherals on a TPL (Targeted Peripheral List). So,
TPL should apply for both OTG and embedded host, and the otg support is
not a must for embedded host.
The TPL support feature will only be effect when CONFIG_USB_OTG_WHITELIST
has been chosen and hcd->tpl_support flag is set, it can avoid the enumeration
fails problem for the user who chooses CONFIG_USB_OTG_WHITELIST wrongly.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enable device-qualifier quirk for Elan Touchscreen, which often fails to
handle requests for the device_descriptor.
Note that the device sometimes do respond properly with a Request Error
(three times as USB core retries), but usually fails to respond at all.
When this happens any further descriptor requests also fails, for
example:
[ 1528.688934] usb 2-7: new full-speed USB device number 4 using xhci_hcd
[ 1530.945588] usb 2-7: unable to read config index 0 descriptor/start: -71
[ 1530.945592] usb 2-7: can't read configurations, error -71
This has been observed repeating for over a minute before eventual
successful enumeration.
Reported-by: Drew Von Spreecken <drewvs@gmail.com>
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add new quirk for devices that cannot handle requests for the
device_qualifier descriptor.
A USB-2.0 compliant device must respond to requests for the
device_qualifier descriptor (even if it's with a request error), but at
least one device is known to misbehave after such a request.
Suggested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
During surprise device hotplug removal tests, it was observed that
hub_events may try to call usb_lock_device on a device that has already
been freed. Protect the usb_device by taking out a reference (under the
hub_event_lock) when hub_events pulls it off the list, returning the
reference after hub_events is finished using it.
Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
Suggested-by: David Bulkow <david.bulkow@stratus.com> for using kref
Suggested-by: Alan Stern <stern@rowland.harvard.edu> for placement
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bdd405d2a5 ("usb: hub: Prevent hub autosuspend if
usbcore.autosuspend is -1") causes a build error if CONFIG_PM_RUNTIME is
disabled. Fix that by doing a simple #ifdef guard around it.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Michael Welling <mwelling@emacinc.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If user specifies that USB autosuspend must be disabled by module
parameter "usbcore.autosuspend=-1" then we must prevent
autosuspend of USB hub devices as well.
commit 596d789a21 introduced in v3.8 changed the original behaivour
and stopped respecting the usbcore.autosuspend parameter for hubs.
Fixes: 596d789a21 "USB: set hub's default autosuspend delay as 0"
Cc: [3.8+] <stable@vger.kernel.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Tested-by: Michael Welling <mwelling@emacinc.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
linux-2.6/drivers/usb/core/hub.c: In function 'usb_disconnect':
linux-2.6/drivers/usb/core/hub.c:2110: warning: 'hub' may be used uninitialized in this function
linux-2.6/drivers/usb/core/hub.c:2111: warning: 'port1' may be used uninitialized in this function
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit [5ee0f803cc3a: usbcore: don't log on consecutive debounce
failures of the same port] added the check of the reliable port, but
it also replaced the device argument to dev_err() wrongly, which leads
to a NULL dereference.
This patch restores the right device, port_dev->dev. Also, since
dev_err() itself shows the port number, reduce the port number shown
in the error message, essentially reverting to the state before the
commit 5ee0f803cc.
[The fix suggested by Hannes, and the error message cleanup suggested
by Alan Stern]
Fixes: 5ee0f803cc ('usbcore: don't log on consecutive debounce failures of the same port')
Reported-by: Hannes Reinecke <hare@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here is the big USB driver update for 3.17-rc1.
Loads of gadget driver changes in here, including some big file
movements to make things easier to manage over time. There's also the
usual xhci and uas driver updates, and a handful of other changes in
here. The changelog has the full details.
All of these have been in linux-next for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlPf2ZIACgkQMUfUDdst+ylvQwCfQKPKcwhtq4vJ2imUzJROEZwN
ygYAnRpFpH/19X59uGSdE7DAdhbitqKg
=uPh1
-----END PGP SIGNATURE-----
Merge tag 'usb-3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB updates from Greg KH:
"Here is the big USB driver update for 3.17-rc1.
Loads of gadget driver changes in here, including some big file
movements to make things easier to manage over time. There's also the
usual xhci and uas driver updates, and a handful of other changes in
here. The changelog has the full details.
All of these have been in linux-next for a while"
* tag 'usb-3.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (211 commits)
USB: devio: fix issue with log flooding
uas: Log a warning when we cannot use uas because the hcd lacks streams
uas: Only complain about missing sg if all other checks succeed
xhci: Add missing checks for xhci_alloc_command failure
xhci: Rename Asrock P67 pci product-id to EJ168
xhci: Blacklist using streams on the Etron EJ168 controller
uas: Limit qdepth to 32 when connected over usb-2
uwb/whci: use correct structure type name in sizeof
usb-core bInterval quirk
USB: serial: ftdi_sio: Add support for new Xsens devices
USB: serial: ftdi_sio: Annotate the current Xsens PID assignments
usb: chipidea: debug: fix sparse non static symbol warnings
usb: ci_hdrc_imx doc: fsl,usbphy is required
usb: ci_hdrc_imx: Return -EINVAL for missing USB PHY
usb: core: allow zero packet flag for interrupt urbs
usb: lvstest: Fix sparse warnings generated by kbuild test bot
USB: core: hcd-pci: free IRQ before disabling PCI device when shutting down
phy: miphy365x: Represent each PHY channel as a DT subnode
phy: miphy365x: Provide support for the MiPHY356x Generic PHY
phy: miphy365x: Add Device Tree bindings for the MiPHY365x
...
usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK
for output URBs. That causes usbcore to log messages without limit
for a nonsensical disallowed combination. The fix is to silently drop
the attribute in usbfs.
The problem is reported to exist since 3.14
https://www.virtualbox.org/ticket/13085
Signed-off-by: Oliver Neukum <oneukum@suse.de>
CC: stable@vger.kernel.org
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds a usb quirk to support devices with interupt endpoints
and bInterval values expressed as microframes. The quirk causes the
parse endpoint function to modify the reported bInterval to a standards
conforming value.
There is currently code in the endpoint parser that checks for
bIntervals that are outside of the valid range (1-16 for USB 2+ high
speed and super speed interupt endpoints). In this case, the code assumes
the bInterval is being reported in 1ms frames. As well, the correction
is only applied if the original bInterval value is out of the 1-16 range.
With this quirk applied to the device, the bInterval will be
accurately adjusted from microframes to an exponent.
Signed-off-by: James P Michels III <james.p.michels@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Section 4.4.7.2 "Interrupt Transfer Bandwidth Requirements" of the USB3.0 spec
says:
A zero-length data payload is a valid transfer and may be useful for
some implementations.
So, extend the logic of allowing URB_ZERO_PACKET to interrupt urbs too.
Otherwise, the kernel throws warning of BOGUS transfer flags.
Signed-off-by: Amit Virdi <amit.virdi@st.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
take longer time for link training compared to many others. Such
devices fail to reconnect with same old address which was associated
with it before suspend.
When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present then, SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.
Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port. In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.
Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.
I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present
for few others. I tested with 3.13-FC19 running at i686 desktop, problem
was still there. However, I was failed to reproduce it with 3.16-RC4
running at same i686 machine. I would say it is just a random
observation. Problem for few devices is always there, as I am unable to
find a proper fix for the issue.
So, now question is what should be the amount of delay so that host is
always able to recognize suspended device after resume.
XHCI specs 4.19.4 says that when Link training is successful, port sets
CSC bit to 1. So if SW reads port status before successful link
training, then it will not find device to be present. USB Analyzer log
with such buggy devices show that in some cases device switch on the
RX termination after long delay of host enabling the VBUS. In few other
cases it has been seen that device fails to negotiate link training in
first attempt. It has been reported till now that few devices take as
long as 2000 ms to train the link after host enabling its VBUS and
RX termination. This patch implements a 2000 ms timeout for CSC bit to set
ie for link training. If in a case link trains before timeout, loop will
exit earlier.
This patch implements above delay, but only for SS device and when
persist is enabled.
So, for the good device overhead is almost none. While for the bad
devices penalty could be the time which it take for link training.
But, If a device was connected before suspend, and was removed
while system was asleep, then the penalty would be the timeout ie
2000 ms.
Results:
Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I am removing two fix mes in this file as after dicussing then it seems
there is no reason to check against Null for usb_device as it can never
be NULL and this is check is therefore not needed.
Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some laptops have an internal port for a BT device which picks
up noise when the kill switch is used, but not enough to trigger
printk_rlimit(). So we shouldn't log consecutive faults of this kind.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
[1022:7814], the second hotplugging will experience the USB 3.0 pen
drive is recognized as high-speed device. After bisecting the kernel,
I found the commit number 41e7e056cd
(USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
some experiments, the bug can be fixed by avoiding executing the function
hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
XHCI Controlleris [1022:7814] is already in RxDetect
(I tried printing out the port status before setting to Disabled state),
it's reasonable to check the port status before really executing
hub_usb3_port_disable().
Fixes: 41e7e056cd (USB: Allow USB 3.0 ports to be disabled.)
Signed-off-by: Gavin Guo <gavin.guo@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb_alloc_dev is used by lvstest driver now which can be built as
module. Therefore export usb_alloc_dev symbol.
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a host controller dies, we don't need to wait for a driver to
time out. We can shut down its URBs immediately. Without this
change, we can end up waiting 30 seconds for a mass-storage transfer
to time out.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb device will autoresume from choose_wakeup() if it is
autosuspended with the wrong wakeup setting, but below errors occur
because usb3503 misc driver will switch to standby mode when suspended.
As add USB_QUIRK_RESET_RESUME, it can stop setting wrong wakeup from
autosuspend_check().
[ 7.734717] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[ 7.854658] usb 1-3: device descriptor read/64, error -71
[ 8.079657] usb 1-3: device descriptor read/64, error -71
[ 8.294664] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[ 8.414658] usb 1-3: device descriptor read/64, error -71
[ 8.639657] usb 1-3: device descriptor read/64, error -71
[ 8.854667] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[ 9.264598] usb 1-3: device not accepting address 3, error -71
[ 9.374655] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[ 9.784601] usb 1-3: device not accepting address 3, error -71
[ 9.784838] usb usb1-port3: device 1-3 not suspended yet
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Resuming a powered down port sometimes results in the port state being
stuck in the training sequence.
hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
port1: can't get reconnection after setting port power on, status -110
hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19
usb 3-1: can't resume, status -19
hub 3-0:1.0: logical disconnect on port 1
In the case above we wait for the port re-connect timeout of 2 seconds
and observe that the port status is USB_SS_PORT_LS_POLLING (although it
is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT).
This is indicative of a case where the device is failing to progress the
link training state machine.
It is resolved by issuing a warm reset to get the hub and device link
state machines back in sync.
hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
usb usb3: port1 usb_port_runtime_resume requires warm reset
hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms
usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd
After a reconnect timeout when we expect the device to be present, force
a warm reset of the device. Note that we can not simply look at the
link status to determine if a warm reset is required as any of the
training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or
USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need
for warm reset by themselves.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Vincent Palatin <vpalatin@chromium.org>
Cc: Lan Tianyu <tianyu.lan@intel.com>
Cc: Ksenia Ragiadakou <burzalodowa@gmail.com>
Cc: Vivek Gautam <gautam.vivek@samsung.com>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Sunil Joshi <joshi@samsung.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Acked-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a USB device is disconnected, usb_unbind_interface is called, which
tries to enable and disable LPM. usb_enable_lpm also try to send a
control command SET SEL to the device.
Since device is already disconnected, therefore it does not make sense
to execute usb_(en/dis)able_lpm.
This patch returns from usb_(en/dis)able_lpm, if device was not in
default state atleast.
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Tested-by: Aymen Bouattay <aymen.bouattay@st.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Koch