kernel/linux.git/drivers/usb/dwc3, branch v6.1.124

usb: dwc3: xilinx: make sure pipe clock is deselected in usb2 only mode

2024-12-19T17:08:50+00:00

commit a48f744bef9ee74814a9eccb030b02223e48c76c upstream. When the USB3 PHY is not defined in the Linux device tree, there could still be a case where there is a USB3 PHY active on the board and enabled by the first stage bootloader. If serdes clock is being used then the USB will fail to enumerate devices in 2.0 only mode. To solve this, make sure that the PIPE clock is deselected whenever the USB3 PHY is not defined and guarantees that the USB2 only mode will work in all cases. Fixes: 9678f3361afc ("usb: dwc3: xilinx: Skip resets and USB3 register settings for USB2.0 mode") Cc: stable@vger.kernel.org Signed-off-by: Neal Frager Signed-off-by: Radhey Shyam Pandey Acked-by: Peter Korsgaard Link: https://lore.kernel.org/r/1733163111-1414816-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman

usb: dwc3: ep0: Don't reset resource alloc flag

2024-12-14T18:54:55+00:00

commit f2e0eee4703869dc5edb5302a919861566ca7797 upstream. The DWC3_EP_RESOURCE_ALLOCATED flag ensures that the resource of an endpoint is only assigned once. Unless the endpoint is reset, don't clear this flag. Otherwise we may set endpoint resource again, which prevents the driver from initiate transfer after handling a STALL or endpoint halt to the control endpoint. Cc: stable@vger.kernel.org Fixes: b311048c174d ("usb: dwc3: gadget: Rewrite endpoint allocation flow") Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/00122b7cc5be06abef461776e7cc9f5ebc8bc1cb.1713229786.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman

usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED

2024-12-14T18:54:25+00:00

[ Upstream commit 5d2fb074dea289c41f5aaf2c3f68286bee370634 ] The driver cannot issue the End Transfer command to the SETUP transfer. Don't clear DWC3_EP_TRANSFER_STARTED flag to make sure that the driver won't send Start Transfer command again, which can cause no-resource error. For example this can occur if the host issues a reset to the device. Cc: stable@vger.kernel.org Fixes: 76cb323f80ac ("usb: dwc3: ep0: clear all EP0 flags") Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/d3d618185fd614bb7426352a9fc1199641d3b5f5.1731545781.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: dwc3: ep0: Don't reset resource alloc flag (including ep0)

2024-12-14T18:54:24+00:00

[ Upstream commit 72fca8371f205d654f95b09cd023a71fd5307041 ] The DWC3_EP_RESOURCE_ALLOCATED flag ensures that the resource of an endpoint is only assigned once. Unless the endpoint is reset, don't clear this flag. Otherwise we may set endpoint resource again, which prevents the driver from initiate transfer after handling a STALL or endpoint halt to the control endpoint. Commit f2e0eee47038 ("usb: dwc3: ep0: Don't reset resource alloc flag") was fixing the initial issue, but did this only for physical ep1. Since the function dwc3_ep0_stall_and_restart is resetting the flags for both physical endpoints, this also has to be done for ep0. Cc: stable@vger.kernel.org Fixes: b311048c174d ("usb: dwc3: gadget: Rewrite endpoint allocation flow") Acked-by: Thinh Nguyen Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20240814-dwc3hwep0reset-v2-1-29e1d7d923ea@pengutronix.de Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 5d2fb074dea2 ("usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED") Signed-off-by: Sasha Levin

usb: dwc3: gadget: Rewrite endpoint allocation flow

2024-12-14T18:54:24+00:00

[ Upstream commit b311048c174da893f47fc09439bc1f6fa2a29589 ] The driver dwc3 deviates from the programming guide in regard to endpoint configuration. It does this command sequence: DEPSTARTCFG -> DEPXFERCFG -> DEPCFG Instead of the suggested flow: DEPSTARTCFG -> DEPCFG -> DEPXFERCFG The reasons for this deviation were as follow, quoted: 1) The databook says to do %DWC3_DEPCMD_DEPSTARTCFG for every %USB_REQ_SET_CONFIGURATION and %USB_REQ_SET_INTERFACE (8.1.5). This is incorrect in the scenario of multiple interfaces. 2) The databook does not mention doing more %DWC3_DEPCMD_DEPXFERCFG for new endpoint on alt setting (8.1.6). Regarding 1), DEPSTARTCFG resets the endpoints' resource and can be a problem if used with SET_INTERFACE request of a multiple interface configuration. But we can still satisfy the programming guide requirement by assigning the endpoint resource as part of usb_ep_enable(). We will only reset endpoint resources on controller initialization and SET_CONFIGURATION request. Regarding 2), the later versions of the programming guide were updated to clarify this flow (see "Alternate Initialization on SetInterface Request" of the programming guide). As long as the platform has enough physical endpoints, we can assign resource to a new endpoint. The order of the command sequence will not be a problem to most platforms for the current implementation of the dwc3 driver. However, this order is required in different scenarios (such as initialization during controller's hibernation restore). Let's keep the flow consistent and follow the programming guide. Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/c143583a5afb087deb8c3aa5eb227ee23515f272.1706754219.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 5d2fb074dea2 ("usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED") Signed-off-by: Sasha Levin

