This patch is needed in order to pass one test case
defined in the OTG Automated Compliance Test specification.

Specification location:
http://www.usb.org/developers/onthego/otgeh_compliance_plan_1_2.pdf

This test case uses PET Tool, and PET Tool is one USB hardware
equipment provided by MQP Electronics.

Test case id is 6.8.3 B-UUT Bypass Capacitance.

We must set this otg flag in order to be able to return OTG
descriptor during enumeration, otherwise this test case with
failed with below error: "Get OTG descriptor request stalled".
Signed-off-by: NJianqiang Tang <jianqiang.tang@intel.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

if we have a !PM kernel build, our runtime
suspend/resume callbacks will be left defined but
unused. Add a ifdef CONFIG_PM guard.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If the request->length is zero, a ZLP should already be sent due to that
and another ZLP is not needed to terminate the transfer.

Fixes: 04c03d10 ("usb: dwc3: gadget: handle request->zero")
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

instead of using:

	if (condition) {
		dev_WARN_ONCE(dev, true, "foo");
		return -EINVAL;
	}

let's use:

	if (dev_WARN_ONCE(dev, condition, "foo"))
		return -EINVAL;
Signed-off-by: NFelipe Balbi <balbi@ti.com>

struct usb_request have 3 flags which might be
important to know about during debug. This patch
shows each of the 3 flags as a single letter:

z -> for zero
s -> short not okay
i -> interrupt

A capital letter means the feature is enabled
while a lower case letter means it is disabled;

Thus 'zsI' indicates that a ZLP is not needed,
that we can accept a short packet and interrupt
for this request should be enabled.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

So far, dwc3 has always missed request->zero
handling for every endpoint. Let's implement
that so we can handle cases where transfer must
be finished with a ZLP.

Note that dwc3 is a little special. Even though
we're dealing with a ZLP, we still need a buffer
of wMaxPacketSize bytes; to hide that detail from
every gadget driver, we have a preallocated buffer
of 1024 bytes (biggest bulk size) to use (and
share) among all endpoints.
Reported-by: NRavi B <ravibabu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Now that we have a generic dwc3-of-simple.c, we can
use that instead of maintaining dwc3-qcom.c which is
extremely similar.

Cc: Ivan T. Ivanov <iivanov@mm-sol.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

For simple platforms which merely enable some clocks
and populate its children, we can use this generic
glue layer to avoid boilerplate code duplication.

For now this supports Qcom and Xilinx, but if we
find a way to add generic handling of regulators and
optional PHYs, we can absorb exynos as well.
Tested-by: NSubbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

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>

In dwc3_cleanup_done_reqs() we expect that all
iterations of our while (1) loop will find a valid
struct dwc3_request *. In case we don't, we're
dumping a WARN_ON_ONCE() splat so that people report
the failure.

This patch is a simple cleanup converting:

	if (!req) {
		WARN_ON_ONCE(1);
		return 1;
	}

to:

	if (WARN_ON_ONCE(!req))
		return 1;

which is a little easier to read.
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>

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>

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>

By moving our sanity checks our internal function
__dwc3_gadget_ep_queue() we can simplify the
externally visible API while also making sure that
callers of __dwc3_gadget_ep_queue() also make use of
the same checks.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Because interrupt endpoints usually transmit such
small amounts of data, it seems pointless to prestart
transfers and try to get speed improvements. This
patch also sorts out a problem with CDC ECM function
where its notification endpoint gets stuck in busy
state and we continuously issue Update Transfer
commands.

Fixes: 8a1a9c9e ("usb: dwc3: gadget: start transfer on XFER_COMPLETE")
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In some SoCs, dwc3 is implemented as a USB2.0 only
core, meaning that it can't ever achieve SuperSpeed.

Currect driver always sets gadget.max_speed to
USB_SPEED_SUPER unconditionally. This can causes
issues to some Host stacks where the host will issue
a GetBOS() request and we will reply with a BOS
containing Superspeed Capability Descriptor.

At least Windows seems to be upset by this fact and
prints a warning that we should connect $this device
to another port.

[ balbi@ti.com : rewrote entire commit, including
source code comment to make a lot clearer what the
problem is ]

Cc: <stable@vger.kernel.org>
Signed-off-by: NBen McCauley <ben.mccauley@garmin.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

PCI IDs for Broxton based platforms.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This reverts commit 8f2c9544.

