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@xxxxxxxxxxx>
---
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
