Some full-speed mceusb infrared transceivers contain invalid endpoint
descriptors for their interrupt endpoints, with bInterval set to 0.
In the past they have worked out okay with the mceusb driver, because
the driver sets the bInterval field in the descriptor to 1,
overwriting whatever value may have been there before.  However, this
approach was never sanctioned by the USB core, and in fact it does not
work with xHCI controllers, because they use the bInterval value that
was present when the configuration was installed.

Currently usbcore uses 32 ms as the default interval if the value in
the endpoint descriptor is invalid.  It turns out that these IR
transceivers don't work properly unless the interval is set to 10 ms
or below.  To work around this mceusb problem, this patch changes the
endpoint-descriptor parsing routine, making the default interval value
be 10 ms rather than 32 ms.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NWade Berrier <wberrier@gmail.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We have CONFIG_BLACKFIN ifdef redefining all musb registers in
musb_regs.h and tusb6010.h is never included causing a build
error with blackfin-allmodconfig and COMPILE_TEST.

Let's fix the issue by not building tusb6010 if CONFIG_BLACKFIN
is selected.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds support for Infineon flashloader 0x8087/0x0801.

The flashloader is used in Telit LE940B modem family with Telit
flashing application.
Signed-off-by: NDaniele Palmas <dnlplm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

Problems with the signal integrity of the high speed USB data lines or
noise on reference ground lines can cause the i.MX6 USB controller to
violate USB specs and exhibit unexpected behavior.

It was observed that USBi_UI interrupts were triggered first and when
isr_setup_status_phase was called, ci->status was NULL, which lead to a
NULL pointer dereference kernel panic.

This patch fixes the kernel panic, emits a warning once and returns
-EPIPE to halt the device and let the host get stalled.
It also adds a comment to point people, who are experiencing this issue,
to their USB hardware design.

Cc: <stable@vger.kernel.org> #4.1+
Signed-off-by: NClemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

The stop endpoint command has its own 5 second timeout timer.
If the timeout function is triggered between USB3 and USB2 host
removal it will try to call usb_hc_died(xhci_to_hcd(xhci)->primary_hcd)

the ->primary_hcd will be set to NULL at USB3 hcd removal.

Fix this by first checking if the PCI host is being removed, and
also by using only xhci_to_hcd() as it will always return the primary
hcd.

CC: <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When building a kernel with CONFIG_PM_SLEEP=n, we
get the following warning:

drivers/usb/dwc3/dwc3-pci.c:253:12: warning: 'dwc3_pci_pm_dummy' defined but not used

In order to fix this, we should only define
dwc3_pci_pm_dummy() when CONFIG_PM_SLEEP is defined.

Fixes: f6c274e1 ("usb: dwc3: pci: runtime_resume child device")
Reported-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

An earlier fix partially fixed the null pointer dereference on skb->len
by moving the assignment of len after the check on skb being non-null,
however it failed to remove the erroneous dereference when assigning len.
Correctly fix this by removing the initialisation of len as was
originally intended.

Fixes: 70237dc8 ("usb: gadget: function: f_eem: socket buffer may be NULL")
Acked-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The previous driver is possible to stop the transfer wrongly.
For example:
 1) An interrupt happens, but not BRDY interruption.
 2) Read INTSTS0. And than state->intsts0 is not set to BRDY.
 3) BRDY is set to 1 here.
 4) Read BRDYSTS.
 5) Clear the BRDYSTS. And then. the BRDY is cleared wrongly.

Remarks:
 - The INTSTS0.BRDY is read only.
  - If any bits of BRDYSTS are set to 1, the BRDY is set to 1.
  - If BRDYSTS is 0, the BRDY is set to 0.

