linux.git/drivers/usb/dwc3, branch v6.16 Linux kernel source tree usb: dwc3: qcom: Don't leave BCR asserted 2025-07-13T15:30:59+00:00 Krishna Kurapati krishna.kurapati@oss.qualcomm.com 2025-07-09T13:29:00+00:00 ef8abc0ba49ce717e6bc4124e88e59982671f3b5 Leaving the USB BCR asserted prevents the associated GDSC to turn on. This blocks any subsequent attempts of probing the device, e.g. after a probe deferral, with the following showing in the log: [ 1.332226] usb30_prim_gdsc status stuck at 'off' Leave the BCR deasserted when exiting the driver to avoid this issue. Cc: stable <stable@kernel.org> Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250709132900.3408752-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Leaving the USB BCR asserted prevents the associated GDSC to turn on. This
blocks any subsequent attempts of probing the device, e.g. after a probe
deferral, with the following showing in the log:

[    1.332226] usb30_prim_gdsc status stuck at 'off'

Leave the BCR deasserted when exiting the driver to avoid this issue.

Cc: stable <stable@kernel.org>
Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250709132900.3408752-1-krishna.kurapati@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: gadget: Fix TRB reclaim logic for short transfers and ZLPs 2025-06-28T15:19:56+00:00 SCHNEIDER Johannes johannes.schneider@leica-geosystems.com 2025-06-25T07:49:16+00:00 80e08394377559ed5a2ccadd861e62d24b826911 Commit 96c7bf8f6b3e ("usb: dwc3: gadget: Cleanup SG handling") updated the TRB reclaim path to use the TRB CHN (Chain) bit to determine whether a TRB was part of a chain. However, this inadvertently changed the behavior of reclaiming the final TRB in some scatter-gather or short transfer cases. In particular, if the final TRB did not have the CHN bit set, the cleanup path could incorrectly skip clearing the HWO (Hardware Own) bit, leaving stale TRBs in the ring. This resulted in broken data transfer completions in userspace, notably for MTP over FunctionFS. Fix this by unconditionally clearing the HWO bit during TRB reclaim, regardless of the CHN bit state. This restores correct behavior especially for transfers that require ZLPs or end on non-CHN TRBs. Fixes: 61440628a4ff ("usb: dwc3: gadget: Cleanup SG handling") Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/AM8PR06MB7521A29A8863C838B54987B6BC7BA@AM8PR06MB7521.eurprd06.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Commit 96c7bf8f6b3e ("usb: dwc3: gadget: Cleanup SG handling") updated
the TRB reclaim path to use the TRB CHN (Chain) bit to determine whether
a TRB was part of a chain. However, this inadvertently changed the
behavior of reclaiming the final TRB in some scatter-gather or short
transfer cases.

In particular, if the final TRB did not have the CHN bit set, the
cleanup path could incorrectly skip clearing the HWO (Hardware Own)
bit, leaving stale TRBs in the ring. This resulted in broken data
transfer completions in userspace, notably for MTP over FunctionFS.

Fix this by unconditionally clearing the HWO bit during TRB reclaim,
regardless of the CHN bit state. This restores correct behavior
especially for transfers that require ZLPs or end on non-CHN TRBs.

Fixes: 61440628a4ff ("usb: dwc3: gadget: Cleanup SG handling")
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/AM8PR06MB7521A29A8863C838B54987B6BC7BA@AM8PR06MB7521.eurprd06.prod.outlook.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: Abort suspend on soft disconnect failure 2025-06-19T10:34:39+00:00 Kuen-Han Tsai khtsai@google.com 2025-05-28T10:03:11+00:00 630a1dec3b0eba2a695b9063f1c205d585cbfec9 When dwc3_gadget_soft_disconnect() fails, dwc3_suspend_common() keeps going with the suspend, resulting in a period where the power domain is off, but the gadget driver remains connected. Within this time frame, invoking vbus_event_work() will cause an error as it attempts to access DWC3 registers for endpoint disabling after the power domain has been completely shut down. Abort the suspend sequence when dwc3_gadget_suspend() cannot halt the controller and proceeds with a soft connect. Fixes: 9f8a67b65a49 ("usb: dwc3: gadget: fix gadget suspend/resume") Cc: stable <stable@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Kuen-Han Tsai <khtsai@google.com> Link: https://lore.kernel.org/r/20250528100315.2162699-1-khtsai@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
When dwc3_gadget_soft_disconnect() fails, dwc3_suspend_common() keeps
going with the suspend, resulting in a period where the power domain is
off, but the gadget driver remains connected.  Within this time frame,
invoking vbus_event_work() will cause an error as it attempts to access
DWC3 registers for endpoint disabling after the power domain has been
completely shut down.

