linux-stable.git/drivers/usb/host, branch v5.4.58 Linux kernel stable tree usb: xhci: Fix ASMedia ASM1142 DMA addressing 2020-08-11T13:33:32+00:00 Forest Crossman cyrozap@gmail.com 2020-07-28T04:24:08+00:00 67afa25456d01f6e53c57a75e0242bb21ce9e649 commit ec37198acca7b4c17b96247697406e47aafe0605 upstream. I've confirmed that the ASMedia ASM1142 has the same problem as the ASM2142/ASM3142, in that it too reports that it supports 64-bit DMA addresses when in fact it does not. As with the ASM2142/ASM3142, this can cause problems on systems where the upper bits matter, and adding the XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue. Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Forest Crossman <cyrozap@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200728042408.180529-3-cyrozap@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ec37198acca7b4c17b96247697406e47aafe0605 upstream.

I've confirmed that the ASMedia ASM1142 has the same problem as the
ASM2142/ASM3142, in that it too reports that it supports 64-bit DMA
addresses when in fact it does not. As with the ASM2142/ASM3142, this
can cause problems on systems where the upper bits matter, and adding
the XHCI_NO_64BIT_SUPPORT quirk completely fixes the issue.

Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Forest Crossman <cyrozap@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200728042408.180529-3-cyrozap@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: xhci: define IDs for various ASMedia host controllers 2020-08-11T13:33:32+00:00 Forest Crossman cyrozap@gmail.com 2020-07-28T04:24:07+00:00 e7ad225ba4ef39d1a8c52db511ac59806b13aa86 commit 1841cb255da41e87bed9573915891d056f80e2e7 upstream. Not all ASMedia host controllers have a device ID that matches its part number. #define some of these IDs to make it clearer at a glance which chips require what quirks. Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Forest Crossman <cyrozap@gmail.com> Link: https://lore.kernel.org/r/20200728042408.180529-2-cyrozap@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1841cb255da41e87bed9573915891d056f80e2e7 upstream.

Not all ASMedia host controllers have a device ID that matches its part
number. #define some of these IDs to make it clearer at a glance which
chips require what quirks.

Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Forest Crossman <cyrozap@gmail.com>
Link: https://lore.kernel.org/r/20200728042408.180529-2-cyrozap@gmail.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: xhci: Fix ASM2142/ASM3142 DMA addressing 2020-07-29T08:18:41+00:00 Forest Crossman cyrozap@gmail.com 2020-07-17T11:27:34+00:00 86894c3797ed03af5271b0cc0ebbfaf69393112a commit dbb0897e805f2ab1b8bc358f6c3d878a376b8897 upstream. The ASM2142/ASM3142 (same PCI IDs) does not support full 64-bit DMA addresses, which can cause silent memory corruption or IOMMU errors on platforms that use the upper bits. Add the XHCI_NO_64BIT_SUPPORT quirk to fix this issue. Signed-off-by: Forest Crossman <cyrozap@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200717112734.328432-1-cyrozap@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit dbb0897e805f2ab1b8bc358f6c3d878a376b8897 upstream.

The ASM2142/ASM3142 (same PCI IDs) does not support full 64-bit DMA
addresses, which can cause silent memory corruption or IOMMU errors on
platforms that use the upper bits. Add the XHCI_NO_64BIT_SUPPORT quirk
to fix this issue.

Signed-off-by: Forest Crossman <cyrozap@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200717112734.328432-1-cyrozap@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: xhci-mtk: fix the failure of bandwidth allocation 2020-07-29T08:18:41+00:00 Chunfeng Yun chunfeng.yun@mediatek.com 2020-07-10T05:57:52+00:00 1d91547f2fc88fb3cc7e82c17026c1acffc38c38 commit 5ce1a24dd98c00a57a8fa13660648abf7e08e3ef upstream. The wMaxPacketSize field of endpoint descriptor may be zero as default value in alternate interface, and they are not actually selected when start stream, so skip them when try to allocate bandwidth. Cc: stable <stable@vger.kernel.org> Fixes: 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller") Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1594360672-2076-1-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5ce1a24dd98c00a57a8fa13660648abf7e08e3ef upstream.

The wMaxPacketSize field of endpoint descriptor may be zero
as default value in alternate interface, and they are not
actually selected when start stream, so skip them when try to
allocate bandwidth.

