URBs and buffers allocated in attach for Epic devices would never be
deallocated in case of a later probe error (e.g. failure to allocate
minor numbers) as disconnect is then never called.
Fix by moving deallocation to release and making sure that the
URBs are first unlinked.
Fixes: f9c99bb8b3 ("USB: usb-serial: replace shutdown with disconnect,
release")
Cc: stable <stable@vger.kernel.org> # v2.6.31
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Private data, URBs and buffers allocated for Epic devices during
attach were never released on errors (e.g. missing endpoints).
Fixes: 6e8cf7751f ("USB: add EPIC support to the io_edgeport driver")
Cc: stable <stable@vger.kernel.org> # v2.6.21
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In netdevice.h we removed the structure in net-next that is being
changes in 'net'. In macsec.c and rtnetlink.c we have overlaps
between fixes in 'net' and the u64 attribute changes in 'net-next'.
The mlx5 conflicts have to do with vxlan support dependencies.
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge "usb: host: xhci-tegra: Changes for v4.7-rc1" from Thierry Reding:
This set of patches introduces a driver for the XUSB controller found on
NVIDIA Tegra SoCs. When loaded with a firmware (available via the linux-
firmware repository), it provides an XHCI-compatible interface.
* tag 'tegra-for-4.7-xhci' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
usb: xhci: tegra: Add Tegra210 support
usb: xhci: Add NVIDIA Tegra XUSB controller driver
dt-bindings: usb: xhci-tegra: Add Tegra210 XUSB controller support
dt-bindings: usb: Add NVIDIA Tegra XUSB controller binding
The right part of the following or expression is only evaluated if
td is nonzero.
!td || (td && td.status == USB_TD_INPROGRESS)
So no need to check td again.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The firmware of R-Car USB 3.0 host controller will control the reset.
So, if the xhci driver doesn't do firmware downloading (e.g. kernel
configuration is CONFIG_USB_XHCI_PLATFORM=y and CONFIG_USB_XHCI_RCAR
is not set), the reset of USB 3.0 host controller doesn't work
correctly. Then, the host controller will cause long wait in
xhci_reset() because the CMD_RESET bit of op_regs->command is not
cleared for 10 seconds.
So, this patch modifies the Kconfig to enable both CONFIG_USB_XHCI_PLATFORM
and CONFIG_USB_XHCI_RCAR.
Fixes: 4ac8918f3a (usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers)
Cc: <stable@vger.kernel.org> # v3.17+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The goto in create_sysfs_files is never executed, so remove it
and clean up the code.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The CRTSCTS flag code cleared (and inconsistently) bits unrelated to
CRTSCTS functionality. It was also harder than necessary to read.
Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Replaced magic numbers used in the CRTSCTS flag code with symbolic names
from the chip specification.
Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
A bug in the CRTSCTS handling caused RTS to alternate between
CRTSCTS=0 => "RTS is transmit active signal" and
CRTSCTS=1 => "RTS is used for receive flow control"
instead of
CRTSCTS=0 => "RTS is statically active" and
CRTSCTS=1 => "RTS is used for receive flow control"
This only happened after first having enabled CRTSCTS.
Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
Fixes: 39a66b8d22 ("[PATCH] USB: CP2101 Add support for flow control")
Cc: stable <stable@vger.kernel.org>
[johan: reword commit message ]
Signed-off-by: Johan Hovold <johan@kernel.org>
The stack object “ci” has a total size of 8 bytes. Its last 3 bytes
are padding bytes which are not initialized and leaked to userland
via “copy_to_user”.
Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the original DWC3_DCFG_NUMP() was always zero. It looks like the
intent was to shift first and then do the mask.
Fixes: 2a58f9c12b ('usb: dwc3: gadget: disable automatic calculation of ACK TP NUMP')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The current implemenentation restart the sent pattern for each entry in
the sg list. The receiving end expects a continuous pattern, and test
will fail unless scatterilst entries happen to be aligned with the
pattern
Fix this by calculating the pattern byte based on total sent size
instead of just the current sg entry.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Fixes: 8b52490193 ("[PATCH] USB: usbtest: scatterlist OUT data pattern testing")
Cc: <stable@vger.kernel.org> # v2.6.18+
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The return type of usbhsp_setup_pipecfg() was u16 but it was returning
a negative value (-EINVAL). Lets have an additional argument which will
have pipecfg and just return the status (success or error) as the return
from the function.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a USB driver is bound to an interface (either through probing or
by claiming it) or is unbound from an interface, the USB core always
disables Link Power Management during the transition and then
re-enables it afterward. The reason is because the driver might want
to prevent hub-initiated link power transitions, in which case the HCD
would have to recalculate the various LPM parameters. This
recalculation takes place when LPM is re-enabled and the new
parameters are sent to the device and its parent hub.
However, if the driver does not want to prevent hub-initiated link
power transitions then none of this work is necessary. The parameters
don't need to be recalculated, and LPM doesn't need to be disabled and
re-enabled.
It turns out that disabling and enabling LPM can be time-consuming,
enough so that it interferes with user programs that want to claim and
release interfaces rapidly via usbfs. Since the usbfs kernel driver
doesn't set the disable_hub_initiated_lpm flag, we can speed things up
and get the user programs to work by leaving LPM alone whenever the
flag isn't set.
And while we're improving the way disable_hub_initiated_lpm gets used,
let's also fix its kerneldoc.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Matthew Giassa <matthew@giassa.net>
CC: Mathias Nyman <mathias.nyman@intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Added support for Gemalto's Cinterion PH8 and AHxx products
with 2 RmNet Interfaces and products with 1 RmNet + 1 USB Audio interface.
In addition some minor renaming and formatting.
Signed-off-by: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
[johan: sort current entries and trim trailing whitespace ]
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
This reverts commit e3345db850, which
broke system resume for a large class of devices.
Devices that after having been reset during resume need to be rebound
due to a missing reset_resume callback, are now left in a suspended
state. This specifically broke resume of common USB-serial devices,
which are now unusable after system suspend (until disconnected and
reconnected) when USB persist is enabled.
During resume, usb_resume_interface will set the needs_binding flag for
such interfaces, but unlike system resume, run-time resume does not
honour it.
Cc: stable <stable@vger.kernel.org> # 4.5
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This means all ->con_set_palette have to have the second parameter
const too now.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace ASYNC_INITIALIZED bit in the tty_port::flags field with
TTY_PORT_INITIALIZED bit in the tty_port::iflags field. Introduce helpers
tty_port_set_initialized() and tty_port_initialized() to abstract
atomic bit ops.
Note: the transforms for test_and_set_bit() and test_and_clear_bit()
are unnecessary as the state transitions are already mutually exclusive;
the tty lock prevents concurrent open/close/hangup.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The debugging facilities in ehci-dbg.c follow an uneven pattern. Some
of them are protected by "#ifdef CONFIG_DYNAMIC_DEBUG" and some
aren't, presumably in the hope of having some of the debugging output
available in any configuration.
This leads to build problems when dynamic debugging isn't configured.
Rather than try to keep this complicated state of affairs, let's just
make everything dependent on CONFIG_DYNAMIC_DEBUG.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB Type-C Connector System Software Interface (UCSI) is
specification that defines the registers and data structures
that can be used to control USB Type-C ports on a system.
UCSI is used on several Intel Broxton SoC based platforms.
Things that UCSI can be used to control include at least USB
Data Role swapping, Power Role swapping and controlling of
Alternate Modes on top of providing general details about
the port and the partners that are attached to it.
The initial purpose of the UCSI driver is to make sure USB
is in host mode on desktop and server systems that are USB
dual role capable, and provide UCSI interface.
The goal is to integrate the driver later to an USB Type-C
framework for Linux kernel, and at the same time add support
for more extensive USB Type-C port control that UCSI offers,
for example data role swapping, power role swapping,
Alternate Mode control etc.
The UCSI specification is public can be obtained from here:
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for the on-chip XUSB controller present on Tegra SoCs. This
controller, when loaded with external firmware, exposes an interface
compliant with xHCI. This driver loads the firmware, starts the
controller, and is able to service host-specific messages sent by the
controller's firmware.
The controller also supports USB device mode as well as powergating
of the SuperSpeed and host-controller logic when not in use, but
support for these is not yet implemented.
Based on work by:
Ajay Gupta <ajayg@nvidia.com>
Bharath Yadav <byadav@nvidia.com>
Andrew Bresticker <abrestic@chromium.org>
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When the root hub device is added to the bus, it tries to get pins
information from pinctrl (see pinctrl_bind_pins, at really_probe), if
the pin information is described at DT, it will show below error since
the root hub's device node is the same with controller's, but controller's
pin has already been requested when it is added to platform bus.
imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already
requested by 2184000.usb; cannot claim for usb1
imx6q-pinctrl 20e0000.iomuxc: pin-137 (usb1) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 137
(MX6Q_PAD_GPIO_1) from group usbotggrp-3 on device 20e0000.iomuxc
usb usb1: Error applying setting, reverse things back
To fix this issue, we move the root hub's device node assignment (equals
to contrller's) after device is added to bus, we only need to know root
hub's device node information after the device under root hub is created,
so this movement will not affect current function.
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Reported-by: Lars Steubesand <lars.steubesand@philips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The XHCI controller presents two USB buses to the system - one for USB2
and one for USB3. The hub init code (hub_port_init) is reentrant but
only locks one bus per thread, leading to a race condition failure when
two threads attempt to simultaneously initialise a USB2 and USB3 device:
[ 8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 13.183701] usb 3-3: device descriptor read/all, error -110
On a test system this failure occurred on 6% of all boots.
The call traces at the point of failure are:
Call Trace:
[<ffffffff81b9bab7>] schedule+0x37/0x90
[<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0
[<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30
[<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150
[<ffffffff817db10c>] usb_control_msg+0xbc/0xf0
[<ffffffff817d07de>] hub_port_init+0x51e/0xb70
[<ffffffff817d4697>] hub_event+0x817/0x1570
[<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
[<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
[<ffffffff810f4684>] worker_thread+0x64/0x4b0
[<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
[<ffffffff810fa7f5>] kthread+0x105/0x120
[<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
[<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
[<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
Call Trace:
[<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40
[<ffffffff817fd87e>] xhci_address_device+0xe/0x10
[<ffffffff817d047f>] hub_port_init+0x1bf/0xb70
[<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff817d4697>] hub_event+0x817/0x1570
[<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
[<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
[<ffffffff810f4684>] worker_thread+0x64/0x4b0
[<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
[<ffffffff810fa7f5>] kthread+0x105/0x120
[<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
[<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
[<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
Which results from the two call chains:
hub_port_init
usb_get_device_descriptor
usb_get_descriptor
usb_control_msg
usb_internal_control_msg
usb_start_wait_urb
usb_submit_urb / wait_for_completion_timeout / usb_kill_urb
hub_port_init
hub_set_address
xhci_address_device
xhci_setup_device
Mathias Nyman explains the current behaviour violates the XHCI spec:
hub_port_reset() will end up moving the corresponding xhci device slot
to default state.
As hub_port_reset() is called several times in hub_port_init() it
sounds reasonable that we could end up with two threads having their
xhci device slots in default state at the same time, which according to
xhci 4.5.3 specs still is a big no no:
"Note: Software shall not transition more than one Device Slot to the
Default State at a time"
So both threads fail at their next task after this.
One fails to read the descriptor, and the other fails addressing the
device.
Fix this in hub_port_init by locking the USB controller (instead of an
individual bus) to prevent simultaneous initialisation of both buses.
Fixes: 638139eb95 ("usb: hub: allow to process more usb hub events in parallel")
Link: https://lkml.org/lkml/2016/2/8/312
Link: https://lkml.org/lkml/2016/2/4/748
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Init data marked const should be annotated with __initconst for
correctness and not __initdata. This also fixes LTO builds that
otherwise fail with section mismatch errors.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
urb allocation will fail when usbtest_alloc_urb() tries to
allocate zero length buffer, but it doesn't need it in fact,
so just skips buffer allocation in the case.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NULL pointer dereferrence will happen when class driver
wants to allocate zero length buffer and pool_max[0]
can't be used, so simply returns NULL in the case.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With the addition of VUDC, the USBIP stack can now be used on
configurations without USB host support, but trying to build
it with USB gadget support disabled fails with
drivers/usb/built-in.o: In function `vep_dequeue':
vudc_main.c:(.text+0xa6ddc): undefined reference to `usb_gadget_giveback_request'
drivers/usb/built-in.o: In function `nuke':
vudc_main.c:(.text+0xa6ea8): undefined reference to `usb_gadget_giveback_request'
drivers/usb/built-in.o: In function `vudc_device_reset':
vudc_main.c:(.text+0xa720c): undefined reference to `usb_gadget_udc_reset'
drivers/usb/built-in.o: In function `vudc_probe':
This addresses both issues, by changing the dependency for USBIP_CORE
to USB_COMMON, and adding additional dependencies on USB or USB_GADGET
for the individual portions as needed.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 9360575c58 ("usbip: vudc: Add vudc to Kconfig")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds a code fragment to ignore completing URBs in closing
connection.
Regarding this patch, 2 execution contexts are related.
1) stub_tx.c: stub_complete() which is called from USB core
1-1) add to unlink list and free URB or
1-2) move to tx list
2) stub_dev.c: stub_shutdown_connection() which is invoked by unbind
operation through sysfs.
2-1) stop TX/RX threads
2-2) close TCP connection and set ud.tcp_socket to NULL
2-3) cleanup pending URBs by stub_device_cleanup_urbs(sdev)
2-4) free unlink list (no lock)
In the race condition, URBs which will be cleared in 2-3) may be
handled in 1).
In case 1-1), it will not be transferred bcause tx threads are stooped
in 2-1).
In case 1-2), may be freed in 2-4).
With this patch, after 2-2), completing URBs in 1) will not be handled
and cleared in 2-3).
The kernel log with this patch is as below.
kernel: usbip_core: usbip_kernel_unlink:792: shutting down tcp_socket
ef61d980
kernel: usbip-host 1-3: free sdev f5df6180
kernel: usbip-host 1-3: free urb f5df6700
kernel: usbip-host 1-3: Enter
kernel: usbip_core: usbip_stop_eh:132: usbip_eh waiting completion 5
kernel: usbip_host: stub_complete:71: complete! status 0
kernel: usbip_host: stub_complete:102: ignore urb for closed connection
e725fc00 (*)
kernel: usbip_host: stub_complete:71: complete! status -2
kernel: usbip-host 1-3: stopped by a call to usb_kill_urb() because of
cleaning up a virtual connection
kernel: usbip-host 1-3: free urb e725fc00 (**)
kernel: usbip-host 1-3: free urb e725e000
kernel: usbip_host: stub_complete:71: complete! status -2
kernel: usbip-host 1-3: stopped by a call to usb_kill_urb() because of
cleaning up a virtual connection
kernel: usbip-host 1-3: free urb e725f800
kernel: usbip_host: stub_complete:71: complete! status -2
kernel: usbip-host 1-3: stopped by a call to usb_kill_urb() because of
cleaning up a virtual connection
kernel: usbip-host 1-3: free urb e725e800
kernel: usbip_host: stub_complete:71: complete! status -2
kernel: usbip-host 1-3: stopped by a call to usb_kill_urb() because of
cleaning up a virtual connection
kernel: usbip-host 1-3: device reset
kernel: usbip-host 1-3: lock for reset
kernel: usbip_host: store_match_busid:178: del busid 1-3
kernel: uvcvideo: Found UVC 1.00 device Venus USB2.0 Camera (056e:700a)
kernel: input: Venus USB2.0 Camera as
/devices/pci0000:00/0000:00:1a.7/usb1/1-3/1-3:1.0/input/input22
(*) skipped with this patch in completion
(**) released in 2-3
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As find_endpoint() is a global funcion rename it to vudc_find_endpoint()
to clearly mark where does it come from.
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
