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>

There's no such thing as XferNotReady(SETUP), we
can safely drop all that code with no problems
whatsoever.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We can return early from each if () branch
and split the special cases for clarity. While
at that also add a comment to the delayed_status
case.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When returning from ep0_queue, we have an
unnecessary ret variable which is always
zero. Remove it.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As per databook, ACCEPT{U1,U2}ENA bits should be set after receiving
SetConfiguration Command.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

set_halt for ep0 is called to stall a deferred control responses by the
gadget.  We already have a function to stall default control endpoint.
This patch points set_halt for ep0 to the already available function.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NMichel Sanches <michel.sanches@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In case we try to start an invalid test mode, we
will call dwc3_ep0_stall_and_restart() but we will
also call dwc3_ep0_out_start() which will start
a second transfer on ep0.

Let's prevent any problems by returning early in
the error case.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

resource_index is more human readable. No
functional changes.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

That's a much more intuitive name as that function
is only called at the completion of a Status Phase.

It also matches dwc3_ep0_complete_data() for
the completion of Data Phase.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

USB is always little endian, but this driver
could run on non little endian cpus. Let's
be carefull with that.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

There's no need for returning early. Instead,
we can call dwc3_ep0_stall_and_restart()
conditionally.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

s/has/have. No functional changes, just
a typo fix on a code comment.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

On our Transfer Not Ready handlers, only
dwc3_ep0_do_control_status() had a different
list of parameters.

Align on the parameters in order to keep consistency.

No functional changes.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

IS_ALIGNED provides a much faster operation for
checking proper size alignment then a modulo
operation. Let's use it.
Reported-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When DWC3_EP_PENDING_REQUEST flag is set for a Control OUT Data
phase transfer, we would be missing the proper handling for
unaligned OUT requests, thus hanging a transfer.

Since proper handling is already done on dwc3_ep0_do_control_data(),
we simply re-factor that function so it can be re-used from
__dwc3_gadget_ep0_queue().
Reported-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

we're now have DWC3_EP0_BOUNCE_SIZE to tell
us the actual size of the bufer. Let's use that
instead of ep0 wMaxPacketSize.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Remove redundant pointer to struct usb_endpoint_descriptor.
Signed-off-by: NIdo Shayevitz <idos@codeaurora.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This is basically a noop for DWC3. We don't have
to do anything. Basically we test if the request
parameters are correct, cache the Isochronous
Delay and return success.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch implements Set SEL Standard Request
support for dwc3 driver. It needs to issue a command
to the controller passing the timing we received on
the data phase of the Set SEL request.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

On device loading the driver enables LPM and the acceptance of U1 and U2
states. The [Set|Clear]Feature requests for "U1/U2" are forwarded
directly to the hardware and allow / forbid the initiation of the low
power links.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Without this default case returning an error,
thus replying with a stall, we would fail
USB30CV TD 9.11 Bad Feature test case.

Cc: stable@vger.kernel.org
Signed-off-by: NGerard Cauvy <g-cauvy1@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

due to a HW limitation we have a bounce buffer for ep0
out transfers which are not aligned with MaxPacketSize.

On such case we were not increment r->actual as we should.

This patch fixes that mistake.

Cc: stable@vger.kernel.org
Signed-off-by: NFelipe Balbi <balbi@ti.com>

To allow ep0 out transfers of upto bounce buffer size
instead of maxpacketsize, use the transfer size as multiple
of ep0 maxpacket size.

Cc: stable@vger.kernel.org
Signed-off-by: NMoiz Sonasath <m-sonasath@ti.com>
Signed-off-by: NPartha Basak <p-basak2@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Transfer resource index is cleared in hardware when XFERCOMPLETE
event is generated, so clear the driver's res_trans_idx variable
immediately after that event is received. The upcoming hibernation
patches depend on this change.
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

trivial patch, no functional changes
Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

those routines have everything we need to map/unmap
USB requests and it's better to use them.

In order to achieve that, we had to add a simple
change on how we allocate and use our setup buffer;
we cannot allocate it from coherent anymore otherwise
the generic map/unmap routines won't be able to easily
know that the GetStatus request already has a DMA
address.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

this will get rid of a useless memcpy on
IRQ handling, thus improving driver performance.

Tested with OMAP5430 running g_mass_storage on
SuperSpeed and HighSpeed.

Note that we are removing the little endian access
of the TRB and all accesses will be in System endianness,
if there happens to be a system in BE, bit 12 of GSBUSCFG0
should be set so that HW does byte invariant BE accesses
when fetching TRBs.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When host requests us to enter a test mode,
we cannot directly enter the test mode before
Status Phase is completed, otherwise the core
will never be able to deliver the Status ZLP
to host, because it has already entered the
requested Test Mode.

In order to fix the error, we move the actual
start of Test Mode right after we receive
Transfer Complete event of the status phase.
Signed-off-by: NGerard Cauvy <g-cauvy1@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>