In case host sends us an unsupported test mode, we
*must* stall this request. This will tell the host
that the selector is invalid and we won't put the
controller in unsupported test modes which could
have undetermined side-effects.
Signed-off-by: NFei Yang <fei.yang@intel.com>
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>

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>

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>

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>

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>

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>

Use chained TRB mechanism to handle non maxpacket aligned transfers
greater than bounce buffer size. With this the first TRB will be programmed
to receive 'ALIGN(ur->length - maxp, maxp)' data and the second TRB
will be programmed to receive the remaining data using bounce buffer.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.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>

No functional change. Added a new parameter in _dwc3_ep0_start_trans_ to
indicate whether the TRB is a chained TRB or last TRB. This is in
preparation for adding chained TRB support for ep0.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

No functional change. This is in preparation for handling non maxpacket
aligned transfers greater than bounce buffer size. This is basically to
avoid code duplication when using chained TRB transfers to handle
non maxpacket aligned transfers greater than bounce buffer size.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

No functional change. Used _roundup_ macro to calculate the transfer
size aligned to maxpacket in  dwc3_ep0_complete_data. It also makes it
similar to how transfer size is calculated in __dwc3_ep0_do_control_data.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

DWC3 uses bounce buffer to handle non max packet aligned OUT transfers and
the size of bounce buffer is 512 bytes. However if the host initiates OUT
transfers of size more than 512 bytes (and non max packet aligned), the
driver throws a WARN dump but still programs the TRB to receive more than
512 bytes. This will cause bounce buffer to overflow and corrupt the
adjacent memory locations which can be fatal.

Fix it by programming the TRB to receive a maximum of DWC3_EP0_BOUNCE_SIZE
(512) bytes.

Cc: <stable@vger.kernel.org> # 3.4+
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This fixes an issue introduced in commit b23c8439 (usb: dwc3:
gadget: fix DEPSTARTCFG for non-EP0 EPs) that made sure we would
only use DEPSTARTCFG once per SetConfig.

The trick is that we should use one DEPSTARTCFG per SetConfig *OR*
SetInterface. SetInterface was completely missed from the original
patch.

This problem became aparent after commit 76e838c9 (usb: dwc3:
gadget: return error if command sent to DEPCMD register fails)
added checking of the return status of device endpoint commands.

'Set Endpoint Transfer Resource' command was caught failing
occasionally. This is because the Transfer Resource
Index was not getting reset during a SET_INTERFACE request.

Finally, to fix the issue, was we have to do is make sure that
our start_config_issued flag gets reset whenever we receive a
SetInterface request.

To verify the problem (and its fix), all we have to do is run
test 9 from testusb with 'testusb -t 9 -s 2048 -a -c 5000'.
Tested-by: NHuang Rui <ray.huang@amd.com>
Tested-by: NSubbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Fixes: b23c8439 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs)
Cc: <stable@vger.kernel.org> # v3.2+
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
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 6856d30c (usb: dwc3: ep0: return early
on NULL requests) tried to fix a minor corner
case where we could dereference a NULL pointer
but it also ended up introducing some dead code.

Unfortunately, that dead code, if reached, could
end up starving the endpoint request list because
a request would never be given back when it should.

Fix this by moving the check for empty request list
before its first use.
Reported-by: NDave Jones <davej@redhat.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Fix the following checkpatch warning.

  WARNING: break is not useful after a goto or return
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add TRB tracepoints for ep0 TRBs as that
might help finding bugs with ep0 handling.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

tracing infrastructure already adds those for us.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

According to Section 8.5.3.2 of the USB 2.0 specification,
a USB device must terminate a Data Phase with either a
short packet or a ZLP (if the previous transfer was
a multiple of wMaxPacketSize).

For reference, here's what the USB 2.0 specification, section
8.5.3.2 says:

"
8.5.3.2 Variable-length Data Stage

A control pipe may have a variable-length data phase
in which the host requests more data than is contained
in the specified data structure. When all of the data
structure is returned to the host, the function should
indicate that the Data stage is ended by returning a
packet that is shorter than the MaxPacketSize for the
pipe. If the data structure is an exact multiple of
wMaxPacketSize for the pipe, the function will return
a zero-length packet to indicate the end of the Data
stage.
"
Signed-off-by: NFelipe Balbi <balbi@ti.com>

if our list of requests is empty, return early.

There's really nothing to be done in case our
request list is empty anyway because the only
situation where we our list is empty, is when
we're transferring ZLPs.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

According to our Gadget Framework API documentation,
->set_halt() *must* return -EAGAIN if we have pending
transfers (on either direction) or FIFO isn't empty (on
TX endpoints).

Fix this bug so that the mass storage gadget can be used
without stall=0 parameter.

This patch should be backported to all kernels since v3.2.

Cc: <stable@vger.kernel.org> # v3.2+
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

dwc3_gadget_ep0_set_halt() will be called without
locks held in some cases, so we must hold the lock
on our own. While at that, also add a version without
locks to be called in certain conditions.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When we're debugging hard-to-reproduce and time-sensitive
use cases, printk() poses too much overhead. That's when
the kernel's tracing infrastructure comes into play.

