In "usb: dwc3: remove special status request handling in ep0" I simplied
a few things and used the generic API for the status transfers. The bug
I introcuded here is that we queue now requests to dep[1] but we don't
clear that list in the stall+start case.
Actually we don't need to use dep[1] at all. We only did in the past to
talk to the correct endpoint (i.e. in or out). This is now take care of
in a diffent place within the ep0 code. So we could queue the in
transfers to dep[0] and don't use dep[1] at all.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The first access was correct, the second was wrong.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The GetStatus (STD)-request is handled the driver and uses a tiny hack
to send the two bytes long answer. This patch removes the custom hack
uses the normal usb_ep_queue() for that.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If we stall and restart we have to reset also this flag to 0 as there is
nothing pending anymore.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Sometimes the host might be trying to initiate Data or
Status phase for an older Control transfer. In such
situations we must STALL that transfer and restart
the state machine rather than letting such situation
go through the wire.
Signed-off-by: Felipe Balbi <balbi@ti.com>
I have talked to USB-IF about USB30CV issuing SetAddres()
with a device on Configured state and they have agreed on
changing USB30CV not to do so.
Adding back the STALL reply in such case and while at
that, also add a debugging message for an address which
is too large.
Signed-off-by: Felipe Balbi <balbi@ti.com>
our parameter structures need to be written to
HW, so instead of assuming little endian, we
convert those into bit shifts.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
DEPSTARTCFG for non-EP0 EPs must only be sent once per config
[ balbi@ti.com : changed config_start to start_config_issued ]
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some people think that this line is not compatible with the GPL. The
statement was required due to the Buenos Aires Convention and is now
deprecated. I remove it because it is said that it is pointless nowdays.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Use "ep0in" and "ep0out" instead "ep1in" and "ep0out" which is confusing
and not consistent with the remaining output.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We already give requests back in dwc3_ep0_stall_and_restart() so
doing it again here will most likely corrupt the list.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The way it was before was really meaningless.
Now it looks saner.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We don't need to care about direction on a two stage
transfer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
According to USB 3.0 Specification, a SetAddress()
while device is in Configured State has an unspecified
behavior (see Section 9.4.6). Still USB30CV wasn't
happy with my Stall reply.
To make that thing happy, just accept the SetAddress()
always. No problems have been observed thus far.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This flag will tell us which direction we're
expecting on the next (data or status) phase.
It will help us catching errors of host going
crazy and requesting data of the wrong direction.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Whenever we issue a Set Stall command on EP0,
the state machine will be restarted and Stall
is cleared automatically, when core receives
the next SETUP packet.
There's no need to track that EP0_STALL state.
Signed-off-by: Felipe Balbi <balbi@ti.com>
when we're going to issue Set Stall command,
we should clear DWC3_EP_STALL flag, but also
we should clear BUSY, HALTED and all others.
Signed-off-by: Felipe Balbi <balbi@ti.com>
The DesignWare USB3 core tells us which phase
of a control transfer should be started, it
also tells us which physical endpoint needs
that transfer.
With these two informations, we have all we
need to simply EP0 handling quite a lot and
get rid rid of the SW state machine tracking
ep0 states.
For achieving this perfectly, we needed to
add support for situations where we get
XferNotReady while endpoint is still busy
and XferNotReady while gadget driver still
hasn't queued a request.
Signed-off-by: Felipe Balbi <balbi@ti.com>
In case we have transfers which aren't aligned
to wMaxPacketSize, we need to be careful with
how we start the transfer with the HW. OUT
transfers _must_ be aligned with wMaxPacketSize
and in order to guarantee that, we use a bounce
buffer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
The DesignWare USB3 is a highly
configurable IP Core which can be
instantiated as Dual-Role Device (DRD),
Peripheral Only and Host Only (XHCI)
configurations.
Several other parameters can be configured
like amount of FIFO space, amount of TX and
RX endpoints, amount of Host Interrupters,
etc.
The current driver has been validated with
a virtual model of version 1.73a of that core
and with an FPGA burned with version 1.83a
of the DRD core. We have support for PCIe
bus, which is used on FPGA prototyping, and
for the OMAP5, more adaptation (or glue)
layers can be easily added and the driver
is half prepared to handle any possible
configuration the HW engineer has chosen
considering we have the information on
one of the GHWPARAMS registers to do
runtime checking of certain features.
More runtime checks can, and should, be added
in order to make this driver even more flexible
with regards to number of endpoints, FIFO sizes,
transfer types, etc.
While this supports only the device side, for
now, we will add support for Host side (xHCI -
see the updated series Sebastian has sent [1])
and OTG after we have it all stabilized.
[1] http://marc.info/?l=linux-usb&m=131341992020339&w=2
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sebastian Andrzej Siewior