Now that usb_endpoint_maxp() only returns the lowest
11 bits from wMaxPacketSize, we can remove this macro
from the driver.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Now that usb_endpoint_maxp() only returns the lowest
11 bits from wMaxPacketSize, we can remove the &
operation from this driver.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Now that usb_endpoint_maxp() only returns the lowest
11 bits from wMaxPacketSize, we can remove the &
operation from this driver.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <linux-usb@vger.kernel.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Now that usb_endpoint_maxp() only returns the lowest
11 bits from wMaxPacketSize, we can remove the &
operation from this driver.

Cc: Peter Chen <Peter.Chen@nxp.com>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

usb_endpoint_maxp() is now returning maxpacket
correctly - iow only bits 10:0. We can finaly remove
XHCI's private GET_MAX_PACKET macro.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.

Cc: Bin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.

Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.

Cc: Li Yang <leoli@freescale.com>
Cc: <linuxppc-dev@lists.ozlabs.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.

Cc: Ashwini Pahuja <ashwini.linux@gmail.com>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <linux-usb@vger.kernel.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.
Acked-by: NPeter Chen <Peter.Chen@nxp.com>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

With this extra piece of information, it will be
easier to find mismatches between driver and HW.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

We will be using dwc3_ep0_state_string() from within
our tracepoints, so we need to move that helper to
debug.h in order for it to be accessible.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Removing some trace prints which were made redundant
when we started decoding events and TRBs completely
within their respective trace points.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

DWC3 can tell us which phase of a setup transfer
we're getting into. Let's decode it from the event
to make it easier to debug.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

Link State Change events are only needed for
debugging and to apply certain workarounds on known
errata. Let's save a few cycles by disabling these
events completely on working revisions of the core.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

There might be situations where a Start Transfer
command might fail, if that ever happens, instead of
simply removing the request from our list, we should
give the request back to the gadget driver,
otherwise we might eventually starve it from requests.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

No Response Update Transfer is a special type of
Update Transfer command which can be used whenever
we're not relying on XferNotReady to prepare
transfers. With this, we don't need to wait for
CMDACT to be cleared and issue further commands to
the endpoint straight away.

Let's start using this version to skip the long-ish
wait.
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

The cmd argument we pass to
dwc3_send_gadget_ep_cmd() could contain extra
arguments embedded. When checking for StartTransfer
command, we need to make sure to match only lower 4
bits which contain the actual command and ignore the
rest.
Reported-by: NJanusz Dziedzic <januszx.dziedzic@intel.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

In case of High-Speed, High-Bandwidth endpoints, we
need to tell DWC3 that we have more than one packet
per interval. We do that by setting PCM1 field of
Isochronous-First TRB.

Cc: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

ep->mult is supposed to be set to Isochronous and
Interrupt Endapoint's multiplier value. This value
is computed from different places depending on the
link speed.

If we're dealing with HighSpeed, then it's part of
bits [12:11] of wMaxPacketSize. This case wasn't
taken into consideration before.

While at that, also make sure the ep->mult defaults
to one so drivers can use it unconditionally and
assume they'll never multiply ep->maxpacket to zero.

Cc: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

usb_endpoint_maxp() returns wMaxPacketSize in its
raw form. Without taking into consideration that it
also contains other bits reserved for isochronous
endpoints.

This patch fixes one occasion where this is a
problem by making sure that we initialize
ep->maxpacket only with lower 10 bits of the value
returned by usb_endpoint_maxp(). Note that seperate
patches will be necessary to audit all call sites of
usb_endpoint_maxp() and make sure that
usb_endpoint_maxp() only returns lower 10 bits of
wMaxPacketSize.

Cc: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

