They are used way too often in this file, in some ways that are actually
wrong.  Almost all of these are already known by the compiler and CPU so
just remove them all as none of these should be on any "hot paths" where
it actually matters.

Cc: Felipe Balbi <balbi@kernel.org>
Reported-by: NPeter Chen <peter.chen@nxp.com>
Reviewed-by: NPeter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20201127140559.381351-6-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In many cases a function that supports SuperSpeed can very well
operate in SuperSpeedPlus, if a gadget controller supports it,
as the endpoint descriptors (and companion descriptors) are
generally identical and can be re-used. This is true for two
commonly used functions: Android's ADB and MTP. So we can simply
assign the usb_function's ssp_descriptors array to point to its
ss_descriptors, if available. Similarly, we need to allow an
epfile's ioctl for FUNCTIONFS_ENDPOINT_DESC to correctly
return the corresponding SuperSpeed endpoint descriptor in case
the connected speed is SuperSpeedPlus as well.

The only exception is if a function wants to implement an
Isochronous endpoint capable of transferring more than 48KB per
service interval when operating at greater than USB 3.1 Gen1
speed, in which case it would require an additional SuperSpeedPlus
Isochronous Endpoint Companion descriptor to be returned as part
of the Configuration Descriptor. Support for that would need
to be separately added to the userspace-facing FunctionFS API
which may not be a trivial task--likely a new descriptor format
(v3?) may need to be devised to allow for separate SS and SSP
descriptors to be supplied.
Signed-off-by: NJack Pham <jackp@codeaurora.org>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201027230731.9073-1-jackp@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Needed for SuperSpeed Plus support for f_midi.  This allows the
gadget to work properly without crashing at SuperSpeed rates.

Cc: Felipe Balbi <balbi@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NWill McVicker <willmcvicker@google.com>
Reviewed-by: NPeter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20201127140559.381351-4-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Setup the SuperSpeed Plus descriptors for f_acm.  This allows the gadget
to work properly without crashing at SuperSpeed rates.