Abort the suspend sequence when dwc3_gadget_suspend() cannot halt the
controller and proceeds with a soft connect.

Fixes: 9f8a67b65a49 ("usb: dwc3: gadget: fix gadget suspend/resume")
Cc: stable <stable@kernel.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
Link: https://lore.kernel.org/r/20250528100315.2162699-1-khtsai@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3-exynos: add support for ExynosAutov920 2025-05-21T11:12:43+00:00 Pritam Manohar Sutar pritam.sutar@samsung.com 2025-05-16T07:13:33+00:00 657bfcbbfa38c8372408ca3f3085381b637838bd This SoC has a DWC3 compatible controllers. It needs "ref" and "susp_clk" for it's operation. Add required changes in exynos dwc3 glue layer to support this SoC. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Pritam Manohar Sutar <pritam.sutar@samsung.com> Link: https://lore.kernel.org/r/20250516071333.3223226-3-pritam.sutar@samsung.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This SoC has a DWC3 compatible controllers. It needs "ref" and
"susp_clk" for it's operation.

Add required changes in exynos dwc3 glue layer to support this SoC.

Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Pritam Manohar Sutar <pritam.sutar@samsung.com>
Link: https://lore.kernel.org/r/20250516071333.3223226-3-pritam.sutar@samsung.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: qcom: Use bulk clock API and devres 2025-05-21T11:10:23+00:00 Bjorn Andersson bjorn.andersson@oss.qualcomm.com 2025-05-09T03:42:11+00:00 e33ebb133a245a48b543d6eb79768a66f233656b The Qualcomm DWC3 glue driver duplicates the logic of the bulk clock API to acquire, prepare, and unprepare the controller's clocks. It also manages the life cycle of these handled explicitly. Transition to the bulk clock API and manage the resources using devres, to clean up the code. The resource acquisition is moved above the initial reset pulse, to handle resource issues before the state is touched - other than this, this no functional change. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20250508-dwc3-clk-bulk-v2-1-bad3427e88d4@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The Qualcomm DWC3 glue driver duplicates the logic of the bulk clock
API to acquire, prepare, and unprepare the controller's clocks. It also
manages the life cycle of these handled explicitly.

Transition to the bulk clock API and manage the resources using devres,
to clean up the code. The resource acquisition is moved above the
initial reset pulse, to handle resource issues before the state is
touched - other than this, this no functional change.

Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20250508-dwc3-clk-bulk-v2-1-bad3427e88d4@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge 6.15-rc6 into usb-next 2025-05-13T06:26:58+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2025-05-13T06:26:58+00:00 ab6dc9a6c721c2eed867c157447764ae68ff9b7e We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
We need the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: gadget: Make gadget_wakeup asynchronous 2025-05-01T15:38:55+00:00 Prashanth K prashanth.k@oss.qualcomm.com 2025-04-22T10:32:31+00:00 2372f1caeca433c4c01c2482f73fbe057f5168ce Currently gadget_wakeup() waits for U0 synchronously if it was called from func_wakeup(), this is because we need to send the function wakeup command soon after the link is active. And the call is made synchronous by polling DSTS continuosly for 20000 times in __dwc3_gadget_wakeup(). But it observed that sometimes the link is not active even after polling 20K times, leading to remote wakeup failures. Adding a small delay between each poll helps, but that won't guarantee resolution in future. Hence make the gadget_wakeup completely asynchronous. Since multiple interfaces can issue a function wakeup at once, add a new variable wakeup_pending_funcs which will indicate the functions that has issued func_wakup, this is represented in a bitmap format. If the link is in U3, dwc3_gadget_func_wakeup() will set the bit corresponding to interface_id and bail out. Once link comes back to U0, linksts_change irq is triggered, where the function wakeup command is sent based on bitmap. Cc: stable <stable@kernel.org> Fixes: 92c08a84b53e ("usb: dwc3: Add function suspend and function wakeup support") Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20250422103231.1954387-4-prashanth.k@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Currently gadget_wakeup() waits for U0 synchronously if it was
called from func_wakeup(), this is because we need to send the
function wakeup command soon after the link is active. And the
call is made synchronous by polling DSTS continuosly for 20000
times in __dwc3_gadget_wakeup(). But it observed that sometimes
the link is not active even after polling 20K times, leading to
remote wakeup failures. Adding a small delay between each poll
helps, but that won't guarantee resolution in future. Hence make
the gadget_wakeup completely asynchronous.