This patch implements a few initial tracepoints for the
dwc3 driver. More traces can be added as necessary in order
to ease the task of debugging dwc3.
Reviewed-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Those functions are only using within debugging
messages, grouping them into debug.h makes sense.

While at that, also add missing multiple inclusion
guard.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The dwc3 UDC driver doesn't implement endpoint wedging correctly.
When an endpoint is wedged, the gadget driver should be allowed to
clear the wedge by calling usb_ep_clear_halt().  Only the host is
prevented from resetting the endpoint.

This patch fixes the implementation.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NPratyush Anand <pratyush.anand@st.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

These aren't necessary after switch and if blocks.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

before changing to configured state, we need
to wait until gadget driver has had a chance
to process the request.

In case of USB_GADGET_DELAYED_STATUS, that means
we need to defer usb_gadget_set_state() until
the upcoming usb_ep_queue().
Reported-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In case we're switching back to USB_STATE_ADDRESS
from USB_STATE_CONFIGURED (if host sends
a set configuration command for configuration
zero), we should only switch if the request
is successfully processed by the gadget driver.
Reported-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This is a Linux-only driver which makes use
of GPL-only symbols. It makes no sense to
maintain Dual BSD/GPL licensing for this driver.

Considering that the amount of work to use this
driver in any different operating system would likely
be as large as developing the driver from scratch and
considering that we depend on GPL-only symbols, we
will switch over to a GPL v2-only license.

Cc: Anton Tikhomirov <av.tikhomirov@samsung.com>
Acked-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We can reuse the generic implementation via
our struct usb_gadget.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

make use of the previously introduced gadget->state
field.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

drivers/usb/dwc3/ep0.c: In function `__dwc3_ep0_do_control_data':
drivers/usb/dwc3/ep0.c:905: error: `typeof' applied to a bit-field

Looks like a gcc-3.4.5/sparc64 bug.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In case of ep0 out, if length is not aligned to maxpacket size then we use
dwc->ep_bounce_addr for dma transfer and not request->dma. Since, we have
alreday done memcpy from dwc->ep0_bounce to request->buf, so we do not need to
issue cache sync function. In fact, cache sync function will bring wrong data
in request->buf from request->dma in this scenario.

So, cache sync function must not be executed in case of ep0 bounced.

Cc: <stable@vger.kernel.org> # v3.4 v3.5
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When issuing SetStall on ep0, we must make sure to
reinitialize all flags on physical ep1 too.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

commit 68d3e668 (usb: dwc3: ep0: fix for possible early
delayed_status) added handling for early delayed status,
but the current code only works because so far delayed
status will always be on the IN direction.

This patch makes the code more robust by making sure that
we can handle all directions properly.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Due to the late Silicon limitation found, we are
now pre-starting DATA phase's TRBs. If, still, we
get XferNotReady(DATA) we will ignore it unless
we're getting it for the wrong direction.

In that case we must keep the error case handling
plus add a ENDTRANSFER command to forcefully end
the Data TRB we started previously, then continue
to SetStall and so on.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We uncovered a limitation of this core WRT to the
Link Layer Compliance Suite's TD7.06.

On that test, host will start a GetDescriptor(DEVICE)
standard request, but it will do so only on the
SETUP phase, meaning there will *NOT* be any DATA or
STATUS phases.

The idea of the test is to verify robustness of the
IP WRT framing errors, so the test will send a
sequence of different SETUP_DPs each with a different
framing error and the Suite expects us to be able to
receive all SETUP_DPs with no timeouts.

This core, has the ability to tell us which phase the
host is expecting before we start it. Whenever we
receive a TP or DP when no transfers are cached on
the internal IP's caches, the IP will generate a
XferNotReady event with status informing us (in case
of physical ep0/ep1) if it's related to DATA or STATUS
phases - SETUP phase is expected to be prestarted.

Because we're always waiting for XferNotReady
events for DATA and STATUS phases, we will never
be able to know that the Host wants to start another
SETUP phase instead, which will render us "not
compliant" with TD7.06.

In order to "fix" the problem we must not rely
on XferNotReady events for the DATA phase  and try
to always pre-start DATA transfers on physical
endpoints 0 and 1. If host goes back to SETUP phase
from DATA phase we will receive a XferComplete for
that phase with TRB's status set to SETUP_PENDING,
which is only useful for printing a debugging log as
the core expects us to still go through to the STATUS
phase, initiate a CONTROL_STATUS TRB just so it
completes right away and, only then, we go back to
the pending SETUP phase.

SNPS has decided to modify the programming model of
the core so that on-demand DATA phases will not be
supported anymore. Note that this limitation does not
affect 2-stage transfers, meaning that if TD7.06 would
start a 2-stage transfer instead of a 3-stage transfer,
we would receive a "fake" XferNotReady(STATUS) which
would complete right after being initiated with
SETUP_PENDING status.

Other endpoints are also not affected, so we can still
use on-demand transfers on Bulk/Isoc/Interrupt endpoints.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Databook doesn't say we should stall if we
get XferNotReady(STATUS) while we're expecting
something else.

Instead of stalling and restarting, tests have
proven that ignoring the event is far more
effective.

This problem has been caught while rewriting
ep0 handling in order we pass Link Layer TD7.6.
Signed-off-by: NFelipe Balbi <balbi@ti.com>