kernel/linux.git/drivers/usb/dwc3, branch linux-4.20.y

usb: dwc3: exynos: Fix error handling of clk_prepare_enable

2019-03-13T21:04:12+00:00

[ Upstream commit 512e6fb589bc18f9321457632e89b95017447db9 ] If clk_prepare_enable() fails in dwc3_exynos_probe() or in dwc3_exynos_resume(), exynos->clks[0] is left undisabled because of usage preincrement in while condition. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 9f2168367a0a ("usb: dwc3: exynos: Rework clock handling and prepare for new variants") Acked-by: Marek Szyprowski Signed-off-by: Alexey Khoroshilov Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin

usb: dwc3: gadget: Fix the uninitialized link_state when udc starts

2019-03-05T16:59:36+00:00

[ Upstream commit 88b1bb1f3b88e0bf20b05d543a53a5b99bd7ceb6 ] Currently the link_state is uninitialized and the default value is 0(U0) before the first time we start the udc, and after we start the udc then stop the udc, the link_state will be undefined. We may have the following warnings if we start the udc again with an undefined link_state: WARNING: CPU: 0 PID: 327 at drivers/usb/dwc3/gadget.c:294 dwc3_send_gadget_ep_cmd+0x304/0x308 dwc3 100e0000.hidwc3_0: wakeup failed --> -22 [...] Call Trace: [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x84/0x98) [] (dump_stack) from [] (__warn+0xe8/0x100) [] (__warn) from [](warn_slowpath_fmt+0x38/0x48) [] (warn_slowpath_fmt) from [](dwc3_send_gadget_ep_cmd+0x304/0x308) [] (dwc3_send_gadget_ep_cmd) from [](dwc3_ep0_start_trans+0x48/0xf4) [] (dwc3_ep0_start_trans) from [](dwc3_ep0_out_start+0x64/0x80) [] (dwc3_ep0_out_start) from [](__dwc3_gadget_start+0x1e0/0x278) [] (__dwc3_gadget_start) from [](dwc3_gadget_start+0x88/0x10c) [] (dwc3_gadget_start) from [](udc_bind_to_driver+0x88/0xbc) [] (udc_bind_to_driver) from [](usb_gadget_probe_driver+0xf8/0x140) [] (usb_gadget_probe_driver) from [](gadget_dev_desc_UDC_store+0xac/0xc4 [libcomposite]) [] (gadget_dev_desc_UDC_store [libcomposite]) from[] (configfs_write_file+0xd4/0x160) [] (configfs_write_file) from [] (__vfs_write+0x1c/0x114) [] (__vfs_write) from [] (vfs_write+0xa4/0x168) [] (vfs_write) from [] (SyS_write+0x3c/0x90) [] (SyS_write) from [] (ret_fast_syscall+0x0/0x3c) Signed-off-by: Zeng Tao Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin

usb: dwc3: gadget: synchronize_irq dwc irq in suspend

2019-03-05T16:59:36+00:00

[ Upstream commit 01c10880d24291a96a4ab0da773e3c5ce4d12da8 ] We see dwc3 endpoint stopped by unwanted irq during suspend resume test, which is caused dwc3 ep can't be started with error "No Resource". Here, add synchronize_irq before suspend to sync the pending IRQ handlers complete. Signed-off-by: Bo He Signed-off-by: Yu Wang Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin

usb: dwc3: gadget: Handle 0 xfer length for OUT EP

2019-02-12T19:02:36+00:00

commit 1e19cdc8060227b0802bda6bc0bd22b23679ba32 upstream. For OUT endpoints, zero-length transfers require MaxPacketSize buffer as per the DWC_usb3 programming guide 3.30a section 4.2.3.3. This patch fixes this by explicitly checking zero length transfer to correctly pad up to MaxPacketSize. Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: stable@vger.kernel.org Signed-off-by: Tejas Joglekar Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

usb: dwc3: gadget: Disable CSP for stream OUT ep

2019-02-12T19:02:17+00:00

[ Upstream commit 244add8ebfb231c39db9e33b204bd0ce8f24f782 ] In stream mode, when fast-forwarding TRBs, the stream number is not cleared causing the new stream to not get assigned. So we don't want controller to carry on transfers when short packet is received. So disable the CSP for stream capable endpoint. This is based on the 3.30a Programming guide, where table 3-1 device descriptor structure field definitions says for CSP bit If this bit is 0, the controller generates an XferComplete event and remove the stream. So if we keep CSP as 1 then switching between streams would not happen as in stream mode, when fast-forwarding TRBs, the stream number is not cleared causing the new stream to not get assigned. Signed-off-by: Tejas Joglekar Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin

usb: dwc3: trace: add missing break statement to make compiler happy

2019-02-12T19:02:15+00:00