Since multiple interfaces can issue a function wakeup at once,
add a new variable wakeup_pending_funcs which will indicate the
functions that has issued func_wakup, this is represented in a
bitmap format. If the link is in U3, dwc3_gadget_func_wakeup()
will set the bit corresponding to interface_id and bail out.
Once link comes back to U0, linksts_change irq is triggered,
where the function wakeup command is sent based on bitmap.

Cc: stable <stable@kernel.org>
Fixes: 92c08a84b53e ("usb: dwc3: Add function suspend and function wakeup support")
Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20250422103231.1954387-4-prashanth.k@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge 6.15-rc4 into usb-next 2025-04-28T08:32:58+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2025-04-28T08:32:58+00:00 615dca38c2eae55aff80050275931c87a812b48c We need the USB fixes in here as well, and this resolves the following merge conflicts that were reported in linux-next: drivers/usb/chipidea/ci_hdrc_imx.c drivers/usb/host/xhci.h Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
We need the USB fixes in here as well, and this resolves the following
merge conflicts that were reported in linux-next:

	drivers/usb/chipidea/ci_hdrc_imx.c
	drivers/usb/host/xhci.h

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: qcom: Fix error handling in probe 2025-04-25T11:22:25+00:00 Dan Carpenter dan.carpenter@linaro.org 2025-04-23T08:23:53+00:00 4c0fca65d10548f68c040ed49bf1860ce0dda9b9 There are two issues: 1) Return -EINVAL if platform_get_resource() fails. Don't return success. 2) The devm_ioremap() function doesn't return error pointers, it returns NULL. Update the check. Fixes: 1881a32fe14d ("usb: dwc3: qcom: Transition to flattened model") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/aAijmfAph0FlTqg6@stanley.mountain Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
There are two issues:
1) Return -EINVAL if platform_get_resource() fails.  Don't return
   success.
2) The devm_ioremap() function doesn't return error pointers, it returns
   NULL.  Update the check.

Fixes: 1881a32fe14d ("usb: dwc3: qcom: Transition to flattened model")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/aAijmfAph0FlTqg6@stanley.mountain
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: qcom: use modern PM macros 2025-04-25T11:22:00+00:00 Arnd Bergmann arnd@arndb.de 2025-04-23T16:26:09+00:00 45ebb7baf2356c3d9118c40216ad5b3d0d516b15 The use of the old SET_SYSTEM_SLEEP_PM_OPS/SET_RUNTIME_PM_OPS macros without __maybe_unused annotations causes warnings when build testing without CONFIG_PM: drivers/usb/dwc3/dwc3-qcom.c:421:12: error: unused function 'dwc3_qcom_suspend' [-Werror,-Wunused-function] 421 | static int dwc3_qcom_suspend(struct dwc3_qcom *qcom, bool wakeup) | ^~~~~~~~~~~~~~~~~ drivers/usb/dwc3/dwc3-qcom.c:457:12: error: unused function 'dwc3_qcom_resume' [-Werror,-Wunused-function] 457 | static int dwc3_qcom_resume(struct dwc3_qcom *qcom, bool wakeup) Change these to the modern SYSTEM_SLEEP_PM_OPS/RUNTIME_PM_OPS/pm_ptr macros, which avoids the warnings and improves readability at the same time. Fixes: 1881a32fe14d ("usb: dwc3: qcom: Transition to flattened model") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20250423162613.2082417-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The use of the old SET_SYSTEM_SLEEP_PM_OPS/SET_RUNTIME_PM_OPS macros
without __maybe_unused annotations causes warnings when build testing
without CONFIG_PM:

drivers/usb/dwc3/dwc3-qcom.c:421:12: error: unused function 'dwc3_qcom_suspend' [-Werror,-Wunused-function]
  421 | static int dwc3_qcom_suspend(struct dwc3_qcom *qcom, bool wakeup)
      |            ^~~~~~~~~~~~~~~~~
drivers/usb/dwc3/dwc3-qcom.c:457:12: error: unused function 'dwc3_qcom_resume' [-Werror,-Wunused-function]
  457 | static int dwc3_qcom_resume(struct dwc3_qcom *qcom, bool wakeup)

Change these to the modern SYSTEM_SLEEP_PM_OPS/RUNTIME_PM_OPS/pm_ptr
macros, which avoids the warnings and improves readability at the same
time.

Fixes: 1881a32fe14d ("usb: dwc3: qcom: Transition to flattened model")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20250423162613.2082417-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>