summaryrefslogtreecommitdiff
path: root/drivers/usb/dwc3/gadget.c
AgeCommit message (Collapse)Author
2025-05-01usb: dwc3: gadget: Make gadget_wakeup asynchronousPrashanth K
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>
2025-04-11usb: dwc3: gadget: check that event count does not exceed event buffer lengthFrode Isaksen
The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34 Signed-off-by: Frode Isaksen <frode@meta.com> Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable <stable@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20250403072907.448524-1-fisaksen@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-14usb: dwc3: Don't use %pK through printkThomas Weißschuh
This is a revert of commit 04fb365c453e ("usb: dwc3: replace %p with %pK") When the formatting was changed from %p to %pK that was a security improvement, as %p would leak raw pointer values to the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. On the other hand, restricted pointers ("%pK") were never meant to be used through printk(). They can unintentionally still leak raw pointers or acquire sleeping looks in atomic contexts. Switch back to regular %p again. Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://lore.kernel.org/r/20250310-restricted-pointers-usb-v2-2-a7598e2d47d1@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-10Merge v6.14-rc6 into usb-nextGreg Kroah-Hartman
Resolves the merge conflict with: drivers/usb/typec/ucsi/ucsi_acpi.c Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-03usb: dwc3: gadget: Prevent irq storm when TH re-executesBadhri Jagan Sridharan
While commit d325a1de49d6 ("usb: dwc3: gadget: Prevent losing events in event cache") makes sure that top half(TH) does not end up overwriting the cached events before processing them when the TH gets invoked more than one time, returning IRQ_HANDLED results in occasional irq storm where the TH hogs the CPU. The irq storm can be prevented by the flag before event handler busy is cleared. Default enable interrupt moderation in all versions which support them. ftrace event stub during dwc3 irq storm: irq/504_dwc3-1111 ( 1111) [000] .... 70.000866: irq_handler_exit: irq=14 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000872: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000874: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000881: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000883: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000889: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000892: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000898: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000901: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000907: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000909: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000915: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000918: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000924: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000927: irq_handler_exit: irq=504 ret=handled irq/504_dwc3-1111 ( 1111) [000] .... 70.000933: irq_handler_entry: irq=504 name=dwc3 irq/504_dwc3-1111 ( 1111) [000] .... 70.000935: irq_handler_exit: irq=504 ret=handled .... Cc: stable <stable@kernel.org> Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Fixes: d325a1de49d6 ("usb: dwc3: gadget: Prevent losing events in event cache") Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20250216223003.3568039-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-17Merge 6.14-rc3 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-14usb: dwc3: gadget: Add support for snps,reserved-endpoints propertyAndy Shevchenko
The snps,reserved-endpoints property lists the reserved endpoints that shouldn't be used for normal transfers. Add support for that to the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Ferry Toth <fntoth@gmail.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20250212193116.2487289-4-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-14usb: dwc3: gadget: Refactor loop to avoid NULL endpointsAndy Shevchenko
Prepare the gadget driver to handle the reserved endpoints that will be not allocated at the initialisation time. While at it, add a warning where the NULL endpoint should never happen. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Ferry Toth <fntoth@gmail.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20250212193116.2487289-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-14usb: dwc3: Fix timeout issue during controller enter/exit from halt stateSelvarasu Ganesan
There is a frequent timeout during controller enter/exit from halt state after toggling the run_stop bit by SW. This timeout occurs when performing frequent role switches between host and device, causing device enumeration issues due to the timeout. This issue was not present when USB2 suspend PHY was disabled by passing the SNPS quirks (snps,dis_u2_susphy_quirk and snps,dis_enblslpm_quirk) from the DTS. However, there is a requirement to enable USB2 suspend PHY by setting of GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY bits when controller starts in gadget or host mode results in the timeout issue. This commit addresses this timeout issue by ensuring that the bits GUSB2PHYCFG.ENBLSLPM and GUSB2PHYCFG.SUSPHY are cleared before starting the dwc3_gadget_run_stop sequence and restoring them after the dwc3_gadget_run_stop sequence is completed. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable <stable@kernel.org> Signed-off-by: Selvarasu Ganesan <selvarasu.g@samsung.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20250201163903.459-1-selvarasu.g@samsung.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-15usb: dwc3: gadget: Reinitiate stream for all host NoStream behaviorThinh Nguyen
There are too many different host behaviors when it comes to NoStream handling, and not everyone follows the USB and xHCI spec. The DWC3 driver attempts to do some guess work to interop with different hosts, but it can't cover everything. Let's keep it simple and treat every host the same: just retry on NoStream after a 100ms of no response delay. Note that some hosts cannot handle frequent retries. This may affect performance on certain defective hosts, but NoStream is a rare occurrence and interoperability is more important. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/b92ae94c86f01f165d5f178b7767898573b6dc75.1736819308.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-13Merge 6.13-rc7 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well for testing. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-24usb: dwc3: gadget: Fix incorrect UDC state after manual deconfigurationRoy Luo
The UDC state in sysfs (/sys/class/udc/<udc>/state) should accurately reflect the current state of the USB Device Controller. Currently, the UDC state is not handled consistently during gadget disconnection. While the disconnect interrupt path correctly sets the state to "not-attached", manual deconfiguration leaves the state in "configured", misrepresenting the actual situation. This commit ensures consistent UDC state handling by setting the state to "not-attached" after manual deconfiguration. This accurately reflects the UDC's state and provides a consistent behavior regardless of the disconnection method. Signed-off-by: Roy Luo <royluo@google.com> Reviewed-by: André Draszik <andre.draszik@linaro.org> Tested-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20241223042536.1465299-1-royluo@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-23usb: dwc3: gadget: fix writing NYET thresholdAndré Draszik
Before writing a new value to the register, the old value needs to be masked out for the new value to be programmed as intended, because at least in some cases the reset value of that field is 0xf (max value). At the moment, the dwc3 core initialises the threshold to the maximum value (0xf), with the option to override it via a DT. No upstream DTs seem to override it, therefore this commit doesn't change behaviour for any upstream platform. Nevertheless, the code should be fixed to have the desired outcome. Do so. Fixes: 80caf7d21adc ("usb: dwc3: add lpm erratum support") Cc: stable@vger.kernel.org # 5.10+ (needs adjustment for 5.4) Signed-off-by: André Draszik <andre.draszik@linaro.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20241209-dwc3-nyet-fix-v2-1-02755683345b@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-16usb: dwc3: gadget: Remove dwc3_request->needs_extra_trbThinh Nguyen
Now that we track TRBs base on request->num_trbs on reclaim, we don't need to save the dwc3_request->needs_extra_trb check. Remove it. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/08dd88a3308ac7894267c52340eaf0e1564bbf36.1731545781.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-16usb: dwc3: gadget: Cleanup SG handlingThinh Nguyen
The current logic in dwc3 driver is tracking req->num_queued_sgs and req->sg. But they can be checked base on the num_pending_sgs and num_trbs. They are redundant and can complicate the SG logic. Let's remove them. Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/96c7bf8f6b3e91e607d5b78ea51cb1d00c614eaf.1731545781.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-16usb: dwc3: gadget: Fix looping of queued SG entriesThinh Nguyen
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 <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/d07a7c4aa0fcf746cdca0515150dbe5c52000af7.1731545781.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-16usb: dwc3: gadget: Fix checking for number of TRBs leftThinh Nguyen
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 <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/708dc62b56b77da1f704cc2ae9b6ddb1f2dbef1f.1731545781.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-13usb: dwc3: gadget: Add missing check for single port RAM in TxFIFO resizing ↵Selvarasu Ganesan
logic The existing implementation of the TxFIFO resizing logic only supports scenarios where more than one port RAM is used. However, there is a need to resize the TxFIFO in USB2.0-only mode where only a single port RAM is available. This commit introduces the necessary changes to support TxFIFO resizing in such scenarios by adding a missing check for single port RAM. This fix addresses certain platform configurations where the existing TxFIFO resizing logic does not work properly due to the absence of support for single port RAM. By adding this missing check, we ensure that the TxFIFO resizing logic works correctly in all scenarios, including those with a single port RAM. Fixes: 9f607a309fbe ("usb: dwc3: Resize TX FIFOs to meet EP bursting requirements") Cc: stable@vger.kernel.org # 6.12.x: fad16c82: usb: dwc3: gadget: Refine the logic for resizing Tx FIFOs Signed-off-by: Selvarasu Ganesan <selvarasu.g@samsung.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20241112044807.623-1-selvarasu.g@samsung.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-29usb: dwc3: gadget: Refine the logic for resizing Tx FIFOsAkash Kumar
The current logic is rigid, setting num_fifos to fixed values. 3 for any maxburst greater than 1. tx_fifo_resize_max_num for maxburst greater than 6. Additionally, it did not differentiate much between bulk and isochronous transfers, applying similar logic to both. The updated logic is more flexible and specifically designed to meet the unique requirements of both bulk and isochronous transfers. We have made every effort to satisfy all needs and requirements, verified on our specific platform and application. Bulk Transfers: Ensures that num_fifos is optimized by considering both the maxburst and DT property "tx-fifo-max-num" for super speed and above. For high-speed and below bulk endpoints, a 2K TxFIFO allocation is used to meet efficient data transfer needs, considering FIFO-constrained platforms. Isochronous Transfers: Ensures that num_fifos is sufficient by considering the maximum packet multiplier for HS and below and maxburst for Super-speed and above eps, along with a constraint with the DT property "tx-fifo-max-num". This change aims to optimize the allocation of Tx FIFOs for both bulk and isochronous endpoints, potentially improving data transfer efficiency and overall performance. It also enhances support for all use cases, which can be tweaked with DT parameters and the endpoint’s maxburst and maxpacket. This structured approach ensures that the appropriate number of FIFOs is allocated based on the endpoint type and USB speed. Signed-off-by: Akash Kumar <quic_akakum@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20241017064423.7056-1-quic_akakum@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-16usb: dwc3: Wait for EndXfer completion before restoring GUSB2PHYCFGPrashanth K
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 <quic_prashk@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20240924093208.2524531-1-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-04usb: dwc3: core: Stop processing of pending events if controller is haltedSelvarasu Ganesan
This commit addresses an issue where events were being processed when the controller was in a halted state. To fix this issue by stop processing the events as the event count was considered stale or invalid when the controller was halted. Fixes: fc8bb91bc83e ("usb: dwc3: implement runtime PM") Cc: stable@kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g@samsung.com> Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20240916231813.206-1-selvarasu.g@samsung.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-09-03usb: dwc3: Avoid waking up gadget during startxferPrashanth K
When operating in High-Speed, it is observed that DSTS[USBLNKST] doesn't update link state immediately after receiving the wakeup interrupt. Since wakeup event handler calls the resume callbacks, there is a chance that function drivers can perform an ep queue, which in turn tries to perform remote wakeup from send_gadget_ep_cmd(STARTXFER). This happens because DSTS[[21:18] wasn't updated to U0 yet, it's observed that the latency of DSTS can be in order of milli-seconds. Hence avoid calling gadget_wakeup during startxfer to prevent unnecessarily issuing remote wakeup to host. Fixes: c36d8e947a56 ("usb: dwc3: gadget: put link to U0 before Start Transfer") Cc: stable@vger.kernel.org Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Prashanth K <quic_prashk@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20240828064302.3796315-1-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-05-10usb: dwc3: Wait unconditionally after issuing EndXfer commandPrashanth K
Currently all controller IP/revisions except DWC3_usb3 >= 310a wait 1ms unconditionally for ENDXFER completion when IOC is not set. This is because DWC_usb3 controller revisions >= 3.10a supports GUCTL2[14: Rst_actbitlater] bit which allows polling CMDACT bit to know whether ENDXFER command is completed. Consider a case where an IN request was queued, and parallelly soft_disconnect was called (due to ffs_epfile_release). This eventually calls stop_active_transfer with IOC cleared, hence send_gadget_ep_cmd() skips waiting for CMDACT cleared during EndXfer. For DWC3 controllers with revisions >= 310a, we don't forcefully wait for 1ms either, and we proceed by unmapping the requests. If ENDXFER didn't complete by this time, it leads to SMMU faults since the controller would still be accessing those requests. Fix this by ensuring ENDXFER completion by adding 1ms delay in __dwc3_stop_active_transfer() unconditionally. Cc: stable@vger.kernel.org Fixes: b353eb6dc285 ("usb: dwc3: gadget: Skip waiting for CMDACT cleared during endxfer") Signed-off-by: Prashanth K <quic_prashk@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20240502044103.1066350-1-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-04-23usb: dwc3: core: Prevent phy suspend during initThinh Nguyen
GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout. The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant. This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers. Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes. Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Cc: stable@vger.kernel.org Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-26usb: dwc3: Properly set system wakeupThinh Nguyen
If the device is configured for system wakeup, then make sure that the xHCI driver knows about it and make sure to permit wakeup only at the appropriate time. For host mode, if the controller goes through the dwc3 code path, then a child xHCI platform device is created. Make sure the platform device also inherits the wakeup setting for xHCI to enable remote wakeup. For device mode, make sure to disable system wakeup if no gadget driver is bound. We may experience unwanted system wakeup due to the wakeup signal from the controller PMU detecting connection/disconnection when in low power (D3). E.g. In the case of Steam Deck, the PCI PME prevents the system staying in suspend. Cc: stable@vger.kernel.org Reported-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Closes: https://lore.kernel.org/linux-usb/70a7692d-647c-9be7-00a6-06fc60f77294@igalia.com/T/#mf00d6669c2eff7b308d1162acd1d66c09f0853c7 Fixes: d07e8819a03d ("usb: dwc3: add xHCI Host support") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Sanath S <Sanath.S@amd.com> Tested-by: Guilherme G. Piccoli <gpiccoli@igalia.com> # Steam Deck Link: https://lore.kernel.org/r/667cfda7009b502e08462c8fb3f65841d103cc0a.1709865476.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-26Merge v6.8-rc6 into usb-nextGreg Kroah-Hartman
We need it here for the USB fixes, and it resolves a merge conflict as reported in linux-next in drivers/usb/roles/class.c Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-19usb: dwc3: gadget: Don't disconnect if not startedThinh Nguyen
Don't go through soft-disconnection sequence if the controller hasn't started. Otherwise, there will be timeout and warning reports from the soft-disconnection flow. Cc: stable@vger.kernel.org Fixes: 61a348857e86 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/linux-usb/20240215233536.7yejlj3zzkl23vjd@synopsys.com/T/#mb0661cd5f9272602af390c18392b9a36da4f96e6 Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/e3be9b929934e0680a6f4b8f6eb11b18ae9c7e07.1708043922.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-19Merge 6.8-rc5 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-17usb: dwc3: gadget: Remove redundant assignment to pointer trbColin Ian King
The pointer trb is being assigned a value that is not being read afterwards, it is being re-assigned later inside a for_each_sg loop. The assignment is redundant and can be removed. Cleans up clang scan warning: drivers/usb/dwc3/gadget.c:3432:19: warning: Value stored to 'trb' during its initialization is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20240207120319.2445123-1-colin.i.king@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-17usb: dwc3: gadget: Rewrite endpoint allocation flowThinh Nguyen
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 <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/c143583a5afb087deb8c3aa5eb227ee23515f272.1706754219.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-09Revert "usb: dwc3: Support EBC feature of DWC_usb31"Thinh Nguyen
This reverts commit 398aa9a7e77cf23c2a6f882ddd3dcd96f21771dc. The update to the gadget API to support EBC feature is incomplete. It's missing at least the following: * New usage documentation * Gadget capability check * Condition for the user to check how many and which endpoints can be used as "fifo_mode" * Description of how it can affect completed request (e.g. dwc3 won't update TRB on completion -- ie. how it can affect request's actual length report) Let's revert this until it's ready. Fixes: 398aa9a7e77c ("usb: dwc3: Support EBC feature of DWC_usb31") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/3042f847ff904b4dd4e4cf66a1b9df470e63439e.1707441690.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-27usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspendUttkarsh Aggarwal
In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadget_driver is cleared and in parallel CPU2 executes dwc3_gadget_suspend where it finds dwc->gadget_driver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where it checks dwc->gadget_driver is already NULL because of which the NULL pointer deference occur. Cc: stable@vger.kernel.org Fixes: 9772b47a4c29 ("usb: dwc3: gadget: Fix suspend/resume during device mode") Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com> Link: https://lore.kernel.org/r/20240119094825.26530-1-quic_uaggarwa@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-04usb: dwc3: gadget: Queue PM runtime idle on disconnect eventWesley Cheng
There is a scenario where DWC3 runtime suspend is blocked due to the dwc->connected flag still being true while PM usage_count is zero after DWC3 giveback is completed and the USB gadget session is being terminated. This leads to a case where nothing schedules a PM runtime idle for the device. The exact condition is seen with the following sequence: 1. USB bus reset is issued by the host 2. Shortly after, or concurrently, a USB PD DR SWAP request is received (sink->source) 3. USB bus reset event handler runs and issues dwc3_stop_active_transfers(), and pending transfer are stopped 4. DWC3 usage_count decremented to 0, and runtime idle occurs while dwc->connected == true, returns -EBUSY 5. DWC3 disconnect event seen, dwc->connected set to false due to DR swap handling 6. No runtime idle after this point Address this by issuing an asynchronous PM runtime idle call after the disconnect event is completed, as it modifies the dwc->connected flag, which is what blocks the initial runtime idle. Fixes: fc8bb91bc83e ("usb: dwc3: implement runtime PM") Cc: <stable@vger.kernel.org> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20240103214946.2596-1-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-04usb: dwc3: Support EBC feature of DWC_usb31Manan Aurora
Support configuration and use of bulk endpoints in the so-called EBC mode described in the DBC_usb31 databook (appendix E) Added a bit fifo_mode to usb_ep to indicate to the UDC driver that a specific endpoint is to operate in the EBC (or equivalent) mode when enabled Added macros for bits 15 and 14 of DEPCFG parameter 1 to indicate EBC mode and write back behaviour. These bits will be set to 1 when configuring an EBC endpoint as described in the programming guide Signed-off-by: Manan Aurora <maurora@google.com> Link: https://lore.kernel.org/r/20231031034641.660606-1-maurora@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-04usb: dwc3: gadget: Handle EP0 request dequeuing properlyWesley Cheng
Current EP0 dequeue path will share the same as other EPs. However, there are some special considerations that need to be made for EP0 transfers: - EP0 transfers never transition into the started_list - EP0 only has one active request at a time In case there is a vendor specific control message for a function over USB FFS, then there is no guarantee on the timeline which the DATA/STATUS stage is responded to. While this occurs, any attempt to end transfers on non-control EPs will end up having the DWC3_EP_DELAY_STOP flag set, and defer issuing of the end transfer command. If the USB FFS application decides to timeout the control transfer, or if USB FFS AIO path exits, the USB FFS driver will issue a call to usb_ep_dequeue() for the ep0 request. In case of the AIO exit path, the AIO FS blocks until all pending USB requests utilizing the AIO path is completed. However, since the dequeue of ep0 req does not happen properly, all non-control EPs with the DWC3_EP_DELAY_STOP flag set will not be handled, and the AIO exit path will be stuck waiting for the USB FFS data endpoints to receive a completion callback. Fix is to utilize dwc3_ep0_reset_state() in the dequeue API to ensure EP0 is brought back to the SETUP state, and ensures that any deferred end transfer commands are handled. This also will end any active transfers on EP0, compared to the previous implementation which directly called giveback only. Fixes: fcd2def66392 ("usb: dwc3: gadget: Refactor dwc3_gadget_ep_dequeue") Cc: stable <stable@kernel.org> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20231206201814.32664-1-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04usb: dwc3: Properly handle processing of pending eventsElson Roy Serrao
If dwc3 is runtime suspended we defer processing the event buffer until resume, by setting the pending_events flag. Set this flag before triggering resume to avoid race with the runtime resume callback. While handling the pending events, in addition to checking the event buffer we also need to process it. Handle this by explicitly calling dwc3_thread_interrupt(). Also balance the runtime pm get() operation that triggered this processing. Cc: stable@vger.kernel.org Fixes: fc8bb91bc83e ("usb: dwc3: implement runtime PM") Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20230801192658.19275-1-quic_eserrao@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-03Merge tag 'usb-6.5-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB / Thunderbolt driver updates from Greg KH: "Here is the big set of USB and Thunderbolt driver updates for 6.5-rc1. Included in here are: - Lots of USB4/Thunderbolt additions and updates for new hardware types and fixes as people are starting to get access to the hardware in the wild - new gadget controller driver, cdns2, added - new typec drivers added - xhci driver updates - typec driver updates - usbip driver fixes - usb-serial driver updates and fixes - lots of smaller USB driver updates All of these have been in linux-next for a while with no reported problems" * tag 'usb-6.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (265 commits) usb: host: xhci-plat: Set XHCI_STATE_REMOVING before resuming XHCI HC usb: host: xhci: Do not re-initialize the XHCI HC if being removed usb: typec: nb7vpq904m: fix CONFIG_DRM dependency usbip: usbip_host: Replace strlcpy with strscpy usb: dwc3: gadget: Propagate core init errors to UDC during pullup USB: serial: option: add LARA-R6 01B PIDs usb: ulpi: Make container_of() no-op in to_ulpi_dev() usb: gadget: legacy: fix error return code in gfs_bind usb: typec: fsa4480: add support for Audio Accessory Mode usb: typec: fsa4480: rework mux & switch setup to handle more states usb: typec: ucsi: call typec_set_mode on non-altmode partner change USB: gadget: f_hid: make hidg_class a static const structure USB: gadget: f_printer: make usb_gadget_class a static const structure USB: mon: make mon_bin_class a static const structure USB: gadget: udc: core: make udc_class a static const structure USB: roles: make role_class a static const structure dt-bindings: usb: dwc3: Add interrupt-names property support for wakeup interrupt dt-bindings: usb: Add StarFive JH7110 USB controller dt-bindings: usb: dwc3: Add IPQ9574 compatible usb: cdns2: Fix spelling mistake in a trace message "Wakupe" -> "Wakeup" ...
2023-06-23usb: dwc3: gadget: Propagate core init errors to UDC during pullupKrishna Kurapati
In scenarios where pullup relies on resume (get sync) to initialize the controller and set the run stop bit, then core_init is followed by gadget_resume which will eventually set run stop bit. But in cases where the core_init fails, the return value is not sent back to udc appropriately. So according to UDC the controller has started but in reality we never set the run stop bit. On systems like Android, there are uevents sent to HAL depending on whether the configfs_bind / configfs_disconnect were invoked. In the above mentioned scnenario, if the core init fails, the run stop won't be set and the cable plug-out won't result in generation of any disconnect event and userspace would never get any uevent regarding cable plug out and we never call pullup(0) again. Furthermore none of the next Plug-In/Plug-Out's would be known to configfs. Return back the appropriate result to UDC to let the userspace/ configfs know that the pullup failed so they can take appropriate action. Fixes: 77adb8bdf422 ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded") Cc: stable <stable@kernel.org> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Message-ID: <20230618120949.14868-1-quic_kriskura@quicinc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-13usb: dwc3: gadget: Reset num TRBs before giving back the requestElson Roy Serrao
Consider a scenario where cable disconnect happens when there is an active usb reqest queued to the UDC. As part of the disconnect we would issue an end transfer with no interrupt-on-completion before giving back this request. Since we are giving back the request without skipping TRBs the num_trbs field of dwc3_request still holds the stale value previously used. Function drivers re-use same request for a given bind-unbind session and hence their dwc3_request context gets preserved across cable disconnect/connect. When such a request gets re-queued after cable connect, we would increase the num_trbs field on top of the previous stale value thus incorrectly representing the number of TRBs used. Fix this by resetting num_trbs field before giving back the request. Fixes: 09fe1f8d7e2f ("usb: dwc3: gadget: track number of TRBs per request") Cc: stable <stable@kernel.org> Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Message-ID: <1685654850-8468-1-git-send-email-quic_eserrao@quicinc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-28USB: fix up merge of 6.4-rc4 into usb-nextRoger Quadros
The merge of 6.4-rc4 got the changes in drivers/usb/dwc3/gadget.c completely incorrect, so fix it up properly. Link: https://lore.kernel.org/r/f604f836-7858-6140-4ec1-9ba95cba6991@kernel.org Fixes: 7e530d32a365 ("Merge 6.4-rc4 into usb-next") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-28Merge 6.4-rc4 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here and this resolves merge conflicts in: drivers/usb/dwc3/gadget.c drivers/usb/gadget/udc/core.c Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-13usb: dwc3: gadget: Bail out in pullup if soft reset timeout happensKrishna Kurapati
If the core soft reset timeout happens, avoid setting up event buffers and starting gadget as the writes to these registers may not reflect when in reset and setting the run stop bit can lead the controller to access wrong event buffer address resulting in a crash. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20230510075252.31023-2-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-13usb: dwc3: Add error logs for unknown endpoint eventsRoy Luo
In cases where the controller somehow fails to write to event buffer memory (e.g. due to incorrect MMU config), the driver would receive all-zero dwc3 events. However, the abnormal event is silently dropped as a regular ep0out event. Add error logs when an unknown endpoint event is received to highlight the anomaly. Signed-off-by: Roy Luo <royluo@google.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20230504000129.728316-1-royluo@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-13usb: dwc3: fix gadget mode suspend interrupt handler issueLinyu Yuan
When work in gadget mode, currently driver doesn't update software level link_state correctly as link state change event is not enabled for most devices, in function dwc3_gadget_suspend_interrupt(), it will only pass suspend event to UDC core when software level link state changes, so when interrupt generated in sequences of suspend -> reset -> conndone -> suspend, link state is not updated during reset and conndone, so second suspend interrupt event will not pass to UDC core. Remove link_state compare in dwc3_gadget_suspend_interrupt() and add a suspended flag to replace the compare function. Fixes: 799e9dc82968 ("usb: dwc3: gadget: conditionally disable Link State change events") Cc: stable <stable@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com> Link: https://lore.kernel.org/r/20230512004524.31950-1-quic_linyyuan@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-13usb: dwc3: gadget: Improve dwc3_gadget_suspend() and dwc3_gadget_resume()Roger Quadros
Prevent -ETIMEDOUT error on .suspend(). e.g. If gadget driver is loaded and we are connected to a USB host, all transfers must be stopped before stopping the controller else we will not get a clean stop i.e. dwc3_gadget_run_stop() will take several seconds to complete and will return -ETIMEDOUT. Handle error cases properly in dwc3_gadget_suspend(). Simplify dwc3_gadget_resume() by using the introduced helper function. Fixes: 9f8a67b65a49 ("usb: dwc3: gadget: fix gadget suspend/resume") Cc: stable@vger.kernel.org Suggested-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Roger Quadros <rogerq@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20230503110048.30617-1-rogerq@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-21usb: dwc3: gadget: Refactor EP0 forced stall/restart into a separate APIWesley Cheng
Several sequences utilize the same routine for forcing the control endpoint back into the SETUP phase. This is required, because those operations need to ensure that EP0 is back in the default state. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20230420212759.29429-3-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-21usb: dwc3: gadget: Execute gadget stop after halting the controllerWesley Cheng
Do not call gadget stop until the poll for controller halt is completed. DEVTEN is cleared as part of gadget stop, so the intention to allow ep0 events to continue while waiting for controller halt is not happening. Fixes: c96683798e27 ("usb: dwc3: ep0: Don't prepare beyond Setup stage") Cc: stable@vger.kernel.org Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20230420212759.29429-2-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20usb: dwc3: gadget: Stall and restart EP0 if host is unresponsiveWesley Cheng
It was observed that there are hosts that may complete pending SETUP transactions before the stop active transfers and controller halt occurs, leading to lingering endxfer commands on DEPs on subsequent pullup/gadget start iterations. dwc3_gadget_ep_disable name=ep8in flags=0x3009 direction=1 dwc3_gadget_ep_disable name=ep4in flags=1 direction=1 dwc3_gadget_ep_disable name=ep3out flags=1 direction=0 usb_gadget_disconnect deactivated=0 connected=0 ret=0 The sequence shows that the USB gadget disconnect (dwc3_gadget_pullup(0)) routine completed successfully, allowing for the USB gadget to proceed with a USB gadget connect. However, if this occurs the system runs into an issue where: BUG: spinlock already unlocked on CPU spin_bug+0x0 dwc3_remove_requests+0x278 dwc3_ep0_out_start+0xb0 __dwc3_gadget_start+0x25c This is due to the pending endxfers, leading to gadget start (w/o lock held) to execute the remove requests, which will unlock the dwc3 spinlock as part of giveback. To mitigate this, resolve the pending endxfers on the pullup disable path by re-locating the SETUP phase check after stop active transfers, since that is where the DWC3_EP_DELAY_STOP is potentially set. This also allows for handling of a host that may be unresponsive by using the completion timeout to trigger the stall and restart for EP0. Fixes: c96683798e27 ("usb: dwc3: ep0: Don't prepare beyond Setup stage") Cc: stable@vger.kernel.org Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20230413195742.11821-2-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20USB: dwc3: gadget: drop dead hibernation codeJohan Hovold
The hibernation code is broken and has never been enabled in mainline and should thus be dropped. Remove the hibernation bits from the gadget code, which effectively reverts commits e1dadd3b0f27 ("usb: dwc3: workaround: bogus hibernation events") and 7b2a0368bbc9 ("usb: dwc3: gadget: set KEEP_CONNECT in case of hibernation") except for the spurious interrupt warning. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230404072524.19014-5-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-29usb: dwc3: Add function suspend and function wakeup supportElson Roy Serrao
USB host sends function suspend and function resume notifications to the interface through SET_FEATURE/CLEAR_FEATURE setup packets. Add support to handle these packets by delegating the requests to composite layer. Also add support to handle function wake notification requests to exit from function suspend state. Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Elson Roy Serrao <quic_eserrao@quicinc.com> Link: https://lore.kernel.org/r/1679694482-16430-5-git-send-email-quic_eserrao@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-07-15 17:27:12 +0000