After commit b09b5224 ("usb: chipidea: implement platform shutdown
callback") and commit 43a40457 ("usb: chipidea: host: set host to
be null after hcd is freed") a NULL pointer dereference is caused
on i.MX23 during shutdown. So ensure that role is set to CI_ROLE_END and
we finish interrupt handling before the hcd is deallocated. This avoids
the NULL pointer dereference.
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Fixes: b09b5224 ("usb: chipidea: implement platform shutdown callback")
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

Since the controller on R-Car Gen3 doesn't have any status registers
to detect initialization (LPSTS.SUSPM = 1) and the initialization needs
up to 45 usec, this patch adds wait after the initialization. Otherwise,
writing other registers (e.g. INTENB0) will fail.

Fixes: de18757e ("usb: renesas_usbhs: add R-Car Gen3 power control")
Cc: <stable@vger.kernel.org> # v4.6+
Cc: <balbi@kernel.org>
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
with 20 ms of slack, after removing slack time some ohci controllers don't
respond in time. Logs from systems with controllers that have the
issue would show "HcDoneHead not written back; disabled"
Signed-off-by: NBryan Paluch <bryanpaluch@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If we're booting pandaboard using NFSroot over built-in g_ether, we
can get the following after booting once and doing a warm reset:

g_ether gadget: ecm_open
g_ether gadget: notify connect true
...
WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147
l3_interrupt_handler+0x220/0x34c
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Read):
Data Access in User mode du ring Functional access
...

Fix the issue by calling pm_runtime functions from
musb_gadget_queue.

Note that in the long run we should be able to queue the pending
transfers if pm_runtime is not active, and flush the queue from
pm_runtime_resume.
Reported-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If we configure musb with 2430 glue as a peripheral, and then rmmod
omap2430 module, we'll get the following error:

[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
...
rmmod/413 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
 (&phy->mutex){+.+.+.}, at: [<c04b9fd0>] phy_power_off+0x1c/0xb8
[  204.678710]
               and this task is already holding:
 (&(&musb->lock)->rlock){-.-...}, at: [<bf3a482c>]
 musb_gadget_stop+0x24/0xec [musb_hdrc]
which would create a new lock dependency:
 (&(&musb->lock)->rlock){-.-...} -> (&phy->mutex){+.+.+.}
...

This is because some glue layers expect musb_platform_enable/disable
to be called with spinlock held, and 2430 glue layer has USB PHY on
the I2C bus using a mutex.

We could fix the glue layers to take the spinlock, but we still have
a problem of musb_plaform_enable/disable being called in an unbalanced
manner. So that would still lead into USB PHY enable/disable related
problems for omap2430 glue layer.

While it makes sense to only enable USB PHY when needed from PM point
of view, in this case we just can't do it yet without breaking things.
So let's just revert phy_enable/disable related changes instead and
reconsider this after we have fixed musb_platform_enable/disable to
be balanced.

Fixes: a83e17d0 ("usb: musb: Improve PM runtime and phy handling for 2430 glue layer")
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
needs to handle 4 reset lines for EHCI.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The reset value of RWC is 0, set RemoteWakeupConnected bit explicitly
before calling ohci_run, it also fixes the issue that the mass
storage stick connected wasn't suspended when the system suspend.
Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure we have at least one port before attempting to register a
console.

Currently, at least one driver binds to a "dummy" interface and requests
zero ports for it. Should such an interface also lack endpoints, we get
a NULL-deref during probe.

Fixes: e5b1e206 ("USB: serial: make minor allocation dynamic")
Cc: stable <stable@vger.kernel.org>	# 3.11
Signed-off-by: NJohan Hovold <johan@kernel.org>

USB2 host inititated resume, and system suspend bus resume
need to use the same USB_RESUME_TIMEOUT as elsewhere.

This resolves a device disconnect issue at system resume seen
on Intel Braswell and Apollolake, but is in no way limited to
those platforms.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If a device is unplugged and replugged during Sx system suspend
some  Intel xHC hosts will overwrite the CAS (Cold attach status) flag
and no device connection is noticed in resume.

A device in this state can be identified in resume if its link state
is in polling or compliance mode, and the current connect status is 0.
A device in this state needs to be warm reset.

Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8

Observed on Cherryview and Apollolake as they go into compliance mode
if LFPS times out during polling, and re-plugged devices are not
discovered at resume.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the
same quirks to prevent machines from spurious restart while
shutting them down.
Reported-by: NHasan Mahmood <hasan.mahm@gmail.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>