summaryrefslogtreecommitdiffstats
path: root/drivers/usb
AgeCommit message (Collapse)AuthorFilesLines
2021-08-26usb: dwc3: gadget: Fix dwc3_calc_trbs_left()Thinh Nguyen1-8/+8
We can't depend on the TRB's HWO bit to determine if the TRB ring is "full". A TRB is only available when the driver had processed it, not when the controller consumed and relinquished the TRB's ownership to the driver. Otherwise, the driver may overwrite unprocessed TRBs. This can happen when many transfer events accumulate and the system is slow to process them and/or when there are too many small requests. If a request is in the started_list, that means there is one or more unprocessed TRBs remained. Check this instead of the TRB's HWO bit whether the TRB ring is full. Fixes: c4233573f6ee ("usb: dwc3: gadget: prepare TRBs on update transfers too") Cc: <stable@vger.kernel.org> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/e91e975affb0d0d02770686afc3a5b9eb84409f6.1629335416.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: mtu3: fix random remote wakeupChunfeng Yun2-1/+4
Some platforms, e.g. 8183/8192, use low level latch way to keep wakeup signal, it may latch a wrong signal if debounce more time, and enable wakeup earlier. ____________________ ip_sleep ____/ \__________ ___________________ wakeup_signal ____________/ \______ _______________________________ wakeup_en _______/ ^ ^ |(1) |(2) latch wakeup_signal mistakenly at (1), should latch it at (2); Workaround: delay about 100us to enable wakeup, meanwhile decrease debounce time. Fixes: b1a344589eea ("usb: mtu3: support ip-sleep wakeup for MT8183") Cc: stable@vger.kernel.org Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20210826083637.33237-2-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: mtu3: return successful suspend statusChunfeng Yun1-0/+1
Forgot 'return 0;' when suspend successfully, make the mistake when I split patches. Fixes: 6b587394c65c ("usb: mtu3: support suspend/resume for dual-role mode") Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20210826083637.33237-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: xhci-mtk: Do not use xhci's virt_dev in drop_endpointChunfeng Yun2-51/+60
xhci-mtk depends on xhci's internal virt_dev when it retrieves its internal data from usb_host_endpoint both in add_endpoint and drop_endpoint callbacks. But when setup packet was retired by transaction errors in xhci_setup_device() path, a virt_dev for the slot is newly created with real_port 0. This leads to xhci-mtks's NULL pointer dereference from drop_endpoint callback as xhci-mtk assumes that virt_dev's real_port is always started from one. The similar problems were addressed by [1] but that can't cover the failure cases from setup_device. This patch drops the usages of xhci's virt_dev in xhci-mtk's drop_endpoint callback by adopting hashtable for searching mtk's schedule entity from a given usb_host_endpoint pointer instead of searching a linked list. So mtk's drop_endpoint callback doesn't have to rely on virt_dev at all. [1] f351f4b63dac ("usb: xhci-mtk: fix oops when unbind driver") Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20210826025144.51992-5-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: xhci-mtk: modify the SOF/ITP interval for mt8195Chunfeng Yun1-0/+65
There are 4 USB controllers on MT8195, the controllers (IP1~IP3, exclude IP0) have a wrong default SOF/ITP interval which is calculated from the frame counter clock 24Mhz by default, but in fact, the frame counter clock is 48Mhz, so we should set the accurate interval according to 48Mhz for those controllers. Note: the first controller no need set it. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1629189389-18779-9-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: xhci-mtk: add a member of num_esitChunfeng Yun2-13/+9
Add a member num_esit to save the number of esit, then no need caculate it in some functions. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1629189389-18779-8-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: xhci-mtk: check boundary before check ttChunfeng Yun1-3/+4
check_sch_tt() will access fs_bus_bw[] array, check boundary firstly to avoid out-of-bounds issue. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1629189389-18779-7-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: xhci-mtk: update fs bus bandwidth by bw_budget_tableChunfeng Yun1-10/+7
Use @bw_budget_table[] to update fs bus bandwidth due to not all microframes consume @bw_cost_per_microframe, see setup_sch_info(). Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1629189389-18779-6-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: xhci-mtk: fix issue of out-of-bounds array accessChunfeng Yun1-4/+6
Bus bandwidth array access is based on esit, increase one will cause out-of-bounds issue; for example, when esit is XHCI_MTK_MAX_ESIT, will overstep boundary. Fixes: 7c986fbc16ae ("usb: xhci-mtk: get the microframe boundary for ESIT") Cc: <stable@vger.kernel.org> Reported-by: Stan Lu <stan.lu@mediatek.com> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1629189389-18779-5-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: xhci-mtk: support option to disable usb2 portsChunfeng Yun2-2/+11
Add support to disable specific usb2 host ports, it's useful when a usb2 port is disabled on some platforms, but enabled on others for the same SoC. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1629189389-18779-4-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: xhci-mtk: fix use-after-free of mtk->hcdChunfeng Yun1-1/+1
BUG: KASAN: use-after-free in usb_hcd_is_primary_hcd+0x38/0x60 Call trace: dump_backtrace+0x0/0x3dc show_stack+0x20/0x2c dump_stack+0x15c/0x1d4 print_address_description+0x7c/0x510 kasan_report+0x164/0x1ac __asan_report_load8_noabort+0x44/0x50 usb_hcd_is_primary_hcd+0x38/0x60 xhci_mtk_runtime_suspend+0x68/0x148 pm_generic_runtime_suspend+0x90/0xac __rpm_callback+0xb8/0x1f4 rpm_callback+0x54/0x1d0 rpm_suspend+0x4e0/0xc84 __pm_runtime_suspend+0xc4/0x114 xhci_mtk_probe+0xa58/0xd00 This may happen when probe fails, needn't suspend it synchronously, fix it by using pm_runtime_put_noidle(). Reported-by: Pi Hsun <pihsun@google.com> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1629189389-18779-3-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: bdc: Fix a resource leak in the error handling path of 'bdc_probe()'Christophe JAILLET1-14/+13
If an error occurs after a successful 'clk_prepare_enable()' call, it must be undone by a corresponding 'clk_disable_unprepare()' call. This call is already present in the remove function. Add this call in the error handling path and reorder the code so that the 'clk_prepare_enable()' call happens later in the function. The goal is to have as much managed resources functions as possible before the 'clk_prepare_enable()' call in order to keep the error handling path simple. While at it, remove the now unneeded 'clk' variable. Fixes: c87dca047849 ("usb: bdc: Add clock enable for new chips with a separate BDC clock") Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/f8a4a6897deb0c8cb2e576580790303550f15fcd.1629314734.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: bdc: Fix an error handling path in 'bdc_probe()' when no suitable DMA ↵Christophe JAILLET1-1/+2
config is available If no suitable DMA configuration is available, a previous 'bdc_phy_init()' call must be undone by a corresponding 'bdc_phy_exit()' call. Branch to the existing error handling path instead of returning directly. Fixes: cc29d4f67757 ("usb: bdc: Add support for USB phy") Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/0c5910979f39225d5d8fe68c9ab1c147c68ddee1.1629314734.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26Revert "usb: xhci-mtk: Do not use xhci's virt_dev in drop_endpoint"Chunfeng Yun2-86/+69
I find the patch introduce some issues, e.g. 1. oops happens when xhci_gen_setup() failed, and hash is not init but try to destroy it; 2. memory leakage happens when fail to insert ep, need free sch_ep, or insert ep after insert int list; 3. memory leakage happens when fail to allocate sch_array, need destroy rhashtable; 4. it's better to check ep->hcpriv when drop ep; so prefer to revert this patch, and resend it after the issues are fixed. This reverts commit b8731209958a1dffccc2888121f4c0280c990550. Cc: Ikjoon Jang <ikjn@chromium.org> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20210820065913.64490-2-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26Revert "usb: xhci-mtk: relax TT periodic bandwidth allocation"Chunfeng Yun1-13/+7
As discussed in following patch: https://patchwork.kernel.org/patch/12420339 No need calculate number of uframes again, but should use value form check_sch_tt(), if we plan to remove extra CS, also can do it in check_sch_tt(). So revert this patch, and prepare to send new patch for it. This reverts commit 548011957d1d72e0b662300c8b32b81d593b796e. Cc: Ikjoon Jang <ikjn@chromium.org> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/20210820065913.64490-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: isp1760: clean never read udc_enabled warningRui Miguel Silva1-2/+2
When CONFIG_USB_ISP1761_UDC is not enabled the udc_enabled variable is never used since it is short circuited before in the logic operations. This would trigger the following warning by clang analyzer: drivers/usb/isp1760/isp1760-core.c:490:2: warning: Value stored to 'udc_enabled' is never read [clang-analyzer-deadcode.DeadStores] udc_enabled = ((devflags & ISP1760_FLAG_ISP1763) || ^ drivers/usb/isp1760/isp1760-core.c:490:2: note: Value stored to 'udc_enabled' is never read Just swap the other of the operands in the logic operations. Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> Link: https://lore.kernel.org/r/20210819180929.1327349-6-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: isp1760: do not shift in uninitialized slotRui Miguel Silva1-7/+11
Even though it is not expected, and would trigger a WARN_ON, killing a transfer in a uninitialized slot this sequence is warned by clang analyzer, twice: drivers/usb/isp1760/isp1760-hcd.c:1976:18: warning: The result of the left shift is undefined because the right operand is negative [clang-analyzer-core.UndefinedBinaryOperatorResult] skip_map |= (1 << qh->slot); drivers/usb/isp1760/isp1760-hcd.c:1983:18: warning: The result of the left shift is undefined because the right operand is negative [clang-analyzer-core.UndefinedBinaryOperatorResult] skip_map |= (1 << qh->slot); Only set skip map if slot is active. Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> Link: https://lore.kernel.org/r/20210819180929.1327349-5-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: isp1760: do not reset retvalRui Miguel Silva1-1/+0
We do not really need to reset retval before get used bellow. This will avoid the clang-analyzer warning: drivers/usb/isp1760/isp1760-hcd.c:1919:2: warning: Value stored to 'retval' is never read [clang-analyzer-deadcode.DeadStores] retval = 0; Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> Link: https://lore.kernel.org/r/20210819180929.1327349-4-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: isp1760: check maxpacketsize before using itRui Miguel Silva1-1/+1
When checking if we need one more packet on a bulk pipe we may, even though not probable at all, get there with a zero maxpacketsize. In that case for sure no packet, no even a one more, will be allocated. This will clean the clang-analyzer warning: drivers/usb/isp1760/isp1760-hcd.c:1856:38: warning: Division by zero [clang-analyzer-core.DivideZero] && !(urb->transfer_buffer_length % Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> Link: https://lore.kernel.org/r/20210819180929.1327349-3-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: isp1760: ignore return value for bus change patternRui Miguel Silva1-3/+7
We do not care about the return value of that read between the scratch register write and read, we really just want to make sure that the pattern in the bus get changed to make sure we are testing correctly the scratch pattern. Clang-analyzer complains about the never read scratch variable: >> drivers/usb/isp1760/isp1760-hcd.c:735:2: warning: Value stored to 'scratch' is never read [clang-analyzer-deadcode.DeadStores] scratch = isp1760_hcd_read(hcd, HC_CHIP_ID_HIGH); Just ignore the return value of that CHIP_ID_HIGH read, add more information to the comment above why we are doing this. And as at it, just do a small format change in the error message bellow. Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org> Link: https://lore.kernel.org/r/20210819180929.1327349-2-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: gadget: Add description for module parameterWei Ming Chen1-0/+1
The description for "qlen" is missing, and there is a description for this parameter in "Documentation/usb/gadget_printer.rst" Signed-off-by: Wei Ming Chen <jj251510319013@gmail.com> Link: https://lore.kernel.org/r/20210821142647.2904-1-jj251510319013@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usbip:vhci_hcd USB port can get stuck in the disabled stateShuah Khan1-1/+7
When a remote usb device is attached to the local Virtual USB Host Controller Root Hub port, the bound device driver may send a port reset command. vhci_hcd accepts port resets only when the device doesn't have port address assigned to it. When reset happens device is in assigned/used state and vhci_hcd rejects it leaving the port in a stuck state. This problem was found when a blue-tooth or xbox wireless dongle was passed through using usbip. A few drivers reset the port during probe including mt76 driver specific to this bug report. Fix the problem with a change to honor reset requests when device is in used state (VDEV_ST_USED). Reported-and-tested-by: Michael <msbroadf@gmail.com> Suggested-by: Michael <msbroadf@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20210819225937.41037-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usbip: clean up code in vhci_device_unlink_cleanupAnirudh Rayabharam1-40/+12
The cleanup code for unlink_tx and unlink_rx lists is almost the same. So, extract it into a new function and call it for both unlink_rx and unlink_tx. Also, remove unnecessary log messages. Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com> Link: https://lore.kernel.org/r/20210820190122.16379-3-mail@anirudhrb.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usbip: give back URBs for unsent unlink requests during cleanupAnirudh Rayabharam1-0/+24
In vhci_device_unlink_cleanup(), the URBs for unsent unlink requests are not given back. This sometimes causes usb_kill_urb to wait indefinitely for that urb to be given back. syzbot has reported a hung task issue [1] for this. To fix this, give back the urbs corresponding to unsent unlink requests (unlink_tx list) similar to how urbs corresponding to unanswered unlink requests (unlink_rx list) are given back. [1]: https://syzkaller.appspot.com/bug?id=08f12df95ae7da69814e64eb5515d5a85ed06b76 Reported-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com Tested-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com> Link: https://lore.kernel.org/r/20210820190122.16379-2-mail@anirudhrb.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: gadget: aspeed: Remove repeated verbose license textCai Huoqing5-25/+0
remove it because SPDX-License-Identifier is already used Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210823045807.49-1-caihuoqing@baidu.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: gadget: mass_storage: Remove repeated verbose license textCai Huoqing1-30/+0
remove it because SPDX-License-Identifier is already used Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Link: https://lore.kernel.org/r/20210822043005.192-1-caihuoqing@baidu.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: musb: musb_dsps: request_irq() after initializing musbNadezda Lutovinova1-7/+6
If IRQ occurs between calling dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev(), then null pointer dereference occurs since glue->musb wasn't initialized yet. The patch puts initializing of neccesery data before registration of the interrupt handler. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210819163323.17714-1-lutovinova@ispras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: dwc3: pci: add support for AMD's newer generation platform.Nehal Bakulchandra Shah1-0/+17
AMD's latest platforms has DWC3 controller. Add the PCI ID and properties for the same. Signed-off-by: Nehal Bakulchandra Shah <Nehal-Bakulchandra.shah@amd.com> Acked-by: Felipe Balbi <balbi@kernel.org> Link: https://lore.kernel.org/r/20210823184449.2796184-2-Nehal-Bakulchandra.shah@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: dwc3: imx8mp: request irq after initializing dwc3Nadezda Lutovinova1-7/+7
If IRQ occurs between calling devm_request_threaded_irq() and initializing dwc3_imx->dwc3, then null pointer dereference occurs since dwc3_imx->dwc3 is used in dwc3_imx8mp_interrupt(). The patch puts registration of the interrupt handler after initializing of neccesery data. Found by Linux Driver Verification project (linuxtesting.org). Reviewed-by: Fabio Estevam <festevam@gmail.com> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210819154818.18334-1-lutovinova@ispras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26usb: ehci-orion: Handle errors of clk_prepare_enable() in probeEvgeny Novikov1-2/+6
ehci_orion_drv_probe() did not account for possible errors of clk_prepare_enable() that in particular could cause invocation of clk_disable_unprepare() on clocks that were not prepared/enabled yet, e.g. in remove or on handling errors of usb_add_hcd() in probe. Though, there were several patches fixing different issues with clocks in this driver, they did not solve this problem. Add handling of errors of clk_prepare_enable() in ehci_orion_drv_probe() to avoid calls of clk_disable_unprepare() without previous successful invocation of clk_prepare_enable(). Found by Linux Driver Verification project (linuxtesting.org). Fixes: 8c869edaee07 ("ARM: Orion: EHCI: Add support for enabling clocks") Co-developed-by: Kirill Shilimanov <kirill.shilimanov@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Evgeny Novikov <novikov@ispras.ru> Signed-off-by: Kirill Shilimanov <kirill.shilimanov@huawei.com> Link: https://lore.kernel.org/r/20210825170902.11234-1-novikov@ispras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26xhci: Add bus number to some debug messagesMathias Nyman3-5/+10
As we register two usb buses for each xHC, and systems with several hosts are more and more common it is getting hard to follow the flow of debug messages without knowing which bus they belong to Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-7-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26xhci: Add additional dynamic debug to follow URBs in cancel and error cases.Mathias Nyman1-6/+24
Add more debugging messages to follow what happends to a URB internally in special cases like URB cancel, halted endpoints and endpoint reset. Helps tracking issues like URB never given back by host. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26Revert "USB: xhci: fix U1/U2 handling for hardware with XHCI_INTEL_HOST ↵Mathias Nyman1-12/+12
quirk set" 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 <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26xhci: Fix failure to give back some cached cancelled URBs.Mathias Nyman1-15/+25
Only TDs with status TD_CLEARING_CACHE will be given back after cache is cleared with a set TR deq command. xhci_invalidate_cached_td() failed to set the TD_CLEARING_CACHE status for some cancelled TDs as it assumed an endpoint only needs to clear the TD it stopped on. This isn't always true. For example with streams enabled an endpoint may have several stream rings, each stopping on a different TDs. Note that if an endpoint has several stream rings, the current code will still only clear the cache of the stream pointed to by the last cancelled TD in the cancel list. This patch only focus on making sure all canceled TDs are given back, avoiding hung task after device removal. Another fix to solve clearing the caches of all stream rings with cancelled TDs is needed, but not as urgent. This issue was simultanously discovered and debugged by by Tao Wang, with a slightly different fix proposal. Fixes: 674f8438c121 ("xhci: split handling halted endpoints into two steps") Cc: <stable@vger.kernel.org> #5.12 Reported-by: Tao Wang <wat@codeaurora.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26xhci: fix even more unsafe memory usage in xhci tracingMathias Nyman4-23/+27
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: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26xhci: fix unsafe memory usage in xhci tracingMathias Nyman3-30/+36
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: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210820123503.2605901-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-26USB: serial: replace symbolic permissions by octal permissionsUtkarsh Verma7-15/+15
Replace symbolic permission macros with octal permission numbers because octal permission numbers are easier to read and understand instead of their symbolic macro names. No functional change. Suggested-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Utkarsh Verma <utkarshverma294@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2021-08-25Revert "USB: serial: ch341: fix character loss at high transfer rates"Johan Hovold1-1/+0
This reverts commit 3c18e9baee0ef97510dcda78c82285f52626764b. These devices do not appear to send a zero-length packet when the transfer size is a multiple of the bulk-endpoint max-packet size. This means that incoming data may not be processed by the driver until a short packet is received or the receive buffer is full. Revert back to using endpoint-sized receive buffers to avoid stalled reads. Reported-by: Paul Größel <pb.g@gmx.de> Link: https://bugzilla.kernel.org/show_bug.cgi?id=214131 Fixes: 3c18e9baee0e ("USB: serial: ch341: fix character loss at high transfer rates") Cc: stable@vger.kernel.org Cc: Willy Tarreau <w@1wt.eu> Link: https://lore.kernel.org/r/20210824121926.19311-1-johan@kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2021-08-24USB: serial: option: add new VID/PID to support Fibocom FG150Zhengjun Zhang1-0/+2
Fibocom FG150 is a 5G module based on Qualcomm SDX55 platform, support Sub-6G band. Here are the outputs of lsusb -v and usb-devices: > T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0 > D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 > P: Vendor=2cb7 ProdID=010b Rev=04.14 > S: Manufacturer=Fibocom > S: Product=Fibocom Modem_SN:XXXXXXXX > S: SerialNumber=XXXXXXXX > C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA > I: If#=0x0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host > I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host > I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) > I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) > I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) > Bus 002 Device 002: ID 2cb7:010b Fibocom Fibocom Modem_SN:XXXXXXXX > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 3.20 > bDeviceClass 0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 9 > idVendor 0x2cb7 Fibocom > idProduct 0x010b > bcdDevice 4.14 > iManufacturer 1 Fibocom > iProduct 2 Fibocom Modem_SN:XXXXXXXX > iSerial 3 XXXXXXXX > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 0x00e6 > bNumInterfaces 5 > bConfigurationValue 1 > iConfiguration 4 RNDIS_DUN_DIAG_ADB > bmAttributes 0xa0 > (Bus Powered) > Remote Wakeup > MaxPower 896mA > Interface Association: > bLength 8 > bDescriptorType 11 > bFirstInterface 0 > bInterfaceCount 2 > bFunctionClass 239 Miscellaneous Device > bFunctionSubClass 4 > bFunctionProtocol 1 > iFunction 7 RNDIS > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 239 Miscellaneous Device > bInterfaceSubClass 4 > bInterfaceProtocol 1 > iInterface 0 > ** UNRECOGNIZED: 05 24 00 10 01 > ** UNRECOGNIZED: 05 24 01 00 01 > ** UNRECOGNIZED: 04 24 02 00 > ** UNRECOGNIZED: 05 24 06 00 01 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 9 > bMaxBurst 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 1 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 10 CDC Data > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x8e EP 14 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 6 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x0f EP 15 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 6 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 2 > bAlternateSetting 0 > bNumEndpoints 3 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > ** UNRECOGNIZED: 05 24 00 10 01 > ** UNRECOGNIZED: 05 24 01 00 00 > ** UNRECOGNIZED: 04 24 02 02 > ** UNRECOGNIZED: 05 24 06 00 00 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x83 EP 3 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x000a 1x 10 bytes > bInterval 9 > bMaxBurst 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x01 EP 1 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 3 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 255 Vendor Specific Subclass > bInterfaceProtocol 48 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x84 EP 4 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 4 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 66 > bInterfaceProtocol 1 > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x03 EP 3 OUT > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x85 EP 5 IN > bmAttributes 2 > Transfer Type Bulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0400 1x 1024 bytes > bInterval 0 > bMaxBurst 0 > Binary Object Store Descriptor: > bLength 5 > bDescriptorType 15 > wTotalLength 0x0016 > bNumDeviceCaps 2 > USB 2.0 Extension Device Capability: > bLength 7 > bDescriptorType 16 > bDevCapabilityType 2 > bmAttributes 0x00000006 > BESL Link Power Management (LPM) Supported > SuperSpeed USB Device Capability: > bLength 10 > bDescriptorType 16 > bDevCapabilityType 3 > bmAttributes 0x00 > wSpeedsSupported 0x000f > Device can operate at Low Speed (1Mbps) > Device can operate at Full Speed (12Mbps) > Device can operate at High Speed (480Mbps) > Device can operate at SuperSpeed (5Gbps) > bFunctionalitySupport 1 > Lowest fully-functional device speed is Full Speed (12Mbps) > bU1DevExitLat 1 micro seconds > bU2DevExitLat 500 micro seconds > Device Status: 0x0000 > (Bus Powered) Signed-off-by: Zhengjun Zhang <zhangzhengjun@aicrobo.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2021-08-24usb: gadget: f_hid: optional SETUP/SET_REPORT modeMaxim Devaev2-33/+188
f_hid provides the OUT Endpoint as only way for receiving reports from the host. SETUP/SET_REPORT method is not supported, and this causes a number of compatibility problems with various host drivers, especially in the case of keyboard emulation using f_hid. - Some hosts do not support the OUT Endpoint and ignore it, so it becomes impossible for the gadget to receive a report from the host. In the case of a keyboard, the gadget loses the ability to receive the status of the LEDs. - Some BIOSes/UEFIs can't work with HID devices with the OUT Endpoint at all. This may be due to their bugs or incomplete implementation of the HID standard. For example, absolutely all Apple UEFIs can't handle the OUT Endpoint if it goes after IN Endpoint in the descriptor and require the reverse order (OUT, IN) which is a violation of the standard. Other hosts either do not initialize gadgets with a descriptor containing the OUT Endpoint completely (like some HP and DELL BIOSes and embedded firmwares like on KVM switches), or initialize them, but will not poll the IN Endpoint. This patch adds configfs option no_out_endpoint=1 to disable the OUT Endpoint and allows f_hid to receive reports from the host via SETUP/SET_REPORT. Previously, there was such a feature in f_hid, but it was replaced by the OUT Endpoint [1] in the commit 99c515005857 ("usb: gadget: hidg: register OUT INT endpoint for SET_REPORT"). So this patch actually returns the removed functionality while making it optional. For backward compatibility reasons, the OUT Endpoint mode remains the default behaviour. - The OUT Endpoint mode provides the report queue and reduces USB overhead (eliminating SETUP routine) on transmitting a report from the host. - If the SETUP/SET_REPORT mode is used, there is no report queue, so the userspace will only read last report. For classic HID devices like keyboards this is not a problem, since it's intended to transmit the status of the LEDs and only the last report is important. This mode provides better compatibility with strange and buggy host drivers. Both modes passed USBCV tests. Checking with the USB protocol analyzer also confirmed that everything is working as it should and the new mode ensures operability in all of the described cases. Link: https://www.spinics.net/lists/linux-usb/msg65494.html [1] Reviewed-by: Maciej Żenczykowski <zenczykowski@gmail.com> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Maxim Devaev <mdevaev@gmail.com> Link: https://lore.kernel.org/r/20210821134004.363217-1-mdevaev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-24Merge 5.14-rc7 into usb-nextGreg Kroah-Hartman1-6/+7
We need the USB fix in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-21usb: chipidea: host: fix port index underflow and UBSAN complainsLi Jun1-3/+11
If wIndex is 0 (and it often is), these calculations underflow and UBSAN complains, here resolve this by not decrementing the index when it is equal to 0, this copies the solution from commit 85e3990bea49 ("USB: EHCI: avoid undefined pointer arithmetic and placate UBSAN") Reported-by: Zhipeng Wang <zhipeng.wang_1@nxp.com> Signed-off-by: Li Jun <jun.li@nxp.com> Link: https://lore.kernel.org/r/1624004938-2399-1-git-send-email-jun.li@nxp.com Signed-off-by: Peter Chen <peter.chen@kernel.org>
2021-08-18USB: EHCI: Add alias for Broadcom INSNREGKees Cook1-7/+4
Refactor struct ehci_regs to avoid accessing beyond the end of port_status. This change results in no difference in the final object code. Avoids several warnings when building with -Warray-bounds: drivers/usb/host/ehci-brcm.c: In function 'ehci_brcm_reset': drivers/usb/host/ehci-brcm.c:113:32: warning: array subscript 16 is above array bounds of 'u32[15]' {aka 'unsigned int[15]'} [-Warray-bounds] 113 | ehci_writel(ehci, 0x00800040, &ehci->regs->port_status[0x10]); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from drivers/usb/host/ehci.h:274, from drivers/usb/host/ehci-brcm.c:15: ./include/linux/usb/ehci_def.h:132:7: note: while referencing 'port_status' 132 | u32 port_status[HCS_N_PORTS_MAX]; | ^~~~~~~~~~~ Note that the documentation around this proprietary register was confusing. If "USB_EHCI_INSNREG00" is at port_status[0x0f], its offset would be 0x80 (not 0x90). The comments have been adjusted to fix this apparent typo. Fixes: 9df231511bd6 ("usb: ehci: Add new EHCI driver for Broadcom STB SoC's") Cc: Al Cooper <alcooperx@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Cc: bcm-kernel-feedback-list@broadcom.com Suggested-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210818173018.2259231-3-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18usb: gadget: mv_u3d: request_irq() after initializing UDCNadezda Lutovinova1-9/+10
If IRQ occurs between calling request_irq() and mv_u3d_eps_init(), then null pointer dereference occurs since u3d->eps[] wasn't initialized yet but used in mv_u3d_nuke(). The patch puts registration of the interrupt handler after initializing of neccesery data. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers") Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru> Link: https://lore.kernel.org/r/20210818141247.4794-1-lutovinova@ispras.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18usb: typec: tcpm: Fix VDMs sometimes not being forwarded to alt-mode driversHans de Goede1-6/+7
Commit a20dcf53ea98 ("usb: typec: tcpm: Respond Not_Supported if no snk_vdo"), stops tcpm_pd_data_request() calling tcpm_handle_vdm_request() when port->nr_snk_vdo is not set. But the VDM might be intended for an altmode-driver, in which case nr_snk_vdo does not matter. This change breaks the forwarding of connector hotplug (HPD) events for displayport altmode on devices which don't set nr_snk_vdo. tcpm_pd_data_request() is the only caller of tcpm_handle_vdm_request(), so we can move the nr_snk_vdo check to inside it, at which point we have already looked up the altmode device so we can check for this too. Doing this check here also ensures that vdm_state gets set to VDM_STATE_DONE if it was VDM_STATE_BUSY, even if we end up with responding with PD_MSG_CTRL_NOT_SUPP later. Note that tcpm_handle_vdm_request() was already sending PD_MSG_CTRL_NOT_SUPP in some circumstances, after moving the nr_snk_vdo check the same error-path is now taken when that check fails. So that we have only one error-path for this and not two. Replace the tcpm_queue_message(PD_MSG_CTRL_NOT_SUPP) used by the existing error-path with the more robust tcpm_pd_handle_msg() from the (now removed) second error-path. Fixes: a20dcf53ea98 ("usb: typec: tcpm: Respond Not_Supported if no snk_vdo") Cc: stable <stable@vger.kernel.org> Cc: Kyle Tso <kyletso@google.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Kyle Tso <kyletso@google.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210816154632.381968-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18usb: gadget: f_uac1: fixing inconsistent indentingPavel Hofman1-6/+6
Fixing inconsistent indenting identified by kernel test robot. Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com> Acked-By: Felipe Balbi <balbi@kernel.org> Link: https://lore.kernel.org/r/20210817100555.4437-1-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18usb: remove reference to deleted config STB03xxxLukas Bulwahn1-1/+1
Commit 7583b63c343c ("powerpc/40x: Remove STB03xxx") removes the config STB03xxx, but left a reference in ./drivers/usb/Kconfig behind. Hence, ./scripts/checkkconfigsymbols.py warns: STB03xxx Referencing files: drivers/usb/Kconfig Remove this reference to the deleted config. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20210818071137.22711-4-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18usb: host: remove line for obsolete config USB_HWA_HCDLukas Bulwahn1-1/+0
Commit 71ed79b0e4be ("USB: Move wusbcore and UWB to staging as it is obsolete") misses to adjust some part in ./drivers/usb/host/Makefile. Hence, ./scripts/checkkconfigsymbols.py warns: USB_HWA_HCD Referencing files: drivers/usb/Makefile Remove the missing piece of this code removal. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20210818071137.22711-3-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18usb: host: remove dead EHCI support for on-chip PMC MSP71xx USB controllerLukas Bulwahn3-342/+0
Commit 1b00767fd8e1 ("MIPS: Remove PMC MSP71xx platform") deletes ./arch/mips/pmcs-msp71xx/Kconfig, including its config MSP_HAS_USB. Hence, since then, the corresponding EHCI support for on-chip PMC MSP71xx USB controller is dead code. Remove this dead driver. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20210818071137.22711-2-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18usb: dwc3: Decouple USB 2.0 L1 & L2 eventsJack Pham2-2/+12
On DWC_usb3 revisions 3.00a and newer (including DWC_usb31 and DWC_usb32) the GUCTL1 register gained the DEV_DECOUPLE_L1L2_EVT field (bit 31) which when enabled allows the controller in device mode to treat USB 2.0 L1 LPM & L2 events separately. After commit d1d90dd27254 ("usb: dwc3: gadget: Enable suspend events") the controller will now receive events (and therefore interrupts) for every state change when entering/exiting either L1 or L2 states. Since L1 is handled entirely by the hardware and requires no software intervention, there is no need to even enable these events and unnecessarily notify the gadget driver. Enable the aforementioned bit to help reduce the overall interrupt count for these L1 events that don't need to be handled while retaining the events for full L2 suspend/wakeup. Tested-by: Jun Li <jun.li@nxp.com> Tested-by: Amit Pundir <amit.pundir@linaro.org> # for RB5 (sm8250) Tested-by: John Stultz <john.stultz@linaro.org> # for HiKey960 & db845c Reviewed-by: Jun Li <jun.li@nxp.com> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210812082635.12924-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-14 08:21:34 +0000