linux.git/drivers/usb/host, branch v5.12.5

xhci: Add reset resume quirk for AMD xhci controller.

2021-05-19T08:56:41+00:00

commit 3c128781d8da463761495aaf8898c9ecb4e71528 upstream.

One of AMD xhci controller require reset on resume.
Occasionally AMD xhci controller does not respond to
Stop endpoint command.
Once the issue happens controller goes into bad state
and in that case controller needs to be reset.

Cc: 
Signed-off-by: Sandeep Singh 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20210512080816.866037-6-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

xhci: Do not use GFP_KERNEL in (potentially) atomic context

2021-05-19T08:56:40+00:00

commit dda32c00c9a0fa103b5d54ef72c477b7aa993679 upstream.

'xhci_urb_enqueue()' is passed a 'mem_flags' argument, because "URBs may be
submitted in interrupt context" (see comment related to 'usb_submit_urb()'
in 'drivers/usb/core/urb.c')

So this flag should be used in all the calling chain.
Up to now, 'xhci_check_maxpacket()' which is only called from
'xhci_urb_enqueue()', uses GFP_KERNEL.

Be safe and pass the mem_flags to this function as well.

Fixes: ddba5cd0aeff ("xhci: Use command structures when queuing commands on the command ring")
Cc: 
Signed-off-by: Christophe JAILLET 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20210512080816.866037-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

xhci: Fix giving back cancelled URBs even if halted endpoint can't reset

2021-05-19T08:56:40+00:00

commit 9b6a126ae58d9edfdde2d5f2e87f7615ea5e0155 upstream.

Commit 9ebf30007858 ("xhci: Fix halted endpoint at stop endpoint command
completion") in 5.12 changes how cancelled URBs are given back.

To cancel a URB xhci driver needs to stop the endpoint first.
To clear a halted endpoint xhci driver needs to reset the endpoint.

In rare cases when an endpoint halt (error) races with a endpoint stop we
need to clear the reset before removing, and giving back the cancelled URB.

The above change in 5.12 takes care of this, but it also relies on the
reset endpoint completion handler to give back the cancelled URBs.

There are cases when driver refuses to queue reset endpoint commands,
for example when a link suddenly goes to an inactive error state.
In this case the cancelled URB is never given back.

Fix this by giving back the URB in the stop endpoint if queuing a reset
endpoint command fails.

Fixes: 9ebf30007858 ("xhci: Fix halted endpoint at stop endpoint command completion")
CC:  # 5.12
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20210512080816.866037-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

xhci-pci: Allow host runtime PM as default for Intel Alder Lake xHCI

2021-05-19T08:56:40+00:00

commit b813511135e8b84fa741afdfbab4937919100bef upstream.

In the same way as Intel Tiger Lake TCSS (Type-C Subsystem) the Alder Lake
TCSS xHCI needs to be runtime suspended whenever possible to allow the
TCSS hardware block to enter D3cold and thus save energy.

Cc: stable@vger.kernel.org
Signed-off-by: Abhijeet Rao 
Signed-off-by: Nikunj A. Dadhania 
Signed-off-by: Azhar Shaikh 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20210512080816.866037-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: xhci: Increase timeout for HC halt

2021-05-19T08:56:39+00:00

commit ca09b1bea63ab83f4cca3a2ae8bc4f597ec28851 upstream.

On some devices (specifically the SC8180x based Surface Pro X with
QCOM04A6) HC halt / xhci_halt() times out during boot. Manually binding
the xhci-hcd driver at some point later does not exhibit this behavior.
To work around this, double XHCI_MAX_HALT_USEC, which also resolves this
issue.

Cc: 
Signed-off-by: Maximilian Luz 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20210512080816.866037-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: fotg210-hcd: Fix an error message

2021-05-19T08:56:37+00:00

[ Upstream commit a60a34366e0d09ca002c966dd7c43a68c28b1f82 ]

'retval' is known to be -ENODEV here.
This is a hard-coded default error code which is not useful in the error
message. Moreover, another error message is printed at the end of the
error handling path. The corresponding error code (-ENOMEM) is more
informative.

So remove simplify the first error message.

While at it, also remove the useless initialization of 'retval'.

Fixes: 7d50195f6c50 ("usb: host: Faraday fotg210-hcd driver")
Signed-off-by: Christophe JAILLET 
Link: https://lore.kernel.org/r/94531bcff98e46d4f9c20183a90b7f47f699126c.1620333419.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: host: ehci-tegra: Select USB_GADGET Kconfig option

2021-05-14T08:52:21+00:00

[ Upstream commit 0b9828763aeafa5e527b9d98b8789bdb34937fbc ]

Select USB_GADGET Kconfig option in order to fix build failure which
happens because ChipIdea driver has a build dependency on both USB_GADGET
and USB_EHCI_HCD, while USB_EHCI_TEGRA force-selects the ChipIdea driver
without taking into account the tristate USB_GADGET dependency. It's not
possible to do anything about the cyclic dependency of the Kconfig
options, but USB_EHCI_TEGRA is now a deprecated option that isn't used
by defconfigs and USB_GADGET is wanted on Tegra by default, hence it's
okay to have a bit clunky workaround for it.

Fixes: c3590c7656fb ("usb: host: ehci-tegra: Remove the driver")
Reported-by: kernel test robot 
Acked-by: Alan Stern 
Signed-off-by: Dmitry Osipenko 
Link: https://lore.kernel.org/r/20210320151915.7566-2-digetx@gmail.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: xhci-mtk: improve bandwidth scheduling with TT

2021-05-14T08:52:03+00:00

commit e19ee44a3d07c232f9241024dab1ebd0748cdf5f upstream.

When the USB headset is plug into an external hub, sometimes
can't set config due to not enough bandwidth, so need improve
LS/FS INT/ISOC bandwidth scheduling with TT.

Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints")
Cc: stable 
Signed-off-by: Yaqii Wu 
Signed-off-by: Chunfeng Yun 
Link: https://lore.kernel.org/r/2f30e81400a59afef5f8231c98149169c7520519.1615170625.git.chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman

usb: xhci-mtk: remove or operator for setting schedule parameters

2021-05-14T08:52:03+00:00

commit 5fa5827566e3affa1657ccf9b22706c06a5d021a upstream.

Side effect may happen if use or operator to set schedule parameters
when the parameters are already set before. Set them directly due to
other bits are reserved.

Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints")
Cc: stable 
Signed-off-by: Chunfeng Yun 
Link: https://lore.kernel.org/r/d287899e6beb2fc1bfb8900c75a872f628ecde55.1615170625.git.chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman

xhci: prevent double-fetch of transfer and transfer event TRBs

2021-05-12T06:39:37+00:00

[ Upstream commit e9fcb07704fcef6fa6d0333fd2b3a62442eaf45b ]

The same values are parsed several times from transfer and event
TRBs by different functions in the same call path, all while processing
one transfer event.

As the TRBs are in DMA memory and can be accessed by the xHC host we want
to avoid this to prevent double-fetch issues.

To resolve this pass the already parsed values to the different functions
in the path of parsing a transfer event

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