kernel/drivers/usb/dwc3/ep0.c, branch linux-6.9.y

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

2024-04-18T14:42:21Z

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: gadget: Rewrite endpoint allocation flow

2024-02-17T15:43:09Z

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

usb: dwc: ep0: Update request status in dwc3_ep0_stall_restart

2024-01-04T14:57:45Z

Current implementation blocks the running operations when Plug-out and Plug-In is performed continuously, process gets stuck in dwc3_thread_interrupt(). Code Flow: CPU1 ->Gadget_start ->dwc3_interrupt ->dwc3_thread_interrupt ->dwc3_process_event_buf ->dwc3_process_event_entry ->dwc3_endpoint_interrupt ->dwc3_ep0_interrupt ->dwc3_ep0_inspect_setup ->dwc3_ep0_stall_and_restart By this time if pending_list is not empty, it will get the next request on the given list and calls dwc3_gadget_giveback which will unmap request and call its complete() callback to notify upper layers that it has completed. Currently dwc3_gadget_giveback status is set to -ECONNRESET, whereas it should be -ESHUTDOWN based on condition if not dwc->connected is true. Cc: Fixes: d742220b3577 ("usb: dwc3: ep0: giveback requests on stall_and_restart") Signed-off-by: Uttkarsh Aggarwal Link: https://lore.kernel.org/r/20231222094704.20276-1-quic_uaggarwa@quicinc.com Signed-off-by: Greg Kroah-Hartman

usb: dwc3: Add error logs for unknown endpoint events

2023-05-13T09:57:30Z

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 Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20230504000129.728316-1-royluo@google.com Signed-off-by: Greg Kroah-Hartman

usb: dwc3: Add function suspend and function wakeup support

2023-03-29T08:27:01Z

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 Signed-off-by: Elson Roy Serrao Link: https://lore.kernel.org/r/1679694482-16430-5-git-send-email-quic_eserrao@quicinc.com Signed-off-by: Greg Kroah-Hartman

usb: dwc3: Add remote wakeup handling

2023-03-29T08:27:01Z

An usb device can initate a remote wakeup and bring the link out of suspend as dictated by the DEVICE_REMOTE_WAKEUP feature selector. Add support to handle this packet and set the remote wakeup capability. Some hosts may take longer time to initiate the resume signaling after device triggers a remote wakeup. So add async support to the wakeup API by enabling link status change events. Acked-by: Thinh Nguyen Signed-off-by: Elson Roy Serrao Link: https://lore.kernel.org/r/1679694482-16430-3-git-send-email-quic_eserrao@quicinc.com Signed-off-by: Greg Kroah-Hartman

usb: dwc3: Avoid unmapping USB requests if endxfer is not complete

2022-09-07T14:26:26Z

If DWC3_EP_DELAYED_STOP is set during stop active transfers, then do not continue attempting to unmap request buffers during dwc3_remove_requests(). This can lead to SMMU faults, as the controller has not stopped the processing of the TRB. Defer this sequence to the EP0 out start, which ensures that there are no pending SETUP transactions before issuing the endxfer. Reviewed-by: Thinh Nguyen Signed-off-by: Wesley Cheng Link: https://lore.kernel.org/r/20220901193625.8727-2-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman

usb: dwc3: Do not service EP0 and conndone events if soft disconnected

2022-08-31T07:07:53Z

There are some operations that need to be ignored if there is a soft disconnect in progress. This is to avoid having a pending EP0 transfer in progress while attempting to stop active transfers and halting the controller. There were several instances seen where a soft disconnect was able to occur during early link negotiation, i.e. bus reset/conndone, which leads to the conndone handler re-configuring EPs while attempting to halt the controller, as DEP flags are cleared as part of the soft disconnect path. ep0out: cmd 'Start New Configuration' ep0out: cmd 'Set Endpoint Transfer Resource' ep0in: cmd 'Set Endpoint Transfer Resource' ep1out: cmd 'Set Endpoint Transfer Resource' ... event (00030601): Suspend [U3] event (00000101): Reset [U0] ep0out: req ffffff87e5c9e100 length 0/0 zsI ==> 0 event (00000201): Connection Done [U0] ep0out: cmd 'Start New Configuration' ep0out: cmd 'Set Endpoint Transfer Resource' In addition, if a soft disconnect occurs, EP0 events are still allowed to process, however, it will stall/restart during the SETUP phase. The host is still able to query for the DATA phase, leading to a xfernotready(DATA) event. Since none of the SETUP transfer parameters are populated, the xfernotready is treated as a "wrong direction" error, leading to a duplicate stall/restart routine. Add the proper softconnect/connected checks in sequences that are potentially involved during soft disconnect processing. Reviewed-by: Thinh Nguyen Signed-off-by: Wesley Cheng Link: https://lore.kernel.org/r/20220817182359.13550-2-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman

usb: dwc3: ep0: Properly handle setup_packet_pending scenario in data stage

2022-07-14T14:09:43Z

During a 3 stage SETUP transfer, if the host sends another SETUP token before completing the status phase, it signifies that the host has aborted the current control transfer. Currently, if a setup_packet_pending is received, there are no subsequent calls to dwc3_ep0_out_start() to fetch the new SETUP packet. This leads to a stall on EP0, as host does not expect another STATUS phase as it has aborted the current transfer. Fix this issue by explicitly stalling and restarting EP0, as well as resetting the trb_enqueue indexes. (without this, there is a chance the SETUP TRB is set up on trb_endqueue == 1) Signed-off-by: Wesley Cheng Link: https://lore.kernel.org/r/20220712014403.2977-1-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman

usb: dwc3: Fix a repeated word checkpatch warning

2022-06-12T04:49:47Z

Fixes a repeated word checkpatch warning in ep0.c by removing the repeated 'only' word. Signed-off-by: Kushagra Verma Link: https://lore.kernel.org/r/HK0PR01MB2801996E815208393170010FF8D39@HK0PR01MB2801.apcprd01.prod.exchangelabs.com Signed-off-by: Greg Kroah-Hartman