So, this patch adds condition to avoid such situation. (And about
NRDYSTS, this is not used for now. But, avoiding any side effects,
this patch doesn't touch it.)

Fixes: d5c6a1e0 ("usb: renesas_usbhs: fixup interrupt status clear method")
Cc: <stable@vger.kernel.org> # v3.8+
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

clk_prepare_enable() may fail, so we should better check its return
value and propagate it in the case of failure.
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This driver should clear the bit. Otherwise, the VBUS will output
wrongly if the usb port on a board has VBUS output capability.

Fixes: 746bfe63 ("usb: gadget: renesas_usb3: add support for
		      Renesas USB3.0 peripheral controller")
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This reverts commit 6f8245b4 ("usb: dwc3: gadget: always decrement
by 1").

We can't always decrement this value.

We should decrement only if the calculation of free slots results in a
LINK TRB being among one of the free slots (dequeue < enqueue).

Otherwise, if the LINK TRB is not among the free slots then it should
not be decremented.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

If we have USB gadgets disabled and USB_MUSB_HOST set, we get
errors "possible irq lock inverssion dependency detected"
errors during boot.

Let's fix the issue by adding start_musb flag and start
the controller after we're out of the spinlock protected
section.
Reported-by: NLadislav Michl <ladis@linux-mips.org>
Tested-by: NLadislav Michl <ladis@linux-mips.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We need to decrement in both cases (enq > deq and
enq < deq)
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

There was a typo when generating endpoint name which
would be very confusing when debugging. Fix it.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Always unmap all SG entries as required by DMA API

Fixes: a698908d ("usb: gadget: add generic map/unmap request utilities")
Cc: <stable@vger.kernel.org> # v3.4+
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

These product IDs are listed in Windows driver.
0x6803 corresponds to WeTelecom WM-D300.
0x6802 name is unknown.
Signed-off-by: NAleksandr Makarov <aleksandr.o.makarov@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

UBSAN complains about a left shift by -1 in proc_do_submiturb().  This
can occur when an URB is submitted for a bulk or control endpoint on
a high-speed device, since the code doesn't bother to check the
endpoint type; normally only interrupt or isochronous endpoints have
a nonzero bInterval value.

Aside from the fact that the operation is illegal, it shouldn't matter
because the result isn't used.  Still, in theory it could cause a
hardware exception or other problem, so we should work around it.
This patch avoids doing the left shift unless the shift amount is >= 0.

The same piece of code has another problem.  When checking the device
speed (the exponential encoding for interrupt endpoints is used only
by high-speed or faster devices), we need to look for speed >=
USB_SPEED_SUPER as well as speed == USB_SPEED HIGH.  The patch adds
this check.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NVittorio Zecca <zeccav@gmail.com>
Tested-by: NVittorio Zecca <zeccav@gmail.com>
Suggested-by: NBjørn Mork <bjorn@mork.no>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The maximum value allowed for wMaxPacketSize of a high-speed interrupt
endpoint is 1024 bytes, not 1023.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Fixes: aed9d65a ("USB: validate wMaxPacketValue entries in endpoint descriptors")
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When usb gadget is set gadget serial function, it will be crash in below
situation.

It will clean the 'port->port_usb' pointer in gserial_disconnect() function
when usb link is inactive, but it will release lock for disabling the endpoints
in this function. Druing the lock release period, it maybe complete one request
to issue gs_write_complete()--->gs_start_tx() function, but the 'port->port_usb'
pointer had been set NULL, thus it will be crash in gs_start_tx() function.

This patch adds the 'port->port_usb' pointer checking in gs_start_tx() function
to avoid this situation.
Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

__dwc3_gadget_wakeup() is called while holding a spinlock, then depends on
jiffies in order to timeout while polling the USB core for a link state
update. In the case the wakeup failed, the timeout will never happen and
will also cause the cpu to stall until rcu_preempt kicks in.

This switches to a "decrement variable and wait" timeout scheme.
Signed-off-by: NNicolas Saenz Julienne <nicolassaenzj@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We can't assign -EINVAL to a u16.

Fixes: 3948f0e0 ('usb: add Freescale QE/CPM USB peripheral controller driver')
Acked-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In eth_start_xmit, the socket buffer may be NULL. So, add NULL pointer
check at .wrap API.
Signed-off-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In eth_start_xmit, the socket buffer may be NULL. So, add NULL pointer
check at .wrap API.
Signed-off-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In case of error, the function usb_get_phy() returns ERR_PTR() and never
returns NULL. The NULL test in the return value check should be replaced
with IS_ERR().

Fixes: b5a28756 ("usb: renesas_usbhs: Allow an OTG PHY driver to
	provide VBUS")
Cc: <stable@vger.kernel.org> # v4.3+
Acked-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NWei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Allow for platforms that have a reset controller driver in place to bring
the USB IP out of reset.
Signed-off-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

After going through runtime_suspend/runtime_resume
cycle once we would be left with an unbalanced
pm_runtime_get() call. Fix that by making sure that
we try to suspend right after resuming so things are
balanced and device can runtime_suspend again.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

During runtime_resume of dwc3-pci.c, we need to
runtime suspend our child device (which is dwc3
proper) otherwise nothing will happen.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Add support for WeTelecom WM-D200.

T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=22de ProdID=6801 Rev=00.00
S:  Manufacturer=WeTelecom Incorporated
S:  Product=WeTelecom Mobile Products
C:  #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
Signed-off-by: NAleksandr Makarov <aleksandr.o.makarov@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

When the controller is configured to be dual role and it's in host mode,
if bind udc and gadgt driver, those gadget operations will do gadget
disconnect and finally pull down DP line, which will break host function.

Cc: <stable@vger.kernel.org> # 4.1+
Signed-off-by: NLi Jun <jun.li@nxp.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

Remove the hcd after checking for the xhci last quirks, not before.

This caused a hang on a Alpine Ridge xhci based maching which remove
the whole xhci controller when unplugging the last usb device

CC: <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After a device is disconnected, xhci_stop_device() will be invoked
in xhci_bus_suspend().
Also the "disconnect" IRQ will have ISR to invoke
xhci_free_virt_device() in this sequence.
xhci_irq -> xhci_handle_event -> handle_cmd_completion ->
xhci_handle_cmd_disable_slot -> xhci_free_virt_device

If xhci->devs[slot_id] has been assigned to NULL in
xhci_free_virt_device(), then virt_dev->eps[i].ring in
xhci_stop_device() may point to an invlid address to cause kernel
panic.

virt_dev = xhci->devs[slot_id];
:
if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)

[] Unable to handle kernel paging request at virtual address 00001a68
[] pgd=ffffffc001430000
[] [00001a68] *pgd=000000013c807003, *pud=000000013c807003,
*pmd=000000013c808003, *pte=0000000000000000
[] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G     U
[] Workqueue: pm pm_runtime_work
[] task: ffffffc0bc0e0bc0 ti: ffffffc0bc0ec000 task.ti:
ffffffc0bc0ec000
[] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4

This issue is found when running with realtek ethernet device
(0bda:8153).
Signed-off-by: NJim Lin <jilin@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Enqueue the first TRB even if full_len is zero.
Without this "adb install <apk>" freezes the system.
Signed-off-by: NAlban Browaeys <alban.browaeys@gmail.com>
Fixes: 86065c27 ("xhci: don't rely on precalculated value of needed trbs in the enqueue loop")
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix "Command completion event does not match command" errors by always
handling the command ring stopped events.

The command ring stopped event is generated as a result of aborting
or stopping the command ring with a register write. It is not caused
by a command in the command queue, and thus won't have a matching command
in the comman list.

Solve it by handling the command ring stopped event before checking for a
matching command.

In most command time out cases we abort the command ring, and get
a command ring stopped event. The events command pointer will point at
the current command ring dequeue, which in most cases matches the timed
out command in the command list, and no error messages are seen.

If we instead get a command aborted event before the command ring stopped
event, the abort event will increse the command ring dequeue pointer, and
the following command ring stopped events command pointer will point at the
next, not yet queued command. This case triggered the error message
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This fixes the "BOGUS urb xfer" warning logged by usb_submit_urb().
Signed-off-by: NGavin Li <git@thegavinli.com>
Acked-by: NOliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is an allocation with GFP_KERNEL flag in mos7840_write(),
while it may be called from interrupt context.

Follow-up for commit 19125283 ("USB: kobil_sct: fix non-atomic
allocation in write path")

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

There is an allocation with GFP_KERNEL flag in mos7720_write(),
while it may be called from interrupt context.

Follow-up for commit 19125283 ("USB: kobil_sct: fix non-atomic
allocation in write path")

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>

In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling
into usb_sg_cancel(). usb_sg_cancel() will do nothing and return
directly if req->status has been set to a non-zero value. This will
cause driver hang whenever transfer time out is triggered.

This patch fixes this issue. It could be backported to stable kernel
with version later than v3.15.

Cc: stable@vger.kernel.org # 3.15+
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

stop consuming TRBs when we reach one with HWO bit
already set. This will prevent us from prematurely
retiring a TRB.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

According to Synopsys Databook 2.60a, section 8.3.4,
it's stated that:

	The LST bit should be set to 0 (isochronous
	transfers normally continue until the
	endpoint is removed entirely, at which time
	an End Transfer command is used to stop the
	transfer).

This patch makes sure that detail is observed and
fixes a regression with Android Audio playback
caused by recent changes to DWC3 gadget.
Signed-off-by: NJanusz Dziedzic <januszx.dziedzic@linux.intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

When rndis data transfer is in progress, some Windows7 Host PC is not
sending the GET_ENCAPSULATED_RESPONSE command for receiving the response
for the previous SEND_ENCAPSULATED_COMMAND processed.

The rndis function driver appends each response for the
SEND_ENCAPSULATED_COMMAND in a queue. As the above process got corrupted,
the Host sends a REMOTE_NDIS_RESET_MSG command to do a soft-reset.
As the rndis response queue is not freed, the previous response is sent
as a part of this REMOTE_NDIS_RESET_MSG's reset response and the Host
block any more Rndis transfers.

Hence free the rndis response queue as a part of this soft-reset so that
the correct response for REMOTE_NDIS_RESET_MSG is sent properly during the
response command.
Signed-off-by: NRajkumar Raghupathy <raghup@codeaurora.org>
Signed-off-by: NXerox Lin <xerox_lin@htc.com>
[AmitP: Cherry-picked this patch and folded other relevant
        fixes from Android common kernel android-4.4]
Signed-off-by: NAmit Pundir <amit.pundir@linaro.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>