linux-stable.git/drivers/usb/host, branch v5.4.161

usb: xhci: Enable runtime-pm by default on AMD Yellow Carp platform

2021-11-17T08:48:16+00:00

commit 660a92a59b9e831a0407e41ff62875656d30006e upstream.

AMD's Yellow Carp platform supports runtime power management for
XHCI Controllers, so enable the same by default for all XHCI Controllers.

[ regrouped and aligned the PCI_DEVICE_ID definitions -Mathias]

Cc: stable 
Reviewed-by: Shyam Sundar S K 
Reviewed-by: Mario Limonciello 
Reviewed-by: Basavaraj Natikar 
Signed-off-by: Nehal Bakulchandra Shah 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20211014121200.75433-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

xhci: Fix USB 3.1 enumeration issues by increasing roothub power-on-good delay

2021-11-17T08:48:16+00:00

commit e1959faf085b004e6c3afaaaa743381f00e7c015 upstream.

Some USB 3.1 enumeration issues were reported after the hub driver removed
the minimum 100ms limit for the power-on-good delay.

Since commit 90d28fb53d4a ("usb: core: reduce power-on-good delay time of
root hub") the hub driver sets the power-on-delay based on the
bPwrOn2PwrGood value in the hub descriptor.

xhci driver has a 20ms bPwrOn2PwrGood value for both roothubs based
on xhci spec section 5.4.8, but it's clearly not enough for the
USB 3.1 devices, causing enumeration issues.

Tests indicate full 100ms delay is needed.

Reported-by: Walt Jr. Brake 
Signed-off-by: Mathias Nyman 
Fixes: 90d28fb53d4a ("usb: core: reduce power-on-good delay time of root hub")
Cc: stable 
Link: https://lore.kernel.org/r/20211105160036.549516-1-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: ehci: handshake CMD_RUN instead of STS_HALT

2021-11-12T13:43:02+00:00

commit 7f2d73788d9067fd4f677ac5f60ffd25945af7af upstream.

For Aspeed, HCHalted status depends on not only Run/Stop but also
ASS/PSS status.
Handshake CMD_RUN on startup instead.

Tested-by: Tao Ren 
Reviewed-by: Tao Ren 
Acked-by: Alan Stern 
Signed-off-by: Neal Liu 
Link: https://lore.kernel.org/r/20210910073619.26095-1-neal_liu@aspeedtech.com
Cc: Joel Stanley 
Signed-off-by: Greg Kroah-Hartman

Revert "xhci: Set HCD flag to defer primary roothub registration"

2021-11-06T12:59:45+00:00

This reverts commit 2d7c20db7220bc8dbc560de6e58f024696c790e5 which is
commit b7a0a792f864583207c593b50fd1b752ed89f4c1 upstream.

It has been reported to be causing problems in Arch and Fedora bug
reports.

Reported-by: Hans de Goede 
Link: https://bbs.archlinux.org/viewtopic.php?pid=2000956#p2000956
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019542
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019576
Link: https://lore.kernel.org/r/42bcbea6-5eb8-16c7-336a-2cb72e71bc36@redhat.com
Cc: Mathias Nyman 
Cc: Chris Chiu 
Cc: Alan Stern 
Cc: Kishon Vijay Abraham I 
Signed-off-by: Greg Kroah-Hartman

xhci: Enable trust tx length quirk for Fresco FL11 USB controller

2021-10-20T09:40:13+00:00

commit ea0f69d8211963c4b2cc1998b86779a500adb502 upstream.

Tested on SD5200T TB3 dock which has Fresco Logic FL1100 USB 3.0 Host
Controller.
Before this patch streaming video from USB cam made mouse and keyboard
connected to the same USB bus unusable. Also video was jerky.
With this patch streaming video doesn't have any effect on other
periferals and video is smooth.

Cc: stable@vger.kernel.org
Signed-off-by: Nikolay Martynov 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20211008092547.3996295-6-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

xhci: Fix command ring pointer corruption while aborting a command

2021-10-20T09:40:13+00:00

commit ff0e50d3564f33b7f4b35cadeabd951d66cfc570 upstream.

The command ring pointer is located at [6:63] bits of the command
ring control register (CRCR). All the control bits like command stop,
abort are located at [0:3] bits. While aborting a command, we read the
CRCR and set the abort bit and write to the CRCR. The read will always
give command ring pointer as all zeros. So we essentially write only
the control bits. Since we split the 64 bit write into two 32 bit writes,
there is a possibility of xHC command ring stopped before the upper
dword (all zeros) is written. If that happens, xHC updates the upper
dword of its internal command ring pointer with all zeros. Next time,
when the command ring is restarted, we see xHC memory access failures.
Fix this issue by only writing to the lower dword of CRCR where all
control bits are located.

Cc: stable@vger.kernel.org
Signed-off-by: Pavankumar Kondeti 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20211008092547.3996295-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

xhci: guard accesses to ep_state in xhci_endpoint_reset()

2021-10-20T09:40:13+00:00

commit a01ba2a3378be85538e0183ae5367c1bc1d5aaf3 upstream.

See https://github.com/raspberrypi/linux/issues/3981

Two read-modify-write cycles on ep->ep_state are not guarded by
xhci->lock. Fix these.

Fixes: f5249461b504 ("xhci: Clear the host side toggle manually when endpoint is soft reset")
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Bell 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20211008092547.3996295-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

xhci: Set HCD flag to defer primary roothub registration

2021-09-30T08:09:22+00:00

commit b7a0a792f864583207c593b50fd1b752ed89f4c1 upstream.

Set "HCD_FLAG_DEFER_RH_REGISTER" to hcd->flags in xhci_run() to defer
registering primary roothub in usb_add_hcd(). This will make sure both
primary roothub and secondary roothub will be registered along with the
second HCD. This is required for cold plugged USB devices to be detected
in certain PCIe USB cards (like Inateck USB card connected to AM64 EVM
or J7200 EVM).

CC: stable@vger.kernel.org # 5.4+
Suggested-by: Mathias Nyman 
Tested-by: Chris Chiu 
Signed-off-by: Kishon Vijay Abraham I 
Link: https://lore.kernel.org/r/20210909064200.16216-3-kishon@ti.com
Signed-off-by: Greg Kroah-Hartman

Revert "USB: xhci: fix U1/U2 handling for hardware with XHCI_INTEL_HOST quirk set"

2021-09-22T10:26:35+00:00

[ Upstream commit 2847c46c61486fd8bca9136a6e27177212e78c69 ]

This reverts commit 5d5323a6f3625f101dbfa94ba3ef7706cce38760.

That commit effectively disabled Intel host initiated U1/U2 lpm for devices
with periodic endpoints.

Before that commit we disabled host initiated U1/U2 lpm if the exit latency
was larger than any periodic endpoint service interval, this is according
to xhci spec xhci 1.1 specification section 4.23.5.2

After that commit we incorrectly checked that service interval was smaller
than U1/U2 inactivity timeout. This is not relevant, and can't happen for
Intel hosts as previously set U1/U2 timeout = 105% * service interval.

Patch claimed it solved cases where devices can't be enumerated because of
bandwidth issues. This might be true but it's a side effect of accidentally
turning off lpm.

exit latency calculations have been revised since then

Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20210820123503.2605901-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: EHCI: ehci-mv: improve error handling in mv_ehci_enable()

2021-09-22T10:26:28+00:00

[ Upstream commit 61136a12cbed234374ec6f588af57c580b20b772 ]

mv_ehci_enable() did not disable and unprepare clocks in case of
failures of phy_init(). Besides, it did not take into account failures
of ehci_clock_enable() (in effect, failures of clk_prepare_enable()).
The patch fixes both issues and gets rid of redundant wrappers around
clk_prepare_enable() and clk_disable_unprepare() to simplify this a bit.

Found by Linux Driver Verification project (linuxtesting.org).

Acked-by: Alan Stern 
Signed-off-by: Evgeny Novikov 
Link: https://lore.kernel.org/r/20210708083056.21543-1-novikov@ispras.ru
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin