Now that we modified the code to fix a race condition, it's clear that
DWC3_EP_END_TRANSFER_PENDING is unnecessary, considering that
DWC3_EP_TRANSFER_STARTED will remain set until End Transfer completes.
Tested-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

There is a rare race condition that may happen during a Disconnect
Interrupt if we have a started request that happens to be
dequeued *after* completion of End Transfer command. If that happens,
that request will be left waiting for completion of an End Transfer
command that will never happen.

If End Transfer command has already completed before, we are safe to
giveback the request straight away.
Tested-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have a proper flag for testing that we have a valid transfer in
flight, let's use that instead.

This patch is in preparation to fix a rare race condition that happens
upon Disconnect Interrupt.
Tested-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We must wait until End Transfer completes in order to clear
DWC3_EP_TRANSFER_STARTED, otherwise we may confuse the driver.

This patch is in preparation to fix a rare race condition that happens
upon Disconnect Interrupt.
Tested-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Now that we have req->status, we don't need this extra flag
anymore. It's safe to remove it.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Queueing the same request twice can introduce hard-to-debug
problems. At least one function driver - Android's f_mtp.c - is known
to cause this problem.

While that function is out-of-tree, this is a problem that's easy
enough to avoid.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This patch starts tracking dwc3_request status. A following patch will
build on top of this to prevent a request from being queued twice.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The AM654 SoC contains a DWC3 controller with TI specific
wrapper. Add support for that.

Unlike the Keystone 2 case, for AM654 We don't need to
process any IRQs for basic USB operation.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

On v3.10a in dual-role mode, if port is in device mode
and gadget driver isn't loaded, the OTG event interrupts don't
come through.

It seems that if the core is configured to be OTG2.0 only,
then we can't leave the DCFG.DEVSPD at Super-speed (default)
if we expect OTG to work properly. It must be set to High-speed.

Fix this issue by configuring DCFG.DEVSPD to the supported
maximum speed at gadget init. Device tree still needs to provide
correct supported maximum speed for this to work.

This issue wasn't present on v2.40a but is seen on v3.10a.
It doesn't cause any side effects on v2.40a.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Add a MSM8998 specific DT compatible so that we can properly bind to the
device and enable the USB controller.
Reviewed-by: NAndy Gross <andy.gross@linaro.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NJeffrey Hugo <jhugo@codeaurora.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Currently the link_state is uninitialized and the default value is 0(U0)
before the first time we start the udc, and after we start the udc then
 stop the udc, the link_state will be undefined.
We may have the following warnings if we start the udc again with
an undefined link_state:

WARNING: CPU: 0 PID: 327 at drivers/usb/dwc3/gadget.c:294 dwc3_send_gadget_ep_cmd+0x304/0x308
dwc3 100e0000.hidwc3_0: wakeup failed --> -22
[...]
Call Trace:
[<c010f270>] (unwind_backtrace) from [<c010b3d8>] (show_stack+0x10/0x14)
[<c010b3d8>] (show_stack) from [<c034a4dc>] (dump_stack+0x84/0x98)
[<c034a4dc>] (dump_stack) from [<c0118000>] (__warn+0xe8/0x100)
[<c0118000>] (__warn) from [<c0118050>](warn_slowpath_fmt+0x38/0x48)
[<c0118050>] (warn_slowpath_fmt) from [<c0442ec0>](dwc3_send_gadget_ep_cmd+0x304/0x308)
[<c0442ec0>] (dwc3_send_gadget_ep_cmd) from [<c0445e68>](dwc3_ep0_start_trans+0x48/0xf4)
[<c0445e68>] (dwc3_ep0_start_trans) from [<c0446750>](dwc3_ep0_out_start+0x64/0x80)
[<c0446750>] (dwc3_ep0_out_start) from [<c04451c0>](__dwc3_gadget_start+0x1e0/0x278)
[<c04451c0>] (__dwc3_gadget_start) from [<c04452e0>](dwc3_gadget_start+0x88/0x10c)
[<c04452e0>] (dwc3_gadget_start) from [<c045ee54>](udc_bind_to_driver+0x88/0xbc)
[<c045ee54>] (udc_bind_to_driver) from [<c045f29c>](usb_gadget_probe_driver+0xf8/0x140)
[<c045f29c>] (usb_gadget_probe_driver) from [<bf005424>](gadget_dev_desc_UDC_store+0xac/0xc4 [libcomposite])
[<bf005424>] (gadget_dev_desc_UDC_store [libcomposite]) from[<c023d8e0>] (configfs_write_file+0xd4/0x160)
[<c023d8e0>] (configfs_write_file) from [<c01d51e8>] (__vfs_write+0x1c/0x114)
[<c01d51e8>] (__vfs_write) from [<c01d5ff4>] (vfs_write+0xa4/0x168)
[<c01d5ff4>] (vfs_write) from [<c01d6d40>] (SyS_write+0x3c/0x90)
[<c01d6d40>] (SyS_write) from [<c0107400>] (ret_fast_syscall+0x0/0x3c)
Signed-off-by: NZeng Tao <prime.zeng@hisilicon.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

OUT endpoint requests may somtimes have this flag set when
preparing to be submitted to HW indicating that there is an
additional TRB chained to the request for alignment purposes.
If that request is removed before the controller can execute the
transfer (e.g. ep_dequeue/ep_disable), the request will not go
through the dwc3_gadget_ep_cleanup_completed_request() handler
and will not have its needs_extra_trb flag cleared when
dwc3_gadget_giveback() is called.  This same request could be
later requeued for a new transfer that does not require an
extra TRB and if it is successfully completed, the cleanup
and TRB reclamation will incorrectly process the additional TRB
which belongs to the next request, and incorrectly advances the
TRB dequeue pointer, thereby messing up calculation of the next
requeust's actual/remaining count when it completes.

The right thing to do here is to ensure that the flag is cleared
before it is given back to the function driver.  A good place
to do that is in dwc3_gadget_del_and_unmap_request().

Fixes: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize")
Cc: stable@vger.kernel.org
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We see dwc3 endpoint stopped by unwanted irq during
suspend resume test, which is caused dwc3 ep can't be started
with error "No Resource".

Here, add synchronize_irq before suspend to sync the
pending IRQ handlers complete.
Signed-off-by: NBo He <bo.he@intel.com>
Signed-off-by: NYu Wang <yu.y.wang@intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Move Synopsys HAPS platform device IDs to pci_ids.h so that both
drivers/pci/quirks.c and dwc3-haps driver can reference these IDs.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In stream mode, when fast-forwarding TRBs, the stream number
is not cleared causing the new stream to not get assigned. So
we don't want controller to carry on transfers when short packet
is received. So disable the CSP for stream capable endpoint.

