If the request->length is zero, a ZLP should already be sent due to that
and another ZLP is not needed to terminate the transfer.

Fixes: 04c03d10 ("usb: dwc3: gadget: handle request->zero")
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

instead of using:

	if (condition) {
		dev_WARN_ONCE(dev, true, "foo");
		return -EINVAL;
	}

let's use:

	if (dev_WARN_ONCE(dev, condition, "foo"))
		return -EINVAL;
Signed-off-by: NFelipe Balbi <balbi@ti.com>

So far, dwc3 has always missed request->zero
handling for every endpoint. Let's implement
that so we can handle cases where transfer must
be finished with a ZLP.

Note that dwc3 is a little special. Even though
we're dealing with a ZLP, we still need a buffer
of wMaxPacketSize bytes; to hide that detail from
every gadget driver, we have a preallocated buffer
of 1024 bytes (biggest bulk size) to use (and
share) among all endpoints.
Reported-by: NRavi B <ravibabu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

It just ocurred to me that dwc3 already gives a
really hint of when a setup packet is pending and
that's the SETUP_PENDING TRB Status for EP0 IRQs.

Fix setup_packet_pending initialization based on
that. While at that, also make sure the comment in
gadget.c matches what code is doing.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In dwc3_cleanup_done_reqs() we expect that all
iterations of our while (1) loop will find a valid
struct dwc3_request *. In case we don't, we're
dumping a WARN_ON_ONCE() splat so that people report
the failure.

This patch is a simple cleanup converting:

	if (!req) {
		WARN_ON_ONCE(1);
		return 1;
	}

to:

	if (WARN_ON_ONCE(!req))
		return 1;

which is a little easier to read.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The last few dev_dbg() messages are converted to
tracepoints and we can finally ignore dev_dbg()
messages during debug sessions.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

By moving our sanity checks our internal function
__dwc3_gadget_ep_queue() we can simplify the
externally visible API while also making sure that
callers of __dwc3_gadget_ep_queue() also make use of
the same checks.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Because interrupt endpoints usually transmit such
small amounts of data, it seems pointless to prestart
transfers and try to get speed improvements. This
patch also sorts out a problem with CDC ECM function
where its notification endpoint gets stuck in busy
state and we continuously issue Update Transfer
commands.

Fixes: 8a1a9c9e ("usb: dwc3: gadget: start transfer on XFER_COMPLETE")
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In some SoCs, dwc3 is implemented as a USB2.0 only
core, meaning that it can't ever achieve SuperSpeed.

Currect driver always sets gadget.max_speed to
USB_SPEED_SUPER unconditionally. This can causes
issues to some Host stacks where the host will issue
a GetBOS() request and we will reply with a BOS
containing Superspeed Capability Descriptor.

At least Windows seems to be upset by this fact and
prints a warning that we should connect $this device
to another port.

[ balbi@ti.com : rewrote entire commit, including
source code comment to make a lot clearer what the
problem is ]

Cc: <stable@vger.kernel.org>
Signed-off-by: NBen McCauley <ben.mccauley@garmin.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This reverts commit 8f2c9544.

As it breaks g_ether on my Baytrail FFRD8 device. Everything starts out
fine, but after a bit of data has been transferred it just stops
flowing.

Note that I do get a bunch of these "NOHZ: local_softirq_pending 08"
when booting the machine, but I'm not really sure if they're related
to this problem.

Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This reverts commit 70f3a9ca.

That commit was causing a lockdep splat with g_ether and that
was interfering with proper functionality.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We *know* our threads executes with our IRQs
disabled. We really don't need to use the _irqsave()
variant of spin_lock().
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Instead of limiting __dwc3_gadget_kick_transfer() to
Xfer Complete, we can try to issue Update Transfer
command from Xfer In Progress too.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If we get a Xfer Not Ready event with reason
"Transfer Active" it means endpoint is still
transferring data and we can use that to issue
update transfer for this particular endpoint
in case we have pending requests in our queue.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

if by the time we get to XFER_COMPLETE we have
pending requests to be processed, instead of waiting
for a following XFER_NOT_READY, let's start the request
right away and, maybe, save the time of a few NAKs
due to lack of started transfers.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We shouldn't return -EBUSY, that's used only internally
when the core still has transfers in flight on a given
endpoint.

Also, combine the error reporting so that we don't have
to duplicate it.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Instead of clearing DWC3_PENDING_REQUEST when
we start transfer, let's do it when the request
is actually queued, that way we know for sure
that we're clearing in the right time.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In an attempt to make dwc3 slightly faster, let's
start usb_requests as soon as they come as that will
let us avoid a XFER_NOT_READY event and save a little
bit of time.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

by moving trace_dwc3_ep_queue() from dwc3_gadget_ep_queue()
to __dwc3_gadget_ep_queue() after usb_request is properly
initialized, makes for a better output always showing a
request with 0 actual and -115 (-EINPROGRESS) status.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Using spin_lock() in hard irq handler is pointless
and causes a BUG() in RT (real-time) configuration
so get rid of it.

The reason it's pointless is because the driver is
basically accessing register which is, anyways,
atomic.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Convert endpoint configuration to new capabilities model.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add chained TRB support to ep0. Now TRB's can be chained just by
invoking _dwc3_ep0_start_trans_ with 'chain' parameter set to true.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We should only change endpoint names when we
actually manage to enable/disable it.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We have a "Enabling %s" trace when enabling an endpoint
but that message felt lonely without a matching
"Disabling %s". Add it.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In case of non-Isochronous transfers, we don't
want to clear DWC3_EP_BUSY flag until XferComplete
event. That's because XferInProgress was only enabled
so we can recycle TRBs and usb_requests quicker, but
there are still other pending requests being transferred.