[ Upstream commit 54d48183d21e03f780053d7129312049cb5dd591 ] The missed break statement in the outer switch makes the code fall through always and thus always same value will be printed. Besides that, compiler warns about missed fall through marker: drivers/usb/dwc3/./trace.h: In function ‘trace_raw_output_dwc3_log_trb’: drivers/usb/dwc3/./trace.h:246:4: warning: this statement may fall through [-Wimplicit-fallthrough=] switch (pcm) { ^~~~~~ Add the missing break statement to work correctly without compilation warnings. Fixes: fa8d965d736b ("usb: dwc3: trace: pretty print high-bandwidth transfers too") Cc: Felipe Balbi Signed-off-by: Andy Shevchenko Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin

usb: dwc3: Correct the logic for checking TRB full in __dwc3_prepare_one_trb()

2019-02-12T19:02:14+00:00

[ Upstream commit b7a4fbe2300a8965ea760c7e871507b84aea17f6 ] Availability of TRB's is calculated using dwc3_calc_trbs_left(), which determines total available TRB's based on the HWO bit set in a TRB. In the present code, __dwc3_prepare_one_trb() is called with a TRB which needs to be prepared for transfer. This __dwc3_prepare_one_trb() calls dwc3_calc_trbs_left() to determine total available TRBs and set IOC bit if the total available TRBs are zero. Since the present working TRB (which is passed as an argument to __dwc3_prepare_one_trb() ) doesn't yet have the HWO bit set before calling dwc3_calc_trbs_left(), there are chances that dwc3_calc_trbs_left() wrongly calculates this present working TRB as free(since the HWO bit is not yet set) and returns the total available TRBs as greater than zero (including the present working TRB). This could be a problem. This patch corrects the above mentioned problem in __dwc3_prepare_one_trb() by increementing the dep->trb_enqueue at the last (after preparing the TRB) instead of increementing at the start and setting the IOC bit only if the total available TRBs returned by dwc3_calc_trbs_left() is 1 . Since we are increementing the dep->trb_enqueue at the last, the present working TRB is also considered as available by dwc3_calc_trbs_left() and non zero value is returned . So, according to the modified logic, when the total available TRBs is equal to 1 that means the total available TRBs in the pool are 0. Signed-off-by: Anurag Kumar Vulisha Reviewed-by: Thinh Nguyen Tested-by: Tejas Joglekar Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin

usb: dwc3: gadget: Clear req->needs_extra_trb flag on cleanup

2019-01-31T07:15:45+00:00

commit bd6742249b9ca918565e4e3abaa06665e587f4b5 upstream. OUT endpoint requests may somtimes have this flag set when preparing to be submitted to HW indicating that there is an additional TRB chained to the request for alignment purposes. If that request is removed before the controller can execute the transfer (e.g. ep_dequeue/ep_disable), the request will not go through the dwc3_gadget_ep_cleanup_completed_request() handler and will not have its needs_extra_trb flag cleared when dwc3_gadget_giveback() is called. This same request could be later requeued for a new transfer that does not require an extra TRB and if it is successfully completed, the cleanup and TRB reclamation will incorrectly process the additional TRB which belongs to the next request, and incorrectly advances the TRB dequeue pointer, thereby messing up calculation of the next requeust's actual/remaining count when it completes. The right thing to do here is to ensure that the flag is cleared before it is given back to the function driver. A good place to do that is in dwc3_gadget_del_and_unmap_request(). Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize") Cc: stable@vger.kernel.org Signed-off-by: Jack Pham Signed-off-by: Felipe Balbi [jackp: backport to <= 4.20: replaced 'needs_extra_trb' with 'unaligned' and 'zero' members in patch and reworded commit text] Signed-off-by: Jack Pham Signed-off-by: Greg Kroah-Hartman

Revert "usb: dwc3: pci: Use devm functions to get the phy GPIOs"

2019-01-09T16:45:53+00:00

commit 3004cfd6204927c1294060b849029cf0c2651074 upstream. Commit 211f658b7b40 ("usb: dwc3: pci: Use devm functions to get the phy GPIOs") changed the code to claim the PHY GPIOs permanently for Intel Baytrail devices. This causes issues when the actual PHY driver attempts to claim the same GPIO descriptors. For example, tusb1210 now fails to probe with: tusb1210: probe of dwc3.0.auto.ulpi failed with error -16 (EBUSY) dwc3-pci needs to turn on the PHY once before dwc3 is loaded, but usually the PHY driver will then hold the GPIOs to turn off the PHY when requested (e.g. during suspend). To fix the problem, this reverts the commit to restore the old behavior to put the GPIOs immediately after usage. Link: https://www.spinics.net/lists/linux-usb/msg174681.html Cc: stable@vger.kernel.org Signed-off-by: Stephan Gerhold Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

Revert "usb: dwc3: gadget: skip Set/Clear Halt when invalid"

2018-11-26T07:05:27+00:00

This reverts commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3. Turns out that commit is wrong. Host controllers are allowed to use Clear Feature HALT as means to sync data toggle between host and periperal. Cc: Signed-off-by: Felipe Balbi