Cc: Felipe Balbi <balbi@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Ntaehyun.cho <taehyun.cho@samsung.com>
Signed-off-by: NWill McVicker <willmcvicker@google.com>
Reviewed-by: NPeter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20201127140559.381351-3-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Align the SuperSpeed Plus bitrate for f_rndis to match f_ncm's ncm_bitrate
defined by commit 16501138 ("usb: gadget: f_ncm: add SuperSpeed descriptors
for CDC NCM").

Cc: Felipe Balbi <balbi@kernel.org>
Cc: EJ Hsu <ejh@nvidia.com>
Cc: Peter Chen <peter.chen@nxp.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NWill McVicker <willmcvicker@google.com>
Reviewed-by: NPeter Chen <peter.chen@nxp.com>
Link: https://lore.kernel.org/r/20201127140559.381351-2-gregkh@linuxfoundation.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB4 specification chapter 3 indicates that cable data rates have to be
rounded for USB4 device to operate as USB4.
With that configure cable generation value to use rounded data rates for
USB4.

Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NUtkarsh Patel <utkarsh.h.patel@intel.com>
Link: https://lore.kernel.org/r/20201209042408.23079-2-utkarsh.h.patel@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'usb-v5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-next

Peter writes:

Below are main changes for v5.11-rc1:

For Chipidea USB2:
- Add tracepoint support for UDC
- Some tiny improvements

For Cadence USB3
- Add some quirks for host mode, and let host work well at more use cases
	* SKIP_PHY_INIT
	* Disable BEI
	* Enable runtime PM default for i.mx platform
- Some tiny improvements

* tag 'usb-v5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb:
  MAINTAINERS: Add myself as a reviewer for CADENCE USB3 DRD IP DRIVER
  usb: chipidea: ci_hdrc_imx: Use of_device_get_match_data()
  usb: chipidea: usbmisc_imx: Use of_device_get_match_data()
  usb: cdns3: fix NULL pointer dereference on no platform data
  usb: chipidea: trace: fix the endian issue
  usb: chipidea: add tracepoint support for udc
  doc: dt-binding: cdns,usb3: add wakeup-irq
  usb: cdns3: imx: enable runtime pm by default
  usb: cdns3: add quirk for enable runtime pm by default
  usb: cdns3: host: disable BEI support
  usb: cdns3: host: add xhci_plat_priv quirk XHCI_SKIP_PHY_INIT
  usb: cdns3: host: add .suspend_quirk for xhci-plat.c
  usb: cdns3: Rids of duplicate error message
  usb: cdns3: Add static to cdns3_gadget_exit function

I would like to help in reviewing CADENCE USB3 DRD IP DRIVER patches
Signed-off-by: NAswath Govindraju <a-govindraju@ti.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

The retrieval of driver data via of_device_get_match_data() can make
the code simpler.

Use of_device_get_match_data() to simplify the code.
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

The retrieval of driver data via of_device_get_match_data() can make
the code simpler.

Use of_device_get_match_data() to simplify the code.
Signed-off-by: NFabio Estevam <festevam@gmail.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

Some platforms (e.g. TI) will not have any platform data which will
lead to NULL pointer dereference if we don't check for NULL pdata.

Fixes: 7cea9657 ("usb: cdns3: add quirk for enable runtime pm by default")
Reported-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Acked-by: NPawel Laszczak <pawell@cadence.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

"sparse warnings: (new ones prefixed by >>)"
   drivers/usb/chipidea/trace.c: note: in included file (through include/trace/trace_events.h, include/trace/define_trace.h, drivers/usb/chipidea/trace.h):
>> drivers/usb/chipidea/./trace.h:39:1: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [usertype] next @@     got restricted __le32 [usertype] next @@
>> drivers/usb/chipidea/./trace.h:39:1: sparse:     expected unsigned int [usertype] next
>> drivers/usb/chipidea/./trace.h:39:1: sparse:     got restricted __le32 [usertype] next
>> drivers/usb/chipidea/./trace.h:39:1: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [usertype] token @@     got restricted __le32 [usertype] token @@
>> drivers/usb/chipidea/./trace.h:39:1: sparse:     expected unsigned int [usertype] token
>> drivers/usb/chipidea/./trace.h:39:1: sparse:     got restricted __le32 [usertype] token
   drivers/usb/chipidea/trace.c: note: in included file (through include/trace/perf.h, include/trace/define_trace.h, drivers/usb/chipidea/trace.h):
>> drivers/usb/chipidea/./trace.h:39:1: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [usertype] next @@     got restricted __le32 [usertype] next @@
>> drivers/usb/chipidea/./trace.h:39:1: sparse:     expected unsigned int [usertype] next
>> drivers/usb/chipidea/./trace.h:39:1: sparse:     got restricted __le32 [usertype] next
>> drivers/usb/chipidea/./trace.h:39:1: sparse: sparse: incorrect type in assignment (different base types) @@     expected unsigned int [usertype] token @@     got restricted __le32 [usertype] token @@
>> drivers/usb/chipidea/./trace.h:39:1: sparse:     expected unsigned int [usertype] token
>> drivers/usb/chipidea/./trace.h:39:1: sparse:     got restricted __le32 [usertype] token
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

Add basic tracepoint support for udc driver.
Reviewed-by: NJun Li <jun.li@nxp.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

To support low power mode for controller, the driver needs wakeup-irq
to reflect the signal changing after controller is stopped, and waking
the controller up accordingly.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

Enable runtime pm by default
Reviewed-by: NJun Li <jun.li@nxp.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

Some vendors (eg: NXP) may want to enable runtime pm by default for
power saving, add one quirk for it.
Reviewed-by: NJun Li <jun.li@nxp.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

The Cadence xHCI doesn't support BEI well, it causes the disconnection
of ISOC devices can't be detected, so we disable it.
Reviewed-by: NJun Li <jun.li@nxp.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

cdns3 manages PHY by own DRD driver, so skip the management by
HCD core.
Reviewed-by: NJun Li <jun.li@nxp.com>
Reviewed-by: NPawel Laszczak <pawell@cadence.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

cdns3 has some special PM sequence between xhci_bus_suspend and
xhci_suspend, add quirk to implement it.
Reviewed-by: NPawel Laszczak <pawell@cadence.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

On failure, the platform_get_irq_byname prints an error message,
so patch removes error message related to this function from
core.c file.

A change was suggested during reviewing CDNSP driver by Chunfeng Yun.
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NPawel Laszczak <pawell@cadence.com>
Acked-by: NPeter Chen <peter.chen@nxp.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

Function cdns3_gadget_exit is used only in gadget.c file.
This patch removes declaration and definition of this
function from gadget-export.h file and makes it static.
Signed-off-by: NPawel Laszczak <pawell@cadence.com>
Acked-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NPeter Chen <peter.chen@nxp.com>

UAS does not share the pessimistic assumption storage is making that
devices cannot deal with WRITE_SAME.  A few devices supported by UAS,
are reported to not deal well with WRITE_SAME. Those need a quirk.

Add it to the device that needs it.
Reported-by: NDavid C. Partridge <david.partridge@perdrix.co.uk>
Signed-off-by: NOliver Neukum <oneukum@suse.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201209152639.9195-1-oneukum@suse.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

usb_create_hcd will alloc memory for hcd, and we should
call usb_put_hcd to free it when adding fails to prevent
memory leak.

Fixes: b92a78e5 ("usb host: Oxford OXU210HP HCD driver")
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201123145809.1456541-1-zhangqilong3@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove casting the values returned by dma_alloc_coherent.
Signed-off-by: NXu Wang <vulab@iscas.ac.cn>
Link: https://lore.kernel.org/r/20201120083054.8973-1-vulab@iscas.ac.cnSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The macro use will already have a semicolon.
Signed-off-by: NTom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20201127190336.2841413-1-trix@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a spelling mistake in the Kconfig help text. Fix it.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20201126223704.13273-1-colin.king@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since we have the nice helpers pr_err() and pr_warn(), use them instead
of raw printk().
Acked-by: NDuncan Sands <duncan.sands@free.fr>
Signed-off-by: NEnrico Weigelt, metux IT consult <info@metux.net>
Link: https://lore.kernel.org/r/20201208093206.24780-3-info@metux.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since we already have the useful atm_info() macro, use it instead of
raw atm_printk()
Signed-off-by: NEnrico Weigelt, metux IT consult <info@metux.net>
Link: https://lore.kernel.org/r/20201208093206.24780-2-info@metux.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If drivers work correctly, they should remain silent.
Signed-off-by: NEnrico Weigelt, metux IT consult <info@metux.net>
Link: https://lore.kernel.org/r/20201208093206.24780-1-info@metux.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Unmask EXTENDED_STATUS_MASK.vSafe0V, ALERT.Extended_Status
and set vbus_vsafe0v to enable VSAFE0V signalling.
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201202040840.663578-3-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This change adds vbus_vsafe0v which when set, makes TCPM
query for VSAFE0V by assigning the tcpc.is_vbus_vsafe0v callback.
Also enables ALERT.ExtendedStatus which is triggered when
status of EXTENDED_STATUS.vSafe0V changes.
EXTENDED_STATUS.vSafe0V is set when vbus is at vSafe0V and
cleared otherwise.
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201202040840.663578-2-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

TCPM at present lacks the notion of VSAFE0V. There
are three vbus threshold levels that are critical to track:
a. vSafe5V         - VBUS “5 volts” as defined by the USB
                     PD specification.
b. vSinkDisconnect - Threshold used for transition from
                     Attached.SNK to Unattached.SNK.
c. vSafe0V         - VBUS “0 volts” as defined by the USB
                     PD specification.

Tracking vSafe0V is crucial for entry into Try.SNK and
Attached.SRC and turning vbus back on by the source in
response to hard reset.

>From "4.5.2.2.8.2 Exiting from AttachWait.SRC State" section
in the Type-C spec:

"The port shall transition to Attached.SRC when VBUS is at
vSafe0V and the SRC.Rd state is detected on exactly one of
the CC1 or CC2 pins for at least tCCDebounce."

"A DRP that strongly prefers the Sink role may optionally
transition to Try.SNK instead of Attached.SRC when VBUS
is at vSafe0V and the SRC.Rd state is detected on exactly
one of the CC1 or CC2 pins for at least tCCDebounce."

>From "7.1.5 Response to Hard Resets" section in the PD spec:

"After establishing the vSafe0V voltage condition on VBUS,
the Source Shall wait tSrcRecover before re-applying VCONN
and restoring VBUS to vSafe5V."

vbus_present in the TCPM code tracks vSafe5V(vbus_present is true)
and vSinkDisconnect(vbus_present is false).

This change adds is_vbus_vsafe0v callback which when set makes
TCPM query for vSafe0V voltage level when needed.

Since not all TCPC controllers might have the capability
to report vSafe0V, TCPM assumes that vSafe0V is same as
vSinkDisconnect when is_vbus_vsafe0v callback is not set.
This allows TCPM to continue to support controllers which don't
have the support for reporting vSafe0V.

Introducing vSafe0V helps fix the failure reported at
"Step 15. CVS verifies PUT remains in AttachWait.SRC for 500ms"
of "TD 4.7.2 Try. SNK DRP Connect DRP Test" of
"Universal Serial Bus Type-C (USB Type-C) Functional Test
Specification Chapters 4 and 5". Here the compliance tester
intentionally maintains vbus at greater than vSafe0V and expects
the Product under test to stay in AttachWait.SRC till vbus drops
to vSafe0V.
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201202040840.663578-1-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

tcpm_check_send_discover does not clear the send_discover flag
when any of the following conditions are not met.
1. data_role is TYPEC_HOST
2. link is pd_capable

Discovery indentity would anyways not be attempted during
the current session anymore when the above conditions are not
met. Hence clear the send_discover flag here to prevent
tcpm_enable_frs_work from rescheduling indefinetly.
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201203031908.1491542-1-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

nRetryCount was updated from 3 to 2 between PD2.0 and PD3.0 spec.
nRetryCount in "Table 6-34 Counter parameters" of the PD 2.0
spec is set to 3, whereas, nRetryCount in "Table 6-59 Counter
parameters" is set to 2.

Pass down negotiated rev in pd_transmit so that low level chip
drivers can update the retry count accordingly before attempting
packet transmission.

This helps in passing "TEST.PD.PORT.ALL.02" of the
"Power Delivery Merged" test suite which was initially failing
with "The UUT did not retransmit the message nReryCount times"

In fusb302 & tcpci drivers, by default the driver sets the retry
count to 3 (Default for PD 2.0). Update this to 2,
if the negotiated rev is PD 3.0.

In wcove, since the retry count is intentionally set to max, leaving
it as is.
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20201202031733.647808-1-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When Intel PMC Mux agent driver receives the response message from PMC, it
checks for the same response bits for all the mux states.
Corrected it by checking correct response message bits, Bit 8 & 9 for the
SAFE Mode and Alternate Modes and Bit 16 & 17 for the Connect and
Disconnect Modes.
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NUtkarsh Patel <utkarsh.h.patel@intel.com>
Link: https://lore.kernel.org/r/20201203220813.16281-1-utkarsh.h.patel@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The pm_runtime_enable will decrement the power disable depth. Imbalance
depth will resulted in enabling runtime PM of device fails later.  Thus
a pairing decrement must be needed on the error handling path to keep it
balanced.

Fixes: 6c984b06 ("ARM: OMAP: USBHOST: Replace usbhs core driver APIs by Runtime pm APIs")
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NZhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20201123145719.1455849-1-zhangqilong3@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If a USB2 device wakeup is not enabled/supported the link state may
still be in U0 in xhci_bus_suspend(), where it's then manually put
to suspended U3 state.

Just as with selective suspend the device needs time to enter U3
suspend before continuing with further suspend operations
(e.g. system suspend), otherwise we may enter system suspend with link
state in U0.

[commit message rewording -Mathias]

Cc: <stable@vger.kernel.org>
Signed-off-by: NLi Jun <jun.li@nxp.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20201208092912.1773650-6-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Intel Maple Ridge is successor of Titan Ridge Thunderbolt controller. As
Titan Ridge this one also includes xHCI host controller. In order to
safe energy we should put it to low power state by default when idle.
For this reason allow host runtime PM for Maple Ridge.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20201208092912.1773650-5-mathias.nyman@linux.intel.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The xHCI controller on Alpine Ridge LP keeps the whole Thunderbolt
controller awake if the host controller is not allowed to sleep.
This is the case even if no USB devices are connected to the host.

Add the Intel Alpine Ridge LP product-id to the list of product-ids
for which we allow runtime PM by default.

Fixes: 2815ef7f ("xhci-pci: allow host runtime PM as default for Intel Alpine and Titan Ridge")
Cc: <stable@vger.kernel.org>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20201208092912.1773650-4-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Synopsys xHC has an internal TRB cache of size TRB_CACHE_SIZE for
each endpoint. The default value for TRB_CACHE_SIZE is 16 for SS and 8
for HS. The controller loads and updates the TRB cache from the transfer
ring in system memory whenever the driver issues a start transfer or
update transfer command.

For chained TRBs, the Synopsys xHC requires that the total amount of
bytes for all TRBs loaded in the TRB cache be greater than or equal to 1
MPS. Or the chain ends within the TRB cache (with a last TRB).

If this requirement is not met, the controller will not be able to send
or receive a packet and it will hang causing a driver timeout and error.

This can be a problem if a class driver queues SG requests with many
small-buffer entries. The XHCI driver will create a chained TRB for each
entry which may trigger this issue.

This patch adds logic to the XHCI driver to detect and prevent this from
happening.

For every (TRB_CACHE_SIZE - 2), we check the total buffer size of
the SG list and if the last window of (TRB_CACHE_SIZE - 2) SG list length
and we don't make up at least 1 MPS, we create a temporary buffer to
consolidate full SG list into the buffer.

We check at (TRB_CACHE_SIZE - 2) window because it is possible that there
would be a link and/or event data TRB that take up to 2 of the cache
entries.

We discovered this issue with devices on other platforms but have not
yet come across any device that triggers this on Linux. But it could be
a real problem now or in the future. All it takes is N number of small
chained TRBs. And other instances of the Synopsys IP may have smaller
values for the TRB_CACHE_SIZE which would exacerbate the problem.
Signed-off-by: NTejas Joglekar <joglekar@synopsys.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20201208092912.1773650-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>