When dwc3 core enters into suspend mode, the system (especially for mobile
device) may power off the dwc3 controller for power saving, that will cause
dwc3 controller lost the mode operation when resuming dwc3 core.

Thus we can move the mode setting into dwc3_core_init() function to avoid this
issue.
Signed-off-by: NBaolin Wang <baolin.wang@linaro.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This change makes sure that the ALSA buffers are cleaned if an endpoint
becomes disabled.

Before this change, if the internal ALSA buffer did overflow, the MIDI
function would stop sending MIDI to the host.
Signed-off-by: NFelipe F. Tonello <eu@felipetonello.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This refactor results in a cleaner state machine code and promotes
consistency, readability, and maintanability of this driver.

This refactor state machine was well tested and it is currently running in
production code and devices.
Signed-off-by: NFelipe F. Tonello <eu@felipetonello.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

512 is the value used by wMaxPacketSize, as specified by the USB Spec. This
makes sure this driver uses, by default, the most optimal value for IN and OUT
endpoint requests.
Signed-off-by: NFelipe F. Tonello <eu@felipetonello.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The new version of alloc_ep_req() already aligns the buffer size to
wMaxPacketSize on OUT endpoints.
Signed-off-by: NFelipe F. Tonello <eu@felipetonello.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Using usb_ep_align() makes sure that the buffer size for OUT endpoints is
always aligned with wMaxPacketSize (512 usually). This makes sure
that no buffer has the wrong size, which can cause nasty bugs.
Signed-off-by: NFelipe F. Tonello <eu@felipetonello.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Length of buffers should be of type size_t whenever possible. Altough
recommended, this change has no real practical change, unless a driver has a
uses a huge or negative buffer size - it might help find these bugs.
Signed-off-by: NFelipe F. Tonello <eu@felipetonello.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Introduce an attribute "inquiry_string" to the lun.

In some environments, e. g. BIOS boot menus, the inquiry string
is the only information about devices presented to the user. The
default string depends on the "cdrom" bit of the first lun as
well as the kernel version and allows no further customization.
So without access to the client it is not obvious which gadget is
active at a given point and what any of the available luns might
contain.

If "inquiry_string" is ignored or set to the empty string, the
old behavior is preserved.
Signed-off-by: NPhilipp Gesang <philipp.gesang@intra2net.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Rockchip platform merely enable usb3 clocks and
populate its children. So we can use this generic
glue layer to support Rockchip dwc3.
Signed-off-by: NWilliam Wu <william.wu@rock-chips.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Add a quirk to clear the GUSB3PIPECTL.DELAYP1TRANS bit,
which specifies whether disable delay PHY power change
from P0 to P1/P2/P3 when link state changing from U0
to U1/U2/U3 respectively.
Signed-off-by: NWilliam Wu <william.wu@rock-chips.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Support to configure the UTMI+ PHY with an 8- or 16-bit
interface via DT. The UTMI+ PHY interface is a hardware
capability, and it's platform dependent. Normally, the
PHYIF can be configured during coreconsultant.

But for some specific USB cores(e.g. rk3399 SoC DWC3),
the default PHYIF configuration value is false, so we
need to reconfigure it by software.
Signed-off-by: NWilliam Wu <william.wu@rock-chips.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Add a quirk to clear the GUSB2PHYCFG.U2_FREECLK_EXISTS bit,
which specifies whether the USB2.0 PHY provides a free-running
PHY clock, which is active when the clock control input is active.
Signed-off-by: NWilliam Wu <william.wu@rock-chips.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

With composite gadget (ACM + NCM), USB3380 to host TCP transfer
speed dropped to 150 Mbit/s compared to 900 Mbit/s with NCM
gadget. Problem seems to be that net2280/USB3380 has only four
DMA channels and those DMA channels are allocated to first HW
endpoints. Endpoint match function was mapping endpoint names
directly, so NCM did not get DMA for bulk endpoints.

This patch changed match_ep to prefer DMA enabled hw endpoints
for bulk usb endpoints and PIO for interrupt usb endpoints.
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@haltian.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

With SuperSpeed CDC NCM gadget, net2280 would get stuck in
'handle_ep_small' function. Triggering issue requires large
TCP transfer from host to USB3380.

Patch adds check for stuck condition and prevents hard lockup.
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@haltian.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Patch enables SuperSpeed for NCM gadget.

Tested with USB3380 and measured TCP throughput with two Intel PCs:
  udc to host: 920 Mbit/s
  host to udc: 550 Mbit/s
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@haltian.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