As it breaks g_ether on my Baytrail FFRD8 device. Everything starts out
fine, but after a bit of data has been transferred it just stops
flowing.

Note that I do get a bunch of these "NOHZ: local_softirq_pending 08"
when booting the machine, but I'm not really sure if they're related
to this problem.

Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This reverts commit 70f3a9ca.

That commit was causing a lockdep splat with g_ether and that
was interfering with proper functionality.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Certain Synopsys prototyping PHY boards are not able to meet timings
constraints for LPM. This allows the PHY to meet those timings by
leaving the PHY clock running during suspend.

Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add a quirk to clear the GUSB2PHYCFG.ENBLSLPM bit, which controls
whether the PHY receives the suspend signal from the controller.

Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add platform data and set usb3_lpm_capable and has_lpm_erratum.

Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Fix the alignment of the PCI device definitions. Also change the hex
digit capitalization of one constant to make it consistent with the
rest of the file and driver.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch allows the dwc3 driver to run on the new Synopsys USB 3.1
IP core, albeit in USB 3.0 mode only.

The Synopsys USB 3.1 IP (DWC_usb31) retains mostly the same register
interface and programming model as the existing USB 3.0 controller IP
(DWC_usb3). However the GSNPSID and version numbers are different.

Add checking for the new ID to pass driver probe.

Also, since the DWC_usb31 version number is lower in value than the
full GSNPSID of the DWC_usb3 IP, we set the high bit to identify
DWC_usb31 and to ensure the values are higher.

Finally, add a documentation note about the revision numbering scheme.
Any future revision checks (for STARS, workarounds, and new features)
should take into consideration how it applies to both the 3.1/3.0 IP.

Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This adds the PCI product ID for the Synopsys USB 3.1 IP core
(DWC_usb31) on a HAPS-based PCI development platform.

Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This ID is for the Synopsys DWC_usb3 core with AXI interface on PCIe
HAPS platform. This core has the debug registers mapped at a separate
BAR in order to support enhanced hibernation.

Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We *know* our threads executes with our IRQs
disabled. We really don't need to use the _irqsave()
variant of spin_lock().
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Instead of limiting __dwc3_gadget_kick_transfer() to
Xfer Complete, we can try to issue Update Transfer
command from Xfer In Progress too.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If we get a Xfer Not Ready event with reason
"Transfer Active" it means endpoint is still
transferring data and we can use that to issue
update transfer for this particular endpoint
in case we have pending requests in our queue.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

if by the time we get to XFER_COMPLETE we have
pending requests to be processed, instead of waiting
for a following XFER_NOT_READY, let's start the request
right away and, maybe, save the time of a few NAKs
due to lack of started transfers.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Sharing the ACPI companion with dwc3 core so it has access
to the properties defined for DWC3 in ACPI tables.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

No functional affect on existing platforms, but the driver
is now ready to extract the properties also from ACPI tables
as well as from DT.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

By using the unified device property interface, the function
can be made available for all platforms and not just the
ones using DT.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

of_usb_get_dr_mode will be converted into more generic
usb_get_dr_mode function that will take struct device
instead of struct device_node as its parameter.

To make the conversion possible later, waiting for the
platform device for dwc3 to be populated before calling
of_usb_get_dr_mode.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
CC: Giuseppe Cavallaro <peppe.cavallaro@st.com>
CC: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

By using the unified device property interface, the function
can be made available for all platforms and not just the
ones using DT.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add support for USB DRVVBUS pinctrl state change during
suspend/resume. This helps is conserving power during
system sleep.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Add adjust_frame_length_quirk for writing to fladj register
which adjusts (micro)frame length to value provided by
"snps,quirk-frame-length-adjustment" property thus avoiding
USB 2.0 devices to time-out over a longer run
Signed-off-by: NNikhil Badola <nikhil.badola@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We shouldn't return -EBUSY, that's used only internally
when the core still has transfers in flight on a given
endpoint.

Also, combine the error reporting so that we don't have
to duplicate it.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Instead of clearing DWC3_PENDING_REQUEST when
we start transfer, let's do it when the request
is actually queued, that way we know for sure
that we're clearing in the right time.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In an attempt to make dwc3 slightly faster, let's
start usb_requests as soon as they come as that will
let us avoid a XFER_NOT_READY event and save a little
bit of time.
Signed-off-by: NFelipe Balbi <balbi@ti.com>