It makes no sense to interrupt in the middle of
chained transfer. This patch just makes sure we
don't do that.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

trace already adds a newline character for us, we
don't need to do it ourselves.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

instead of limiting link TRB only to Isoc endpoints,
let's use it for all endpoint types, this way we are
more likely to transfer more data before a
XferComplete event.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

By moving our % DWC3_NUM_TRB operation to the
increment helpers, the rest of the driver can be
simplified.

It's also a good practice to make sure we will have
a single place dealing with details about how to
increment our enqueue and dequeue pointers.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Add three little helpers which will aid in making
the code slightly easier to read. One helper
increments enqueue pointer, another increments
dequeue pointer and the last one tests if we're
dealing with the last TRB.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

instead of using a bitwise and, let's rely on the %
operator since that's a lot more clear. Also, GCC
will optimize % 256 to nothing anyway.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

This makes it clear that we're dealing with a queue
of TRBs. No functional changes. While at that, also
rename start_slot to first_trb_index for similar
reasons.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Synopsys Databook says we should move link to U0
before issuing a Start Transfer command. We could
require the gadget driver to call
usb_gadget_wakeup() however I feel that changing all
gadget drivers to keep track of Link State and
conditionally call usb_gadget_wakeup() would be far
too much work. For now we will handle this at the
UDC level, but at some point composite.c should be
one handling this.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

we will need this from StartTransfer to make sure
link is in U0 before starting a transfer.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Synopsys Databook 2.60a has a note that if we're
sending an endpoint command we _must_ make sure that
DWC3_GUSB2PHY(n).SUSPHY bit is cleared.

This patch implements that particular detail.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

dwc3_send_gadget_ep_cmd() had three return
points. That becomes a pain to track when we need to
debug something or if we need to add more code
before returning.

Let's combine all three return points into a single
one just by introducing a local 'ret' variable.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

we don't plan on using multiple event buffers, but
if we find a good use case for it, this little trick
will help us avoid a loop in hardirq handler looping
for each and every event buffer.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

we will be using a single event buffer and that
renders ev_buffs array unnecessary. Let's remove it
in favor of a single pointer to a single event
buffer.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We never, ever route any of the other event buffers
so we might as well drop support for them.

Until someone has a real, proper benefit for
multiple event buffers, we will rely on a single
one. This also helps reduce memory footprint of
dwc3.ko which won't allocate memory for the extra
event buffers.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

request_list and req_queued were, well, weird naming
choices.

Let's give those better names and call them,
respectively, pending_list and started_list. These
new names better reflect what these lists are
supposed to do.

While at that also rename req->queued to req->started.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

CSP bit of TRB Control is useful for protocols such
CDC EEM/ECM/NCM where we're transferring in blocks
of MTU-sized requests (usually MTU is 1500 bytes).

We know we will always have a short packet after two
(for HS) wMaxPacketSize packets and, usually, we
will have a long(-ish) queue of requests (for our
g_ether gadget, we have at least 10
requests).

Instead of always stopping the queue processing to
interrupt, giveback and restart, let's tell dwc3 to
interrupt but continue processing following request
if we have anything already pending in the queue.

This gave me a considerable improvement of 40% on my
test setup.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

That FIFO resizing logic was added to support OMAP5
ES1.0 which had a bogus default FIFO size. I can't
remember the exact size of default FIFO, but it was
less than one bulk superspeed packet (<1024) which
would prevent USB3 from ever working on OMAP5 ES1.0.

However, OMAP5 ES1.0 support has been dropped by
commit aa2f4b16 ("ARM: OMAP5: id: Remove ES1.0
support") which renders FIFO resizing unnecessary.
Tested-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We were exitting the function before actually
renaming anything. While at that, also always leave
control endpoint un-renamed.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

It's a requirement that we release controller's lock
while calling gadget API function pointers. This
patch just fixes that long standing bug.
Signed-off-by: NJiebing Li <jiebing.li@intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Check that dwc->maximum_speed is set to a valid value. Also add an error
when we use it later if we encounter an invalid value.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Enable SuperSpeedPlus by programming the DCFG.speed and after
enumerating, set gadget->speed appropriately.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Update various places where the speed is checked so that it takes into
account SuperSpeedPlus properly.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

The assignement of EP transfer resources was not handled properly in the
dwc3 driver. Commit aebda618 ("usb: dwc3: Reset the transfer
resource index on SET_INTERFACE") previously fixed one aspect of this
where resources may be exhausted with multiple calls to SET_INTERFACE.
However, it introduced an issue where composite devices with multiple
interfaces can be assigned the same transfer resources for different
endpoints. This patch solves both issues.

The assignment of transfer resources cannot perfectly follow the data
book due to the fact that the controller driver does not have all
knowledge of the configuration in advance. It is given this information
piecemeal by the composite gadget framework after every
SET_CONFIGURATION and SET_INTERFACE. Trying to follow the databook
programming model in this scenario can cause errors. For two reasons:

1) The databook says to do DEPSTARTCFG for every SET_CONFIGURATION and
SET_INTERFACE (8.1.5). This is incorrect in the scenario of multiple
interfaces.

2) The databook does not mention doing more DEPXFERCFG for new endpoint
on alt setting (8.1.6).

The following simplified method is used instead:

All hardware endpoints can be assigned a transfer resource and this
setting will stay persistent until either a core reset or hibernation.
So whenever we do a DEPSTARTCFG(0) we can go ahead and do DEPXFERCFG for
every hardware endpoint as well. We are guaranteed that there are as
many transfer resources as endpoints.

This patch triggers off of the calling dwc3_gadget_start_config() for
EP0-out, which always happens first, and which should only happen in one
of the above conditions.

Fixes: aebda618 ("usb: dwc3: Reset the transfer resource index on SET_INTERFACE")
Cc: <stable@vger.kernel.org> # v3.2+
Reported-by: NRavi Babu <ravibabu@ti.com>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

This patch is needed in order to pass one test case
defined in the OTG Automated Compliance Test specification.

Specification location:
http://www.usb.org/developers/onthego/otgeh_compliance_plan_1_2.pdf

This test case uses PET Tool, and PET Tool is one USB hardware
equipment provided by MQP Electronics.

Test case id is 6.8.3 B-UUT Bypass Capacitance.

We must set this otg flag in order to be able to return OTG
descriptor during enumeration, otherwise this test case with
failed with below error: "Get OTG descriptor request stalled".
Signed-off-by: NJianqiang Tang <jianqiang.tang@intel.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

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>