This is based on the 3.30a Programming guide, where table 3-1
device descriptor structure field definitions says for CSP bit
If this bit is 0, the controller generates an XferComplete event
and remove the stream. So if we keep CSP as 1 then switching between
streams would not happen as in stream mode, when fast-forwarding
TRBs, the stream number is not cleared causing the new stream to not get
assigned.
Signed-off-by: NTejas Joglekar <joglekar@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Commit 211f658b ("usb: dwc3: pci: Use devm functions to get
the phy GPIOs") changed the code to claim the PHY GPIOs permanently
for Intel Baytrail devices.

This causes issues when the actual PHY driver attempts to claim the
same GPIO descriptors. For example, tusb1210 now fails to probe with:

  tusb1210: probe of dwc3.0.auto.ulpi failed with error -16 (EBUSY)

dwc3-pci needs to turn on the PHY once before dwc3 is loaded, but
usually the PHY driver will then hold the GPIOs to turn off the
PHY when requested (e.g. during suspend).

To fix the problem, this reverts the commit to restore the old
behavior to put the GPIOs immediately after usage.

Link: https://www.spinics.net/lists/linux-usb/msg174681.html
Cc: stable@vger.kernel.org
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The missed break statement in the outer switch makes the code fall through
always and thus always same value will be printed.

Besides that, compiler warns about missed fall through marker:

drivers/usb/dwc3/./trace.h: In function ‘trace_raw_output_dwc3_log_trb’:
drivers/usb/dwc3/./trace.h:246:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
    switch (pcm) {
    ^~~~~~

Add the missing break statement to work correctly without compilation
warnings.

Fixes: fa8d965d ("usb: dwc3: trace: pretty print high-bandwidth transfers too")
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Implement the new frame_number API to report the isochronous interval
frame number. This patch checks and reports the interval in which the
isoc transfer was transmitted or received via the Isoc-First TRB SOF
number field.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Availability of TRB's is calculated using dwc3_calc_trbs_left(), which
determines total available TRB's based on the HWO bit set in a TRB.

In the present code, __dwc3_prepare_one_trb() is called with a TRB which
needs to be prepared for transfer. This __dwc3_prepare_one_trb() calls
dwc3_calc_trbs_left() to determine total available TRBs and set IOC bit
if the total available TRBs are zero. Since the present working TRB (which
is passed as an argument to __dwc3_prepare_one_trb() )  doesn't yet have
the HWO bit set before calling dwc3_calc_trbs_left(), there are chances
that dwc3_calc_trbs_left() wrongly calculates this present working TRB
as free(since the HWO bit is not yet set) and returns the total available
TRBs as greater than zero (including the present working TRB). This could
be a problem.

This patch corrects the above mentioned problem in __dwc3_prepare_one_trb()
by increementing the dep->trb_enqueue at the last (after preparing the TRB)
instead of increementing at the start and setting the IOC bit only if the
total available TRBs returned by dwc3_calc_trbs_left() is 1 . Since we are
increementing the dep->trb_enqueue at the last, the present working TRB is
also considered as available by dwc3_calc_trbs_left() and non zero value is
returned . So, according to the modified logic, when the total available
TRBs is equal to 1 that means the total available TRBs in the pool are 0.
Signed-off-by: NAnurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Reviewed-by: NThinh Nguyen <thinhn@synopsys.com>
Tested-by: NTejas Joglekar <tejas.joglekar@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The stream capable endpoints require stream id to be given
when issuing START TRANSFER. While issuing no-op trb the
stream id is not yet known, so don't issue no-op trb's on
stream capable endpoints.
Signed-off-by: NAnurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

For stream capable endpoints, stream id related information
needs to be updated into DEPCMD while issuing START TRANSFER.
This patch does the same.
Signed-off-by: NAnurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Gadget driver may take an unbounded amount of time to queue requests
after XferNotReady. This is important for isochronous endpoints which
need to be started for a specific (micro-)frame.

If we fail to start a transfer for isochronous endpoint, let's try
queueing to a future interval and see if that helps. We will stop trying
if we fail a start transfer for 5 intervals in the future.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Running out of requests on isochronous endpoints is part of normal
operation. We don't really need to know about it every time it
happens.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

They are much more useful in hexadecimal than in decimal. Moreover,
generic commands are already logged in hex.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Sometimes, errors happen when kicking transfers from
__dwc3_gadget_start_isoc(). In those cases, we need to pass along the
error so gadget driver can make informed decisions.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Now that we have a list of cancelled requests, we can skip over TRBs
when END_TRANSFER command completes.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Whenever we have a request in flight, we can move it to the cancelled
list and later simply iterate over that list and skip over any TRBs we
find.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This list will host cancelled requests who still have TRBs being
processed.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Extract the logic for skipping over TRBs to its own function. This
makes the code slightly more readable and makes it easier to move this
call to its final resting place as a following patch.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Now that we track how many TRBs a request uses, it's easier to skip
over them in case of a call to usb_ep_dequeue(). Let's do so and
simplify the code a bit.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This will help us remove the wait_event() from our ->dequeue().
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Both flags are used for the same purpose in dwc3: appending an extra
TRB at the end to deal with controller requirements. By combining both
flags into one, we make it clear that the situation is the same and
that they should be treated equally.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In DWC_usb31 version 1.70a-ea06 and prior, for highspeed and fullspeed
isochronous IN, BIT[15:14] of the 16-bit microframe number reported by
the XferNotReady event are invalid. The driver uses this number to
schedule the isochronous transfer and passes it to the START TRANSFER
command. Because this number is invalid, the command may fail. If
BIT[15:14] matches the internal 16-bit microframe, the START TRANSFER
command will pass and the transfer will start at the scheduled time, if
it is off by 1, the command will still pass, but the transfer will start
2 seconds in the future. For all other conditions, the START TRANSFER
command will fail with bus-expiry.

In order to workaround this issue, we can test for the correct
combination of BIT[15:14] by sending START TRANSFER commands with
different values of BIT[15:14]: 'b00, 'b01, 'b10, and 'b11. Each
combination is 2^14 uframe apart (or 2 seconds). 4 seconds into the
future will result in a bus-expiry status. As the result, within the 4
possible combinations for BIT[15:14], there will be 2 successful and 2
failure START COMMAND status. One of the 2 successful command status
will result in a 2-second delay start. The smaller BIT[15:14] value is
the correct combination.

Since there are only 4 outcomes and the results are ordered, we can
simply test 2 START TRANSFER commands with BIT[15:14] combinations 'b00
and 'b01 to deduce the smaller successful combination.

Let test0 = test status for combination 'b00 and test1 = test status for
'b01 of BIT[15:14]. The correct combination is as follow:

if test0 fails and test1 passes, BIT[15:14] is 'b01
if test0 fails and test1 fails, BIT[15:14] is 'b10
if test0 passes and test1 fails, BIT[15:14] is 'b11
if test0 passes and test1 passes, BIT[15:14] is 'b00

Synopsys STAR 9001202023: Wrong microframe number for isochronous IN
endpoints.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Add a new field to dwc3 structure to track VERSIONTYPE. The VERSIONTYPE
is represented in ASCII in the 32-bit VERSIONTYPE register. In
DWC_usb31, sub releases for each version are tracked with VERSIONTYPE
such as "ea01" and "ea02".
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

DWC_usb31 and DWC_usb3 v3.30a and higher do not support OTG mode. If
the controller supports DRD but the dr_mode is not specified or set to
OTG, then set the mode to peripheral.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Allow extcon device, found by name, to provide DR status for USB.
This is needed, for example, in case of Intel Merrifield platform,
where the Intel Basin Cove PMIC provides an extcon device to communicate
the detected role.

Note, that the "linux,extcon-name" property name is only for kernel
internal use by X86/ACPI platform code and as such is not documented
in the device tree bindings.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Switch to device property for 'extcon' handling.
No functional change intended.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

It's not very useful to repeat a bunch of probe deferral errors. And
it's also not very useful to log "failed" without telling the error
code.
Signed-off-by: NBrian Norris <briannorris@chromium.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Support the option to disable USB2 LPM. Set xhci "usb2-lpm-disable"
property via "snps,usb2-lpm-disable" property.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

GUSB2PHYCFG.ENBLSLPM enables the controller to assert low power signals
to the PHY. Unless disabled via device property, explicitly set
GUSB2PHYCFG.ENBLSLPM as it may not be set by default.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>