Cc: stable <stable@vger.kernel.org>
Fixes: 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1594360672-2076-1-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "usb/xhci-plat: Set PM runtime as active on resume" 2020-07-22T07:32:56+00:00 Sasha Levin sashal@kernel.org 2020-07-17T17:01:26+00:00 11a6ff1df31eed59905c13e30c1d588ca3477fd8 This reverts commit 57a1cd87efb9279ab58aae2e5c41920150e31873. Eugeniu Rosca writes: On Thu, Jul 09, 2020 at 09:00:23AM +0200, Eugeniu Rosca wrote: >After integrating v4.14.186 commit 5410d158ca2a50 ("usb/ehci-platform: >Set PM runtime as active on resume") into downstream v4.14.x, we started >to consistently experience below panic [1] on every second s2ram of >R-Car H3 Salvator-X Renesas reference board. > >After some investigations, we concluded the following: > - the issue does not exist in vanilla v5.8-rc4+ > - [bisecting shows that] the panic on v4.14.186 is caused by the lack > of v5.6-rc1 commit 987351e1ea7772 ("phy: core: Add consumer device > link support"). Getting evidence for that is easy. Reverting > 987351e1ea7772 in vanilla leads to a similar backtrace [2]. > >Questions: > - Backporting 987351e1ea7772 ("phy: core: Add consumer device > link support") to v4.14.187 looks challenging enough, so probably not > worth it. Anybody to contradict this? > - Assuming no plans to backport the missing mainline commit to v4.14.x, > should the following three v4.14.186 commits be reverted on v4.14.x? > * baef809ea497a4 ("usb/ohci-platform: Fix a warning when hibernating") > * 9f33eff4958885 ("usb/xhci-plat: Set PM runtime as active on resume") > * 5410d158ca2a50 ("usb/ehci-platform: Set PM runtime as active on resume") Signed-off-by: Sasha Levin <sashal@kernel.org> 
This reverts commit 57a1cd87efb9279ab58aae2e5c41920150e31873.

Eugeniu Rosca writes:

