We call usb_phy_init() from dwc3_core_init() during
probe, so adding usb_phy_shutdown() to dwc3_core_exit()
while removing the device so we don't keep PHYs
turned on, consuming power, unnecessarily.

Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>

If a USB transfer has already been started, meaning
we have already issued StartTransfer command to that
particular endpoint, DWC3_EP_BUSY flag has also
already been set.

When we try to cancel this transfer which is already
in controller's cache, we will not receive XferComplete
event and we must clear DWC3_EP_BUSY in order to allow
subsequent requests to be properly started.

The best place to clear that flag is right after issuing
DWC3_DEPCMD_ENDTRANSFER.

Cc: stable@vger.kernel.org # v3.4 v3.5 v3.6
Reported-by: Moiz Sonasath <m-sonasath@ti.com>
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>

usb: dwc3: patches for v3.7 merge window

Some much needed changes for our dwc3 driver. First there's a
rework on the ep0 handling due to some Silicon issue we uncovered
which affects all users of this IP core (there's a missing
XferNotReady(DATA) event in some conditions). This issue which
show up as a SETUP transfers which wouldn't complete ever and
we would fail TD 7.06 of the Link Layer Test from USB-IF and
Lecroy's USB3 Exerciser.

We also fix a long standing bug regarding EP0 enable sequencing
where we weren't setting a particular bit (Ignore Sequence
Number). Since we never saw any problems caused by that, it
didn't deserve being sent to stable tree.

On this pull request we also fix Burst Size initialization which
should be done only in SuperSpeed and we were mistakenly setting
Burst Size to the maximum value on non-SuperSpeed mode. Again,
since we never saw any problems caused by that, we're not sending
this patch to stable.

There's also a memory ordering fix regarding usage of bitmaps in
dwc3 driver.

You will also find some sparse warnings fix, a fix for missed
isochronous packets when the endpoint is already busy, and a
fix for synchronization delay on dwc3_stop_active_transfer().

usb: xceiv: patches for v3.7 merge window

nop xceiv got its own header to avoid polluting otg.h. It has also
learned to work as USB2 and USB3 phys so we can use it on USB3
controllers.

Together with those two changes to nop xceiv, we're adding basic
PHY support to dwc3 driver, this is to allow platforms which actually
have a SW-controllable PHY talk to them through dwc3 driver.

We're adding a new phy driver for the OMAP architecture. This driver
is for the PHY found in OMAP4 SoCs, and a new phy driver for the
marvell architecture. An extra phy driver - for Tegra SoCs - is now
moving from arch/arm/mach-tegra* to drivers/usb/phy.

Also here, there's the creation of <linux/usb/phy.h> which should be
used from now on for PHY drivers, even those which don't support
OTG.

this will let us control PHYs on platforms which
need them.

Signed-off-by: Felipe Balbi <balbi@ti.com>

We will be adding support for transceivers on
dwc3 driver but not all boards have controllable
transceivers.

For those which don't provide controllable transceivers
we will register nop transceivers.

Signed-off-by: Felipe Balbi <balbi@ti.com>

We will be adding support for transceivers on
dwc3 driver but not all boards have controllable
transceivers.

For those which don't provide controllable transceivers
we will register nop transceivers.

Note that once OMAP's transceiver drivers reach mainline,
this glue layer will change accordingly.

Signed-off-by: Felipe Balbi <balbi@ti.com>

We will be adding support for transceivers on
dwc3 driver but not all boards have controllable
transceivers.

For those which don't provide controllable transceivers
we will register nop transceivers.

Signed-off-by: Felipe Balbi <balbi@ti.com>

If xfernotready is received and there is no request in request_list then
REQUEST_PENDING flag must be set, so that next request in ep queue is executed.

In case of isoc transfer, if xfernotready is already elapsed and even first
request has not been queued to request_list, then issue END TRANSFER, so that
you can receive xfernotready again and can have notion of current microframe.

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>