alloc_ordered_workqueue replaces the deprecated
create_singlethread_workqueue.

There are multiple work items on the work queue, which require
ordering. Hence, an ordered workqueue has been used.

The workqueue "wq_otg" is not being used on a memory reclaim path.
Hence, WQ_MEM_RECLAIM has not been set.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NBhaktipriya Shridhar <bhaktipriya96@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The assignment ret = ret is redundant and can be removed.
Reviewed-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>

Disabling USB gadget functions configured through configfs is something
that can happen in normal use cases. Keep the existing log for this type
of event, but only as information, not as an error.
Signed-off-by: NRomain Izard <romain.izard.pro@gmail.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

As the last known user, ie. pxa27x_udc relying on calls to
usb_gadget_xxx() was amended to use the phy notifier, remove a bit the
USB stack adherence.

Actually the driver still uses the gadget API for structures definition,
but the implementation of USB gadget specific function usb_gadget_*() is
not necessary anymore.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In the gpio based case, the status of the phy is known at start by
reading the VBus gpio.

Actually, this is a fix, as this initial state, when not set up,
prevents a gadget to answer to the enumeration phase, as there is no
notification in this case (the VBus is already high when kernel boots)
so no interrupt is triggered, and the flow is :
 - gadget initializes
 - gadget gets its phy-generic with a xxx_get_phy_xxx() call type
 - gadget does a "set_peripheral()" call type
   => here if the otg->state is correctly filled, the proper vbus
   handling will be called, and the gadget will be aware it should
   answer enumeration and go forth

Without this fix, the USB cable must be removed and replugged for any
gadget relying on phy-generic and its gpio vbus handling to work.

The problem was seen on a pxa27x architecture based board on a
devicetree build.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In the legacy behavior, and USB phy, upon detection a VBus signal, was
calling usb_gadget_vbus_(dis)connect().

This model doesn't work if the phy is generic and doesn't have an
adherence to the gadget API.

Instead of relying on the phy to call the gadget API, hook up the phy
notifier to report the VBus event, and upon it call the usb gadget API
ourselves.

This brings a new ordering problem, as before even if the usb_get_phy()
was failing because the UDC was probed before the phy, the phy would
call the gadget anyway, making the VBus connection event forwarded to
the gadget. Now we rely on the notifier, we have to ensure the
xxx_get_phy() does indeed work.

In order to cope with this, it is assumed that :
 - for legacy platform_data machine, as the ordering cannot be ensured,
   the phy must call usb_gadget_vbus_(dis)connect, such as
   phy-gpio-vbus-usb.c
 - for new devicetree platforms, we'll rely on the probe deferral, and
   the phy can be gadget API agnostic.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

No functional changes, just a slight cosmetic
change.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We don't use LST bit anymore, so this condition will
never trigger.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Upon transfer completion after a full ring, let's
add more TRBs to our ring in order to complete our
request successfully.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

If the ring is full and we are processing a big
sglist, then let's interrupt so we can, later, add
more TRBs to the ring.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

These two fields will be used in a follow-up patch
to track how many entries of request's sglist we
have already processed. The reason is that if a
gadget driver sends an sglist with more entries then
we can fit in the ring, we will have to continue
processing remaining afterwards.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We know that we have to iterate over the list of
started requests. Instead of looping forever, we can
rely on list_for_each_entry(). Likewise, instead of
a do {} while loop over all, maybe available,
scatterlist entries, we can detect if $this request
uses scatterlist and rely on for_each_sg().

This makes the code easier to follow while making
sure that we will *always* break out of the loop.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Many of the comments in that function are really
outdated and don't match what the driver is
doing. Moreover, recent patches combined programming
model for all non-control endpoints, this gives us
an opportunity to get rid of our special cases in
__dwc3_gadget_ep_queue().
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We always need to decrement our index by at least
one. Simplify the implementation by using a
temporary local variable and making sure that we
will always decrement one extra if tmp == 0.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Instead of waiting until giveback before
incrementing the dequeue pointer, we can increment
it from dwc3_cleanup_done_reqs(), that way we avoid
an extra loop over all TRBs during giveback.

While at that, also avoid using req->first_trb_index
as that's completely unnecessary. A follow-up patch
will clean up further uses of that and remove the
field altogether.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The only endpoint which actually requires LST bit
and XferComplete is ep0/1. Let's save some time by
completely removing LST bit support and
XferComplete.

This simplifies and consolidates endpoint handling
for all other 3 transfer types while also avoiding
extra interrupts.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.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>

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>