In order to make sure we don't allow for another StartTransfer
command while the HW is still processing other transfers,
we must keep DWC3_EP_BUSY flag set and this what this patch
does.

Fixes: f3af3651 (usb: dwc3: gadget: always enable IOC on
	bulk/interrupt transfers)
Cc: <stable@vger.kernel.org> # v3.15+
Reported-by: Nsundeep subbaraya <sundeep.lkml@gmail.com>
Tested-by: Nsundeep subbaraya <sundeep.lkml@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We need to return error to caller if command is not sent to
controller succesfully.
Signed-off-by: NSubbaraya Sundeep Bhatta <sbhatta@xilinx.com>
Fixes: 72246da4 (usb: Introduce DesignWare USB3 DRD Driver)
Cc: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We need to return error to caller if command is not sent to
controller succesfully.
Signed-off-by: NSubbaraya Sundeep Bhatta <sbhatta@xilinx.com>
Fixes: b09bb642 (usb: dwc3: gadget: implement Global Command support)
Cc: <stable@vger.kernel.org> #v3.5+
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Now that we're using XFERINPROGRESS for all endpoint
types (except Control), we will *always* be completing
one TRB at a time, so it's safe to remove the loop
from dwc3_cleanup_done_reqs.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Delete private selfpowered variable, and use common one.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

commit 8e74475b (usb: dwc3: gadget: use udc-core's
reset notifier) added support for the new UDC core's
reset notifier to dwc3 but while at it, it removed
a spin_lock() from dwc3_reset_gadget() which might
cause an unbalanced spin_unlock() further down the line

Fixes: 8e74475b (usb: dwc3: gadget: use udc-core's reset notifier)
Cc: <stable@vger.kernel.org> # v3.19
Signed-off-by: NFelipe Balbi <balbi@ti.com>

By moving all dev_vdbg() to tracepoints, we
can finally get rid of dev_vdbg() usage from
dwc3.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

if an unknown IRQ event is triggered, that means
the HW is really misbehaving. Instead of printing
a debug message, let's WARN() so users report
when that happens.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We already have both ret and dwc defined in this
same function.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This
means, the max TRBs that can be submitted for an EP is fixed to 32. Since the
request queue for an EP is a linked list, any number of requests can be queued
to it by the gadget layer.  However, the dwc3 driver must not submit TRBs more
than the pool it has created for. This limit wasn't respected when SG was used
resulting in submitting more than the max TRBs, eventually leading to
non-transfer of the TRBs submitted over the max limit.

Root cause:
When SG is used, there are two loops iterating to prepare TRBs:
 - Outer loop over the request_list
 - Inner loop over the SG list
The code was missing break to get out of the outer loop.

Fixes: eeb720fb (usb: dwc3: gadget: add support for SG lists)
Cc: <stable@vger.kernel.org> # v3.9+
Signed-off-by: NAmit Virdi <amit.virdi@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
only when it is the last TRB being prepared from the last dwc3_request entry.

The current implementation uses list_is_last to check if the dwc3_request is the
last entry from the request_list. However, list_is_last returns false for the
last entry too. This is because, while preparing the first TRB from a request,
the function dwc3_prepare_one_trb modifies the request's next and prev pointers
while moving the URB to req_queued. Hence, list_is_last always returns false no
matter what.

The correct way is not to access the modified pointers of dwc3_request but to
use list_empty macro instead.

Fixes: e5ba5ec8 (usb: dwc3: gadget: fix scatter gather implementation)
Signed-off-by: NAmit Virdi <amit.virdi@st.com>
Cc: <stable@vger.kernel.org> # v3.9+
Signed-off-by: NFelipe Balbi <balbi@ti.com>

dwc3_gadget_init_hw_endpoints calls dwc3_alloc_trb_pool only if epnum is not
equal to 0 or 1. Hence, rechecking it in the called function is redundant.
Signed-off-by: NAmit Virdi <amit.virdi@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Fixed a typo in comments
Signed-off-by: NMickael Maison <mickael.maison@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Replace usb_gadget_driver's disconnect with udc-core's reset notifier at
bus reset handler.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

HIRD threshold should be configurable by different platforms.

From DesignWare databook:
When HIRD_Threshold[4] is set to 1b1 and HIRD value is greater than or
equal to the value in HIRD_Threshold[3:0], dwc3 asserts output signals
utmi_l1_suspend_n to put PHY into Deep Low-Power mode in L1.

When HIRD_Threshold[4] is set to 1b0 or the HIRD value is less than
HIRD_Threshold[3:0], dwc3 asserts output signals utmi_sleep_n on L1.
Signed-off-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When parameter DWC_USB3_LPM_ERRATA_ENABLE is enabled in Andvanced
Configuration of coreConsultant, it supports of xHCI BESL Errata Dated
10/19/2011 is enabled in host mode. In device mode it adds the capability
to send NYET response threshold based on the BESL value received in the LPM
token, and the threhold is configurable for each soc platform.

This patch adds an entry that soc platform is able to define the lpm
capacity with their own device tree or bus glue layer.

[ balbi@ti.com : added devicetree documentation, spelled threshold
		completely, made sure threshold is only applied to
		proper core revisions. ]
Signed-off-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>