usb: dwc3: gadget: Fix looping of queued SG entries

2024-12-14T18:54:05+00:00

commit b7fc65f5141c24785dc8c19249ca4efcf71b3524 upstream. The dwc3_request->num_queued_sgs is decremented on completion. If a partially completed request is handled, then the dwc3_request->num_queued_sgs no longer reflects the total number of num_queued_sgs (it would be cleared). Correctly check the number of request SG entries remained to be prepare and queued. Failure to do this may cause null pointer dereference when accessing non-existent SG entry. Cc: stable@vger.kernel.org Fixes: c96e6725db9d ("usb: dwc3: gadget: Correct the logic for queuing sgs") Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/d07a7c4aa0fcf746cdca0515150dbe5c52000af7.1731545781.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman

usb: dwc3: gadget: Fix checking for number of TRBs left

2024-12-14T18:54:05+00:00

commit 02a6982b0ccfcdc39e20016f5fc9a1b7826a6ee7 upstream. The check whether the TRB ring is full or empty in dwc3_calc_trbs_left() is insufficient. It assumes there are active TRBs if there's any request in the started_list. However, that's not the case for requests with a large SG list. That is, if we have a single usb request that requires more TRBs than the total TRBs in the TRB ring, the queued TRBs will be available when all the TRBs in the ring are completed. But the request is only partially completed and remains in the started_list. With the current logic, the TRB ring is empty, but dwc3_calc_trbs_left() returns 0. Fix this by additionally checking for the request->num_trbs for active TRB count. Cc: stable@vger.kernel.org Fixes: 51f1954ad853 ("usb: dwc3: gadget: Fix dwc3_calc_trbs_left()") Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/708dc62b56b77da1f704cc2ae9b6ddb1f2dbef1f.1731545781.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

usb: dwc3: fix fault at system suspend if device was already runtime suspended

2024-11-14T12:15:18+00:00

commit 9cfb31e4c89d200d8ab7cb1e0bb9e6e8d621ca0b upstream. If the device was already runtime suspended then during system suspend we cannot access the device registers else it will crash. Also we cannot access any registers after dwc3_core_exit() on some platforms so move the dwc3_enable_susphy() call to the top. Cc: stable@vger.kernel.org # v5.15+ Reported-by: William McVicker Closes: https://lore.kernel.org/all/ZyVfcUuPq56R2m1Y@google.com Fixes: 705e3ce37bcc ("usb: dwc3: core: Fix system suspend on TI AM62 platforms") Signed-off-by: Roger Quadros Acked-by: Thinh Nguyen Tested-by: Will McVicker Link: https://lore.kernel.org/r/20241104-am62-lpm-usb-fix-v1-1-e93df73a4f0d@kernel.org Signed-off-by: Greg Kroah-Hartman

usb: dwc3: core: Fix system suspend on TI AM62 platforms

2024-11-01T00:56:02+00:00

[ Upstream commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 ] Since commit 6d735722063a ("usb: dwc3: core: Prevent phy suspend during init"), system suspend is broken on AM62 TI platforms. Before that commit, both DWC3_GUSB3PIPECTL_SUSPHY and DWC3_GUSB2PHYCFG_SUSPHY bits (hence forth called 2 SUSPHY bits) were being set during core initialization and even during core re-initialization after a system suspend/resume. These bits are required to be set for system suspend/resume to work correctly on AM62 platforms. Since that commit, the 2 SUSPHY bits are not set for DEVICE/OTG mode if gadget driver is not loaded and started. For Host mode, the 2 SUSPHY bits are set before the first system suspend but get cleared at system resume during core re-init and are never set again. This patch resovles these two issues by ensuring the 2 SUSPHY bits are set before system suspend and restored to the original state during system resume. Cc: stable@vger.kernel.org # v6.9+ Fixes: 6d735722063a ("usb: dwc3: core: Prevent phy suspend during init") Link: https://lore.kernel.org/all/1519dbe7-73b6-4afc-bfe3-23f4f75d772f@kernel.org/ Signed-off-by: Roger Quadros Acked-by: Thinh Nguyen Tested-by: Markus Schneider-Pargmann Reviewed-by: Dhruva Gole Link: https://lore.kernel.org/r/20241011-am62-lpm-usb-v3-1-562d445625b5@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: dwc3: Wait for EndXfer completion before restoring GUSB2PHYCFG

2024-10-22T13:56:49+00:00

commit c96e31252110a84dcc44412e8a7b456b33c3e298 upstream. DWC3 programming guide mentions that when operating in USB2.0 speeds, if GUSB2PHYCFG[6] or GUSB2PHYCFG[8] is set, it must be cleared prior to issuing commands and may be set again after the command completes. But currently while issuing EndXfer command without CmdIOC set, we wait for 1ms after GUSB2PHYCFG is restored. This results in cases where EndXfer command doesn't get completed and causes SMMU faults since requests are unmapped afterwards. Hence restore GUSB2PHYCFG after waiting for EndXfer command completion. Cc: stable@vger.kernel.org Fixes: 1d26ba0944d3 ("usb: dwc3: Wait unconditionally after issuing EndXfer command") Signed-off-by: Prashanth K Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20240924093208.2524531-1-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman