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: 2a58f9c1 ('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>

Allow for SS+
Signed-off-by: Oliver Neukum <ONeukum@suse.com>
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: 8b524901 ("[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>

Adding names database to port command.

BEFORE) 'unknown' for vendor and product string.

Imported USB devices
====================
Port 00: <Port in Use> at Low Speed(1.5Mbps)
       unknown vendor : unknown product (03f0:0224)
       3-1 -> usbip://10.0.2.15:3240/5-1
           -> remote bus/dev 005/002

AFTER) Most vendor string will be converted.

Imported USB devices
====================
Port 00: <Port in Use> at Low Speed(1.5Mbps)
       Hewlett-Packard : unknown product (03f0:0224)
       3-1 -> usbip://10.0.2.15:3240/5-1
           -> remote bus/dev 005/002
Signed-off-by: Nobuo Iwata <nobuo.iwata@fujixerox.co.jp>
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>

One line above we have checked that udc is NULL so we shouldn't
dereference it while printing error message.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

We read a struct usb_device_descriptor from it, so make it an actual
binary attribute.
Signed-off-by: Igor Kotrasinski <i.kotrasinsk@gmail.com>
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Tested-by: Krzysztof Opasiak <k.opasiak@samsung.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.htmlSigned-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

Use "foo *bar" instead of "foo * bar".
Signed-off-by: Sandhya Bankar <bankarsandhya512@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove unnecessary space before function pointer arguments.
Signed-off-by: Sandhya Bankar <bankarsandhya512@gmail.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: 638139eb ("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/748Signed-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>

usbdev_vm_ops is used in devio.c only, so declare it as static
Signed-off-by: Michele Curti <michele.curti@gmail.com>
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: 9360575c ("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>

Fix NULL pointer dereference and obsolete comments forgotten when
usbip server was converted from an interface driver to a device driver.
Signed-off-by: Alexander Popov <alpopov@ptsecurity.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix WARN_ON() macro usage as suggested by Felipe.
Instead of using:
if (cond) {
   WARN_ON(1);
   do_stuff();
}

Use a better pattern with WARN_ON() placed in if condition:

if (WARN_ON(cond))
   do_stuff();
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

As vudc provides some new attributes using sysfs infrastructure,
add a suitable documentation file for those attributes.
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Felipe writes:

usb: changes for v4.7 merge window

Here's the big USB Gadget pull request. This time
not as large as usual with only 57 non-merge
commits.

The most important part here is, again, all the work
on dwc3. This time around we're treating all
endpoints (except for control endpoint) exactly the
same. They all have the same amount of TRBs on the
ring, they all treat the ring as an actual ring with
a link TRB pointing to the head, etc.

We're also helping the host side burst (on
SuperSpeed GEN1 or GEN2 at least) for as long as
possible until the endpoint returns NRDY.

Other than this big TRB ring rework on dwc3, we also
have a dwc3-omap DMA initialization fix, some extra
debugfs files to aid in some odd debug sessions and
a complete removal of our FIFO resizing logic.

We have a new quirk for some dwc3 P3 quirk in some
implementations.

The rest is basically non-critical fixes and the
usual cleanups.

Now that we calculate DCFG.NUMP, we can disable
dwc3's automatic calculation so we maximize our
chances of very high throughtput through the use of
bursts.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

NumP field of DCFG register is used on NumP field of
ACK TP header and it tells the host how many packets
an endpoint can receive before waiting for
synchronization.

Documentation says it should be set to anything
<=bMaxBurst. Interestingly, however, this setting is
not per-endpoint how it should be (different
endpoints could have different burst sizes), but
things seem to work okay right now.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

Cleanup in probe if we fail to get dr_mode.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

In case of DDMA mode we don't need to get an SOF interrupt so disable
the unmasking of SOF interrupt in DDMA mode.
Signed-off-by: Sevak Arakelyan <sevaka@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

This is safety change added while doing slub debugging.

Affected functions:
dwc2_hcd_qtd_unlink_and_free()
_dwc2_hcd_urb_enqueue()
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

In host slave mode, the core asserts the rxready, txfifoempty interrupts
that get serviced in the gadget irq handler. Prevent servicing of these
when not in the gadget mode of operation.
Signed-off-by: Vardan Mikayelyan <mvardan@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

Replaced the WARN_ON with a check and return of -EINVAL in the
dwc2_hsotg_ep_enable function if ep0 is passed in.
Signed-off-by: Vahram Aharonyan <vahrama@synopsys.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

if Start Transfer command fails, let's try a little
harder to figure out why the command failed and give
slightly better return codes. This will be usefulf
or isochronous endpoints, at least, which could
decide to retry a given request.
Signed-off-by: Konrad Leszczynski <konrad.leszczynski@intel.com>
Signed-off-by: Rafal Redzimski <rafal.f.redzimski@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

If a gadget driver loaded to a Superspeed-capable
peripheral controller, using a Superspeed cable,
doesn't provide Superspeed descriptors, we will get
a NULL pointer dereference.

In order to avoid that situation, we will try to
find any valid descriptors we can. If no set of
descriptors is passed in, then we'll let that gadget
oops anyhow.
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

For convenience, passing the dwc3 platform device as a
parameter to dwc3_pci_quirks() function.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

Setting the ACPI companion before calling dwc3_pci_quirks.
The ACPI companion will be set unconditionally as the
primary fwnode, overriding any previously set primary
fwnode. This will make sure that any build-in properties
added to the platform device will be added as the secondary
fwnode in cases where also ACPI companion exists.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

In case host sends us an unsupported test mode, we
*must* stall this request. This will tell the host
that the selector is invalid and we won't put the
controller in unsupported test modes which could
have undetermined side-effects.
Signed-off-by: Fei Yang <fei.yang@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

whc_init already calls whc_clean_up if an error occurs during
the initialization, so calling it again if whc_init fails at
the end of wch_probe will cause double free errors.  Fix this
by bailing out on an whc_init failure to a new label that avoids
doing the duplicated whc_clean_up.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Thanks to switching to devm_gpiod_get:
1) We don't have to pass fwnode pointer
2) We can request initial GPIO value at getting call
This was successfully tested on Netgear R6250 (BCM4708).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>