Update various places where the speed is checked so that it takes into
account SuperSpeedPlus properly.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
The assignement of EP transfer resources was not handled properly in the
dwc3 driver. Commit aebda61871 ("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: aebda61871 ("usb: dwc3: Reset the transfer resource index on SET_INTERFACE")
Cc: <stable@vger.kernel.org> # v3.2+
Reported-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe 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: Felipe 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: Felipe 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: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe 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: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe 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: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe 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: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe 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: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe 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: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This fixes an issue introduced in commit b23c843992 (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 76e838c9f7 (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: Huang Rui <ray.huang@amd.com>
Tested-by: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Fixes: b23c843992 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs)
Cc: <stable@vger.kernel.org> # v3.2+
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Delete private selfpowered variable, and use common one.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 6856d30 (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: Dave Jones <davej@redhat.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Fix the following checkpatch warning.
WARNING: break is not useful after a goto or return
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Felipe 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: Felipe 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: Felipe 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe 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: Felipe 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: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe 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: Felipe 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: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Pratyush Anand <pratyush.anand@st.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
These aren't necessary after switch and if blocks.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Greg 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe 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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe 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: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This resolves the merge problems with:
drivers/usb/dwc3/gadget.c
drivers/usb/musb/tusb6010.c
that had been seen in linux-next.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
commit 68d3e66 (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: Felipe 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: Felipe 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: Felipe 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: Felipe 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: Felipe Balbi <balbi@ti.com>
As per databook, ACCEPT{U1,U2}ENA bits should be set after receiving
SetConfiguration Command.
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe 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: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Michel Sanches <michel.sanches@st.com>
Signed-off-by: Felipe 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: Felipe 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: Felipe 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: Felipe 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: Felipe Balbi <balbi@ti.com>
John Youn