The assignement of EP transfer resources was not handled properly in the
dwc3 driver. Commit aebda6187181 ("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: aebda6187181 ("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>

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: Jianqiang Tang <jianqiang.tang@intel.com>
Signed-off-by: Felipe 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: Felipe 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: 04c03d10e507 ("usb: dwc3: gadget: handle request->zero")
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe 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: Felipe 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: Felipe 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: Ravi B <ravibabu@ti.com>
Signed-off-by: Felipe 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: Felipe 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: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Signed-off-by: Felipe 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: Felipe Balbi <balbi@ti.com>