Hi Alan,
On 12/24/2022 7:29 AM, Alan Stern wrote:
On Fri, Dec 23, 2022 at 03:31:52PM -0800, Wesley Cheng wrote:
For USB HCDs that can support multiple USB interrupters, expose functions that class drivers can utilize for setting up secondary interrupters. Class drivers can pass this information to its respective clients, i.e. a dedicated DSP.
Signed-off-by: Wesley Cheng quic_wcheng@quicinc.com
drivers/usb/core/hcd.c | 86 +++++++++++++++++++++++++++++++++++++++++ include/linux/usb.h | 7 ++++ include/linux/usb/hcd.h | 16 +++++++- 3 files changed, 108 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 8300baedafd2..90ead90faf1d 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c
+/**
- usb_hcd_stop_endpoint - Halt USB EP transfers
- @udev: usb device
- @ep: usb ep to stop
- Stop pending transfers on a specific USB endpoint.
- **/
+int usb_hcd_stop_endpoint(struct usb_device *udev,
struct usb_host_endpoint *ep)+{
- struct usb_hcd *hcd = bus_to_hcd(udev->bus);
- int ret = 0;
- if (hcd->driver->stop_endpoint)
ret = hcd->driver->stop_endpoint(hcd, udev, ep);- return ret;
+} +EXPORT_SYMBOL_GPL(usb_hcd_stop_endpoint);
You know, there already is a function that does this. It's named usb_hcd_flush_endpoint(). No need to add another function that does the same thing.
Thanks for the suggestion and review.
Hmmm...maybe I should change the name of the API then to avoid the confusion. Yes, usb_hcd_flush_endpoint() does ensure that URBs submitted to the EP are stopped. However, with this offloading concept, we aren't actually submitting URBs from the main processor, so the ep->urb_list will be empty.
This means the usb_hcd_flush_endpoint() API won't actually do anything. What we need is to ensure that we send a XHCI stop ep command to the controller.
Thanks Wesley Cheng