- 21 6月, 2023 1 次提交
-
-
由 Longfang Liu 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7DZ8S CVE: NA ---------------------------------------------------------------------- When the current HiSilicon USB xhci controller formats the faulty U disk, it will trigger a controller exception error. This will cause errors in the control logic of the xhci controller and driver software. In the end, all USB devices on the xhci controller cannot be used. By introducing a noop command operation, restore the logic of the xhci controller and driver software, and restore all USB devices on the xhci controller to normal. Signed-off-by: NLongfang Liu <liulongfang@huawei.com> (cherry picked from commit 1a869403)
-
- 23 5月, 2023 1 次提交
-
-
由 Mathias Nyman 提交于
stable inclusion from stable-v5.10.153 commit 3b250824b6d3f109c8c18652280f7120c3803545 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3b250824b6d3f109c8c18652280f7120c3803545 -------------------------------- commit 34cd2db4 upstream. Systems based on Alder Lake P see significant boot time delay if boot firmware tries to control usb ports in unexpected link states. This is seen with self-powered usb devices that survive in U3 link suspended state over S5. A more generic solution to power off ports at shutdown was attempted in commit 83810f84 ("xhci: turn off port power in shutdown") but it caused regression. Add host specific XHCI_RESET_TO_DEFAULT quirk which will reset host and ports back to default state in shutdown. Cc: stable@vger.kernel.org Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20221024142720.4122053-3-mathias.nyman@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> Conflicts: drivers/usb/host/xhci.h
-
- 19 4月, 2023 1 次提交
-
-
由 Justin Chen 提交于
stable inclusion from stable-v5.10.150 commit c13d0d2f5a4806cef87693966091b5fd3f5c225f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0XA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c13d0d2f5a4806cef87693966091b5fd3f5c225f -------------------------------- [ Upstream commit 8bd954c5 ] Introduce XHCI_SUSPEND_RESUME_CLKS quirk as a means to suspend and resume clocks if the hardware is capable of doing so. We assume that clocks will be needed if the device may wake. Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NJustin Chen <justinpopo6@gmail.com> Link: https://lore.kernel.org/r/1660170455-15781-2-git-send-email-justinpopo6@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Conflicts: drivers/usb/host/xhci.h
-
- 09 2月, 2023 2 次提交
-
-
由 Mathias Nyman 提交于
stable inclusion from stable-v5.10.142 commit 5a603f4c127377dde986fe86670972e94312ae51 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6CSFH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5a603f4c127377dde986fe86670972e94312ae51 -------------------------------- commit 33e32158 upstream. After xHC controller is started, either in probe or resume, it can take a while before any of the connected usb devices are visible to the roothub due to link training. It's possible xhci driver loads, sees no acivity and suspends the host before the USB device is visible. In one testcase with a hotplugged xHC controller the host finally detected the connected USB device and generated a wake 500ms after host initial start. If hosts didn't suspend the device duringe training it probablty wouldn't take up to 500ms to detect it, but looking at specs reveal USB3 link training has a couple long timeout values, such as 120ms RxDetectQuietTimeout, and 360ms PollingLFPSTimeout. So Add a 500ms grace period that keeps polling the roothub for 500ms after start, preventing runtime suspend until USB devices are detected. Cc: stable@vger.kernel.org Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220825150840.132216-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Mathias Nyman 提交于
stable inclusion from stable-v5.10.142 commit c0cb63ee2e22df6440889d63875a025b678c7686 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6CSFH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c0cb63ee2e22df6440889d63875a025b678c7686 -------------------------------- [ Upstream commit 8531aa16 ] This reverts commit 83810f84. Turning off port power in shutdown did cause issues such as a laptop not proprly powering off, and some specific usb devies failing to enumerate the subsequent boot after a warm reset. So revert this. Fixes: 83810f84 ("xhci: turn off port power in shutdown") Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220825150840.132216-4-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 18 11月, 2022 1 次提交
-
-
由 Sergey Shtylyov 提交于
stable inclusion from stable-v5.10.137 commit b840c2926de2fbfcfef72c4373ef9d8057867349 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I60PLB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b840c2926de2fbfcfef72c4373ef9d8057867349 -------------------------------- [ Upstream commit 1ce69c35 ] Commit cbf286e8 ("xhci: fix unsafe memory usage in xhci tracing") apparently missed one sprintf() call in xhci_decode_trb() -- replace it with the snprintf() call as well... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: cbf286e8 ("xhci: fix unsafe memory usage in xhci tracing") Signed-off-by: NSergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220630124645.1805902-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
- 27 10月, 2022 1 次提交
-
-
由 Mathias Nyman 提交于
stable inclusion from stable-v5.10.127 commit b8142a84657eb464e4d7b2f6e509fdf70629bcb2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5XDDK Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b8142a84657eb464e4d7b2f6e509fdf70629bcb2 -------------------------------- commit 83810f84 upstream. If ports are not turned off in shutdown then runtime suspended self-powered USB devices may survive in U3 link state over S5. During subsequent boot, if firmware sends an IPC command to program the port in DISCONNECT state, it will time out, causing significant delay in the boot time. Turning off roothub port power is also recommended in xhci specification 4.19.4 "Port Power" in the additional note. Cc: stable@vger.kernel.org Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220623111945.1557702-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com>
-
- 06 7月, 2022 3 次提交
-
-
由 Anssi Hannula 提交于
stable inclusion from stable-v5.10.110 commit 0a0c61dd071d7affdbfcf0d87dc5cb10b1d0980c bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0a0c61dd071d7affdbfcf0d87dc5cb10b1d0980c -------------------------------- commit 05519b85 upstream. xhci_decode_ctrl_ctx() returns the untouched buffer as-is if both "drop" and "add" parameters are zero. Fix the function to return an empty string in that case. It was not immediately clear from the possible call chains whether this issue is currently actually triggerable or not. Note that before commit 4843b4b5 ("xhci: fix even more unsafe memory usage in xhci tracing") the result effect in the failure case was different as a static buffer was used here, but the code still worked incorrectly. Fixes: 90d6d573 ("xhci: Add tracing for input control context") Cc: stable@vger.kernel.org Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> commit 4843b4b5 ("xhci: fix even more unsafe memory usage in xhci tracing") Link: https://lore.kernel.org/r/20220303110903.1662404-4-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Mathias Nyman 提交于
stable inclusion from stable-v5.10.110 commit 811f4035194912ac2cb89965dd0851125634b3c8 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=811f4035194912ac2cb89965dd0851125634b3c8 -------------------------------- commit 14073ce9 upstream. xhci_reset() timeout was increased from 250ms to 10 seconds in order to give Renesas 720201 xHC enough time to get ready in probe. xhci_reset() is called with interrupts disabled in other places, and waiting for 10 seconds there is not acceptable. Add a timeout parameter to xhci_reset(), and adjust it back to 250ms when called from xhci_stop() or xhci_shutdown() where interrupts are disabled, and successful reset isn't that critical. This solves issues when deactivating host mode on platforms like SM8450. For now don't change the timeout if xHC is reset in xhci_resume(). No issues are reported for it, and we need the reset to succeed. Locking around that reset needs to be revisited later. Additionally change the signed integer timeout parameter in xhci_handshake() to a u64 to match the timeout value we pass to readl_poll_timeout_atomic() Fixes: 22ceac19 ("xhci: Increase reset timeout for Renesas 720201 host.") Cc: stable@vger.kernel.org Reported-by: NSergey Shtylyov <s.shtylyov@omp.ru> Reported-by: NPavan Kondeti <quic_pkondeti@quicinc.com> Tested-by: NPavan Kondeti <quic_pkondeti@quicinc.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Anssi Hannula 提交于
stable inclusion from stable-v5.10.110 commit c41387f96a223726ca00b011ed3c1e9a645f7ac5 bugzilla: https://gitee.com/openeuler/kernel/issues/I574AL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c41387f96a223726ca00b011ed3c1e9a645f7ac5 -------------------------------- commit 3105bc97 upstream. xhci_decode_usbsts() is expected to return a zero-terminated string by its only caller, xhci_stop_endpoint_command_watchdog(), which directly logs the return value: xhci_warn(xhci, "USBSTS:%s\n", xhci_decode_usbsts(str, usbsts)); However, if no recognized bits are set in usbsts, the function will return without having called any sprintf() and therefore return an untouched non-zero-terminated caller-provided buffer, causing garbage to be output to log. Fix that by always including the raw value in the output. Note that before commit 4843b4b5 ("xhci: fix even more unsafe memory usage in xhci tracing") the result effect in the failure case was different as a static buffer was used here, but the code still worked incorrectly. Fixes: 9c1aa36e ("xhci: Show host status when watchdog triggers and host is assumed dead.") Cc: stable@vger.kernel.org Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220303110903.1662404-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYu Liao <liaoyu15@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 15 11月, 2021 1 次提交
-
-
由 Jonathan Bell 提交于
stable inclusion from stable-5.10.76 commit b6f32897af190d4716412e156ee0abcc16e4f1e5 bugzilla: 182988 https://gitee.com/openeuler/kernel/issues/I4IAHF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b6f32897af190d4716412e156ee0abcc16e4f1e5 -------------------------------- commit 5255660b upstream. Seen on a VLI VL805 PCIe to USB controller. For non-stream endpoints at least, if the xHC halts on a particular TRB due to an error then the DCS field in the Out Endpoint Context maintained by the hardware is not updated with the current cycle state. Using the quirk XHCI_EP_CTX_BROKEN_DCS and instead fetch the DCS bit from the TRB that the xHC stopped on. [ bjorn: rebased to v5.14-rc2 ] Link: https://github.com/raspberrypi/linux/issues/3060 Cc: stable@vger.kernel.org Signed-off-by: NJonathan Bell <jonathan@raspberrypi.org> Signed-off-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211008092547.3996295-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 19 10月, 2021 2 次提交
-
-
由 Mathias Nyman 提交于
stable inclusion from stable-5.10.64 commit 1234849353b09b40f6c7189641e22e0e2040e91d bugzilla: 182256 https://gitee.com/openeuler/kernel/issues/I4EG0U Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1234849353b09b40f6c7189641e22e0e2040e91d -------------------------------- commit cbf286e8 upstream. Removes static char buffer usage in the following decode functions: xhci_decode_trb() xhci_decode_ptortsc() Caller must provide a buffer to use. In tracing use __get_str() as recommended to pass buffer. Minor chanes are needed in xhci debugfs code as these functions are also used there. Changes include moving XHCI_MSG_MAX definititon from xhci-trace.h to xhci.h Cc: <stable@vger.kernel.org> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Mathias Nyman 提交于
stable inclusion from stable-5.10.64 commit 3f7f1baf7045c6a418d5858de23e9f5c6c58d5ff bugzilla: 182256 https://gitee.com/openeuler/kernel/issues/I4EG0U Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3f7f1baf7045c6a418d5858de23e9f5c6c58d5ff -------------------------------- commit 4843b4b5 upstream. Removes static char buffer usage in the following decode functions: xhci_decode_ctrl_ctx() xhci_decode_slot_context() xhci_decode_usbsts() xhci_decode_doorbell() xhci_decode_ep_context() Caller must provide a buffer to use. In tracing use __get_str() as recommended to pass buffer. Minor changes are needed in other xhci code as these functions are also used elsewhere Cc: <stable@vger.kernel.org> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 15 10月, 2021 1 次提交
-
-
由 Mathias Nyman 提交于
stable inclusion from stable-5.10.54 commit ba28765d338ae849af3fc60346f9d457df0cffb3 bugzilla: 175586 https://gitee.com/openeuler/kernel/issues/I4DVDU Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ba28765d338ae849af3fc60346f9d457df0cffb3 -------------------------------- [commit b1adc42d upstream] In several event handlers we need to find the right endpoint structure from slot_id and ep_index in the event. Add a helper for this, check that slot_id and ep_index are valid. Cc: stable@vger.kernel.org Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210129130044.206855-6-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NCarsten Schmid <carsten_schmid@mentor.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 23 7月, 2021 2 次提交
-
-
由 LeoLiu-oc 提交于
zhaoxin inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I40QDN CVE: NA ---------------------------------------------------------------- On some Zhaoxin platforms, xHCI will prefetch TRB for performance improvement. However this TRB prefetch mechanism may cross page boundary, which may access memory not belong to xHCI. In order to fix this issue, using two pages for TRB allocate and only the first page will be used. Signed-off-by: NLeoLiu-oc <LeoLiu-oc@zhaoxin.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 LeoLiu-oc 提交于
zhaoxin inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I40QDN CVE: NA ---------------------------------------------------------------- Add LPM u1/u2 feature support for xHCI of zhaoxin Signed-off-by: NLeoLiu-oc <LeoLiu-oc@zhaoxin.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 09 4月, 2021 1 次提交
-
-
由 Stanislaw Gruszka 提交于
stable inclusion from stable-5.10.24 commit 203060896dbebcd4e0aab6c34cac03d33527ed21 bugzilla: 51348 -------------------------------- commit a4a251f8 upstream. On some systems rt2800usb and mt7601u devices are unable to operate since commit f8f80be5 ("xhci: Use soft retry to recover faster from transaction errors") Seems that some xHCI controllers can not perform Soft Retry correctly, affecting those devices. To avoid the problem add xhci->quirks flag that restore pre soft retry xhci behaviour for affected xHCI controllers. Currently those are AMD_PROMONTORYA_4 and AMD_PROMONTORYA_2, since it was confirmed by the users: on those xHCI hosts issue happen and is gone after disabling Soft Retry. [minor commit message rewording for checkpatch -Mathias] Fixes: f8f80be5 ("xhci: Use soft retry to recover faster from transaction errors") Cc: <stable@vger.kernel.org> # 4.20+ Reported-by: NBernhard <bernhard.gebetsberger@gmx.at> Tested-by: NBernhard <bernhard.gebetsberger@gmx.at> Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202541 Link: https://lore.kernel.org/r/20210311115353.2137560-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: N Weilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 09 3月, 2021 1 次提交
-
-
由 Ikjoon Jang 提交于
stable inclusion from stable-5.10.15 commit 5139bf6a3455c0a9ddaf1c8cb20a50a649ecac55 bugzilla: 48167 -------------------------------- commit 1d69f9d9 upstream. xhci-mtk needs XHCI_MTK_HOST quirk functions in add_endpoint() and drop_endpoint() to handle its own sw bandwidth management. It stores bandwidth data into an internal table every time add_endpoint() is called, and drops those in drop_endpoint(). But when bandwidth allocation fails at one endpoint, all earlier allocation from the same interface could still remain at the table. This patch moves bandwidth management codes to check_bandwidth() and reset_bandwidth() path. To do so, this patch also adds those functions to xhci_driver_overrides and lets mtk-xhci to release all failed endpoints in reset_bandwidth() path. Fixes: 08e469de ("usb: xhci-mtk: supports bandwidth scheduling with multi-TT") Signed-off-by: NIkjoon Jang <ikjn@chromium.org> Link: https://lore.kernel.org/r/20210113180444.v6.1.Id0d31b5f3ddf5e734d2ab11161ac5821921b1e1e@changeid Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
- 07 1月, 2021 1 次提交
-
-
由 Tejas Joglekar 提交于
stable inclusion from stable-5.10.2 commit 1bee58e891f26a4246ad10fcc9c8c7e173a898f4 bugzilla: 46859 -------------------------------- commit bac1ec55 upstream. This commit uses the private data passed by parent device to set the quirk for Synopsys xHC. This patch fixes the SNPS xHC hang issue when the data is scattered across small buffers which does not make atleast MPS size for given TRB cache size of SNPS xHC. 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-2-mathias.nyman@linux.intel.com Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com>
-
- 29 10月, 2020 1 次提交
-
-
由 Sandeep Singh 提交于
On some platform of AMD, S3 fails with HCE and SRE errors. To fix this, need to disable a bit which is enable in sparse controller. Cc: stable@vger.kernel.org #v4.19+ Signed-off-by: NSanket Goswami <Sanket.Goswami@amd.com> Signed-off-by: NSandeep Singh <sandeep.singh@amd.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20201028203124.375344-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 20 9月, 2020 1 次提交
-
-
由 Peter Chen 提交于
Some DRD controllers (eg, dwc3 & cdns3) have PHY management at their own driver to cover both device and host mode, so add one priv quirk for such users to skip PHY management from HCD core. Reviewed-by: NJun Li <jun.li@nxp.com> Signed-off-by: NPeter Chen <peter.chen@nxp.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200918131752.16488-5-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 18 8月, 2020 1 次提交
-
-
由 Nicolas Saenz Julienne 提交于
Some atypical users of xhci-pci might need to manually reset their xHCI controller before starting the HCD setup. Check if a reset controller device is available to the PCI bus and trigger a reset. Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com> Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de> Link: https://lore.kernel.org/r/20200629161845.6021-6-nsaenzjulienne@suse.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 23 7月, 2020 1 次提交
-
-
由 Mathias Nyman 提交于
The generic xhci ring allocations code needs struct xhci_hcd pointer, and it allocates memory for the rings from dma pools created for the xhci device. In order to decouple xhci and DbC we have to create our own ring allocation and free routines for DbC Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200723144530.9992-20-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 24 6月, 2020 1 次提交
-
-
由 Mathias Nyman 提交于
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: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200624135949.22611-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 15 5月, 2020 1 次提交
-
-
由 Vinod Koul 提交于
Some rensas controller like uPD720201 and uPD720202 need firmware to be loaded. Add these devices in table and invoke renesas firmware loader functions to check and load the firmware into device memory when required. Signed-off-by: NVinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200514122039.300417-4-vkoul@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 4月, 2020 1 次提交
-
-
由 Mathias Nyman 提交于
If a class driver cancels its only URB then the endpoint ring buffer will appear empty to the xhci driver. xHC hardware may still process cached TRBs, and complete with a STALL, halting the endpoint. This halted endpoint was not handled correctly by xhci driver as events on empty rings were all assumed to be spurious events. xhci driver refused to restart the ring with EP_HALTED flag set, so class driver was never informed the endpoint halted even if it queued new URBs. The host side of the endpoint needs to be reset, and dequeue pointer should be moved in order to clear the cached TRBs and resetart the endpoint. Small adjustments in finding the new dequeue pointer are needed to support the case of stall on an empty ring and unknown current TD. Cc: <stable@vger.kernel.org> cc: Jeremy Compostella <jeremy.compostella@intel.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200421140822.28233-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 4月, 2020 1 次提交
-
-
由 Nishad Kamdar 提交于
This patch corrects the SPDX License Identifier style in header files related to USB host controller drivers. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used). Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46. Suggested-by: NJoe Perches <joe@perches.com> Signed-off-by: NNishad Kamdar <nishadkamdar@gmail.com> Link: https://lore.kernel.org/r/20200404092135.GA4522@nishadSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 3月, 2020 2 次提交
-
-
由 Kai-Heng Feng 提交于
Like U3 case, xHCI spec doesn't specify the upper bound of U0 transition time. The 20ms is not enough for some devices. Intead of polling PLS or PLC, we can facilitate the port change event to know that the link transits to U0 is completed. While at it, also separate U0 and U3 case to make the code cleaner. [variable rename to u3exit, and skip completion for usb2 ports -Mathias ] Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200312144517.1593-8-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mathias Nyman 提交于
Additional debugging to show xHC USBSTS register when stop endpoint command watchdog triggers and host is assumed dead. useful to know the current status before the controller is stopped by the xhci driver and everything is released and freed. Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200312144517.1593-4-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 24 2月, 2020 1 次提交
-
-
由 Gustavo A. R. Silva 提交于
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200220132017.GA29262@embeddedorSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 2月, 2020 2 次提交
-
-
由 Mathias Nyman 提交于
xhci driver assumed that xHC controllers have at most one custom supported speed table (PSI) for all usb 3.x ports. Memory was allocated for one PSI table under the xhci hub structure. Turns out this is not the case, some controllers have a separate "supported protocol capability" entry with a PSI table for each port. This means each usb3 roothub port can in theory support different custom speeds. To solve this, cache all supported protocol capabilities with their PSI tables in an array, and add pointers to the xhci port structure so that every port points to its capability entry in the array. When creating the SuperSpeedPlus USB Device Capability BOS descriptor for the xhci USB 3.1 roothub we for now will use only data from the first USB 3.1 capable protocol capability entry in the array. This could be improved later, this patch focuses resolving the memory leak. Reported-by: NPaul Menzel <pmenzel@molgen.mpg.de> Reported-by: NSajja Venkateswara Rao <VenkateswaraRao.Sajja@amd.com> Fixes: 47189098 ("xhci: parse xhci protocol speed ID list for usb 3.1 usage") Cc: stable <stable@vger.kernel.org> # v4.4+ Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20200211150158.14475-1-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
This reverts commit fc57313d. Marek reports that it breaks things: This patch landed in today's linux-next (20200211) and causes NULL pointer dereference during second suspend/resume cycle on Samsung Exynos5422-based (arm 32bit) Odroid XU3lite board: A more complete fix will be added soon. Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com> Fixes: fc57313d ("xhci: Fix memory leak when caching protocol extended capability PSI tables") Cc: Paul Menzel <pmenzel@molgen.mpg.de> Cc: Sajja Venkateswara Rao <VenkateswaraRao.Sajja@amd.com> Cc: stable <stable@vger.kernel.org> # v4.4+ Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 10 2月, 2020 1 次提交
-
-
由 Mathias Nyman 提交于
xhci driver assumed that xHC controllers have at most one custom supported speed table (PSI) for all usb 3.x ports. Memory was allocated for one PSI table under the xhci hub structure. Turns out this is not the case, some controllers have a separate "supported protocol capability" entry with a PSI table for each port. This means each usb3 roothub port can in theory support different custom speeds. To solve this, cache all supported protocol capabilities with their PSI tables in an array, and add pointers to the xhci port structure so that every port points to its capability entry in the array. When creating the SuperSpeedPlus USB Device Capability BOS descriptor for the xhci USB 3.1 roothub we for now will use only data from the first USB 3.1 capable protocol capability entry in the array. This could be improved later, this patch focuses resolving the memory leak. Reported-by: NPaul Menzel <pmenzel@molgen.mpg.de> Reported-by: NSajja Venkateswara Rao <VenkateswaraRao.Sajja@amd.com> Fixes: 47189098 ("xhci: parse xhci protocol speed ID list for usb 3.1 usage") Cc: stable <stable@vger.kernel.org> # v4.4+ Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200210134553.9144-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 11 12月, 2019 1 次提交
-
-
由 Henry Lin 提交于
Xhci driver cannot call pci_set_power_state() on non-pci xhci host controllers. For example, NVIDIA Tegra XHCI host controller which acts as platform device with XHCI_SPURIOUS_WAKEUP quirk set in some platform hits this issue during shutdown. Cc: <stable@vger.kernel.org> Fixes: 638298dc ("xhci: Fix spurious wakeups after S5 on Haswell") Signed-off-by: NHenry Lin <henryl@nvidia.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20191211142007.8847-4-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 11月, 2019 1 次提交
-
-
由 Mathias Nyman 提交于
Trace when a register in the doorbell array is written, both for host controller command doorbell and device doorbells, including for which endpoint and stream Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1573836603-10871-3-git-send-email-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 03 9月, 2019 1 次提交
-
-
由 Mathias Nyman 提交于
Software can set a Transfer State Preserve (TSP) flag to maintain data toggle and sequence number when issuing a reset endpoint command. xhci driver is using TSP for soft retry, we want to show TSP usage in tracing as well Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1567172356-12915-4-git-send-email-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 7月, 2019 1 次提交
-
-
由 Mathias Nyman 提交于
A second regression was found in the immediate data transfer (IDT) support which was added to 5.2 kernel IDT is used to transfer small amounts of data (up to 8 bytes) in the field normally used for data dma address, thus avoiding dma mapping. If the data was not already dma mapped, then IDT support assumed data was in urb->transfer_buffer, and did not take into accound that even small amounts of data (8 bytes) can be in a scatterlist instead. This caused a NULL pointer dereference when sg_dma_len() was used with non-dma mapped data. Solve this by not using IDT if scatter gather buffer list is used. Fixes: 33e39350 ("usb: xhci: add Immediate Data Transfer support") Cc: <stable@vger.kernel.org> # v5.2 Reported-by: NMaik Stohn <maik.stohn@seal-one.com> Tested-by: NMaik Stohn <maik.stohn@seal-one.com> CC: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/1564044861-1445-1-git-send-email-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 6月, 2019 1 次提交
-
-
由 Mathias Nyman 提交于
A USB3 device needs to be reset and re-enumarated if the port it connects to goes to a error state, with link state inactive. There is no use in trying to recover failed transactions by resetting endpoints at this stage. Tests show that in rare cases, after multiple endpoint resets of a roothub port the whole host controller might stop completely. Several retries to recover from transaction error can happen as it can take a long time before the hub thread discovers the USB3 port error and inactive link. We can't reliably detect the port error from slot or endpoint context due to a limitation in xhci, see xhci specs section 4.8.3: "There are several cases where the EP State field in the Output Endpoint Context may not reflect the current state of an endpoint" and "Software should maintain an accurate value for EP State, by tracking it with an internal variable that is driven by Events and Doorbell accesses" Same appears to be true for slot state. set a flag to the corresponding slot if a USB3 roothub port link goes inactive to prevent both queueing new URBs and resetting endpoints. Reported-by: NRapolu Chiranjeevi <chiranjeevi.rapolu@intel.com> Tested-by: NRapolu Chiranjeevi <chiranjeevi.rapolu@intel.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>
-
- 05 6月, 2019 1 次提交
-
-
由 Jim Lin 提交于
USB 2.0 specification chapter 11.17.5 says "as part of endpoint halt processing for full-/low-speed endpoints connected via a TT, the host software must use the Clear_TT_Buffer request to the TT to ensure that the buffer is not in the busy state". In our case, a full-speed speaker (ConferenceCam) is behind a high- speed hub (ConferenceCam Connect), sometimes once we get STALL on a request we may continue to get STALL with the folllowing requests, like Set_Interface. Here we invoke usb_hub_clear_tt_buffer() to send Clear_TT_Buffer request to the hub of the device for the following Set_Interface requests to the device to get ACK successfully. Signed-off-by: NJim Lin <jilin@nvidia.com> Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 5月, 2019 1 次提交
-
-
由 Mathias Nyman 提交于
xhci immediate data transfer (IDT) support in 5.2-rc1 caused regression on various Samsung Exynos boards with ASIX USB 2.0 ethernet dongle. If the transfer buffer in the URB is already DMA mapped then IDT should not be used. urb->transfer_dma will already contain a valid dma address, and there is no guarantee the data in urb->transfer_buffer is valid. The IDT support patch used urb->transfer_dma as a temporary storage, copying data from urb->transfer_buffer into it. Issue was solved by preventing IDT if transfer buffer is already dma mapped, and by not using urb->transfer_dma as temporary storage. Fixes: 33e39350 ("usb: xhci: add Immediate Data Transfer support") Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> CC: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-