On Thu, Jul 09, 2020 at 09:00:23AM +0200, Eugeniu Rosca wrote:
>After integrating v4.14.186 commit 5410d158ca2a50 ("usb/ehci-platform:
>Set PM runtime as active on resume") into downstream v4.14.x, we started
>to consistently experience below panic [1] on every second s2ram of
>R-Car H3 Salvator-X Renesas reference board.
>
>After some investigations, we concluded the following:
> - the issue does not exist in vanilla v5.8-rc4+
> - [bisecting shows that] the panic on v4.14.186 is caused by the lack
>   of v5.6-rc1 commit 987351e1ea7772 ("phy: core: Add consumer device
>   link support"). Getting evidence for that is easy. Reverting
>   987351e1ea7772 in vanilla leads to a similar backtrace [2].
>
>Questions:
> - Backporting 987351e1ea7772 ("phy: core: Add consumer device
>   link support") to v4.14.187 looks challenging enough, so probably not
>   worth it. Anybody to contradict this?
> - Assuming no plans to backport the missing mainline commit to v4.14.x,
>   should the following three v4.14.186 commits be reverted on v4.14.x?
>   * baef809ea497a4 ("usb/ohci-platform: Fix a warning when hibernating")
>   * 9f33eff4958885 ("usb/xhci-plat: Set PM runtime as active on resume")
>   * 5410d158ca2a50 ("usb/ehci-platform: Set PM runtime as active on resume")

Signed-off-by: Sasha Levin <sashal@kernel.org>
Revert "usb/ehci-platform: Set PM runtime as active on resume" 2020-07-22T07:32:56+00:00 Sasha Levin sashal@kernel.org 2020-07-17T17:01:10+00:00 4cf55dcd4fa40e1c0c2883b8e306a55de9c2f00d This reverts commit 335d720bb4bd9d2808cae5af6f3c636c87f19596. Eugeniu Rosca writes: On Thu, Jul 09, 2020 at 09:00:23AM +0200, Eugeniu Rosca wrote: >After integrating v4.14.186 commit 5410d158ca2a50 ("usb/ehci-platform: >Set PM runtime as active on resume") into downstream v4.14.x, we started >to consistently experience below panic [1] on every second s2ram of >R-Car H3 Salvator-X Renesas reference board. > >After some investigations, we concluded the following: > - the issue does not exist in vanilla v5.8-rc4+ > - [bisecting shows that] the panic on v4.14.186 is caused by the lack > of v5.6-rc1 commit 987351e1ea7772 ("phy: core: Add consumer device > link support"). Getting evidence for that is easy. Reverting > 987351e1ea7772 in vanilla leads to a similar backtrace [2]. > >Questions: > - Backporting 987351e1ea7772 ("phy: core: Add consumer device > link support") to v4.14.187 looks challenging enough, so probably not > worth it. Anybody to contradict this? > - Assuming no plans to backport the missing mainline commit to v4.14.x, > should the following three v4.14.186 commits be reverted on v4.14.x? > * baef809ea497a4 ("usb/ohci-platform: Fix a warning when hibernating") > * 9f33eff4958885 ("usb/xhci-plat: Set PM runtime as active on resume") > * 5410d158ca2a50 ("usb/ehci-platform: Set PM runtime as active on resume") Signed-off-by: Sasha Levin <sashal@kernel.org> 
This reverts commit 335d720bb4bd9d2808cae5af6f3c636c87f19596.

Eugeniu Rosca writes:

On Thu, Jul 09, 2020 at 09:00:23AM +0200, Eugeniu Rosca wrote:
>After integrating v4.14.186 commit 5410d158ca2a50 ("usb/ehci-platform:
>Set PM runtime as active on resume") into downstream v4.14.x, we started
>to consistently experience below panic [1] on every second s2ram of
>R-Car H3 Salvator-X Renesas reference board.
>
>After some investigations, we concluded the following:
> - the issue does not exist in vanilla v5.8-rc4+
> - [bisecting shows that] the panic on v4.14.186 is caused by the lack
>   of v5.6-rc1 commit 987351e1ea7772 ("phy: core: Add consumer device
>   link support"). Getting evidence for that is easy. Reverting
>   987351e1ea7772 in vanilla leads to a similar backtrace [2].
>
>Questions:
> - Backporting 987351e1ea7772 ("phy: core: Add consumer device
>   link support") to v4.14.187 looks challenging enough, so probably not
>   worth it. Anybody to contradict this?
> - Assuming no plans to backport the missing mainline commit to v4.14.x,
>   should the following three v4.14.186 commits be reverted on v4.14.x?
>   * baef809ea497a4 ("usb/ohci-platform: Fix a warning when hibernating")
>   * 9f33eff4958885 ("usb/xhci-plat: Set PM runtime as active on resume")
>   * 5410d158ca2a50 ("usb/ehci-platform: Set PM runtime as active on resume")

Signed-off-by: Sasha Levin <sashal@kernel.org>
Revert "usb/ohci-platform: Fix a warning when hibernating" 2020-07-22T07:32:55+00:00 Sasha Levin sashal@kernel.org 2020-07-17T17:00:47+00:00 add6b48ad376a8db6736b96a985877c2ca2e470a This reverts commit fbf719e5da126c6b391ea7b1f38d4493582d8aaf. Eugeniu Rosca writes: On Thu, Jul 09, 2020 at 09:00:23AM +0200, Eugeniu Rosca wrote: >After integrating v4.14.186 commit 5410d158ca2a50 ("usb/ehci-platform: >Set PM runtime as active on resume") into downstream v4.14.x, we started >to consistently experience below panic [1] on every second s2ram of >R-Car H3 Salvator-X Renesas reference board. > >After some investigations, we concluded the following: > - the issue does not exist in vanilla v5.8-rc4+ > - [bisecting shows that] the panic on v4.14.186 is caused by the lack > of v5.6-rc1 commit 987351e1ea7772 ("phy: core: Add consumer device > link support"). Getting evidence for that is easy. Reverting > 987351e1ea7772 in vanilla leads to a similar backtrace [2]. > >Questions: > - Backporting 987351e1ea7772 ("phy: core: Add consumer device > link support") to v4.14.187 looks challenging enough, so probably not > worth it. Anybody to contradict this? > - Assuming no plans to backport the missing mainline commit to v4.14.x, > should the following three v4.14.186 commits be reverted on v4.14.x? > * baef809ea497a4 ("usb/ohci-platform: Fix a warning when hibernating") > * 9f33eff4958885 ("usb/xhci-plat: Set PM runtime as active on resume") > * 5410d158ca2a50 ("usb/ehci-platform: Set PM runtime as active on resume") Signed-off-by: Sasha Levin <sashal@kernel.org> 
This reverts commit fbf719e5da126c6b391ea7b1f38d4493582d8aaf.

Eugeniu Rosca writes:

On Thu, Jul 09, 2020 at 09:00:23AM +0200, Eugeniu Rosca wrote:
>After integrating v4.14.186 commit 5410d158ca2a50 ("usb/ehci-platform:
>Set PM runtime as active on resume") into downstream v4.14.x, we started
>to consistently experience below panic [1] on every second s2ram of
>R-Car H3 Salvator-X Renesas reference board.
>
>After some investigations, we concluded the following:
> - the issue does not exist in vanilla v5.8-rc4+
> - [bisecting shows that] the panic on v4.14.186 is caused by the lack
>   of v5.6-rc1 commit 987351e1ea7772 ("phy: core: Add consumer device
>   link support"). Getting evidence for that is easy. Reverting
>   987351e1ea7772 in vanilla leads to a similar backtrace [2].
>
>Questions:
> - Backporting 987351e1ea7772 ("phy: core: Add consumer device
>   link support") to v4.14.187 looks challenging enough, so probably not
>   worth it. Anybody to contradict this?
> - Assuming no plans to backport the missing mainline commit to v4.14.x,
>   should the following three v4.14.186 commits be reverted on v4.14.x?
>   * baef809ea497a4 ("usb/ohci-platform: Fix a warning when hibernating")
>   * 9f33eff4958885 ("usb/xhci-plat: Set PM runtime as active on resume")
>   * 5410d158ca2a50 ("usb/ehci-platform: Set PM runtime as active on resume")

Signed-off-by: Sasha Levin <sashal@kernel.org>
xhci: Return if xHCI doesn't support LPM 2020-06-30T19:36:52+00:00 Kai-Heng Feng kai.heng.feng@canonical.com 2020-06-24T13:59:48+00:00 d6522bc320d7968a7977c30b6f2f3c6d79f1448f commit f0c472a6da51f9fac15e80fe2fd9c83b68754cff upstream. Just return if xHCI is quirked to disable LPM. We can save some time from reading registers and doing spinlocks. Add stable tag as we want this patch together with the next one, "Poll for U0 after disabling USB2 LPM" which fixes a suspend issue for some USB2 LPM devices Cc: stable@vger.kernel.org Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200624135949.22611-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f0c472a6da51f9fac15e80fe2fd9c83b68754cff upstream.

Just return if xHCI is quirked to disable LPM. We can save some time
from reading registers and doing spinlocks.

Add stable tag as we want this patch together with the next one,
"Poll for U0 after disabling USB2 LPM" which fixes a suspend issue
for some USB2 LPM devices

Cc: stable@vger.kernel.org
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200624135949.22611-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci: Fix enumeration issue when setting max packet size for FS devices. 2020-06-30T19:36:52+00:00 Al Cooper alcooperx@gmail.com 2020-06-24T13:59:46+00:00 14d46386226e102e43ee535ac74306b7489180b0 commit a73d9d9cfc3cfceabd91fb0b0c13e4062b6dbcd7 upstream. Unable to complete the enumeration of a USB TV Tuner device. Per XHCI spec (4.6.5), the EP state field of the input context shall be cleared for a set address command. In the special case of an FS device that has "MaxPacketSize0 = 8", the Linux XHCI driver does not do this before evaluating the context. With an XHCI controller that checks the EP state field for parameter context error this causes a problem in cases such as the device getting reset again after enumeration. When that field is cleared, the problem does not occur. This was found and fixed by Sasi Kumar. Cc: stable@vger.kernel.org Signed-off-by: Al Cooper <alcooperx@gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200624135949.22611-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a73d9d9cfc3cfceabd91fb0b0c13e4062b6dbcd7 upstream.

Unable to complete the enumeration of a USB TV Tuner device.

Per XHCI spec (4.6.5), the EP state field of the input context shall
be cleared for a set address command. In the special case of an FS
device that has "MaxPacketSize0 = 8", the Linux XHCI driver does
not do this before evaluating the context. With an XHCI controller
that checks the EP state field for parameter context error this
causes a problem in cases such as the device getting reset again
after enumeration.

When that field is cleared, the problem does not occur.

This was found and fixed by Sasi Kumar.

Cc: stable@vger.kernel.org
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200624135949.22611-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xhci: Fix incorrect EP_STATE_MASK 2020-06-30T19:36:51+00:00 Mathias Nyman mathias.nyman@linux.intel.com 2020-06-24T13:59:45+00:00 c09be4f57956deae7b9dbee3a35811a2a9c45d99 commit dceea67058fe22075db3aed62d5cb62092be5053 upstream. EP_STATE_MASK should be 0x7 instead of 0xf xhci spec 6.2.3 shows that the EP state field in the endpoint context data structure consist of bits [2:0]. The old value included a bit from the next field which fortunately is a RsvdZ region. So hopefully this hasn't caused too much harm Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200624135949.22611-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit dceea67058fe22075db3aed62d5cb62092be5053 upstream.

EP_STATE_MASK should be 0x7 instead of 0xf

xhci spec 6.2.3 shows that the EP state field in the endpoint context data
structure consist of bits [2:0].
The old value included a bit from the next field which fortunately is a
 RsvdZ region. So hopefully this hasn't caused too much harm

Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200624135949.22611-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>