[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y6xd1c3s2XPpOqfi@rowland.harvard.edu>
Date: Wed, 28 Dec 2022 10:16:37 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Oliver Neukum <oneukum@...e.com>
Cc: Wesley Cheng <quic_wcheng@...cinc.com>,
srinivas.kandagatla@...aro.org, mathias.nyman@...el.com,
perex@...ex.cz, broonie@...nel.org, lgirdwood@...il.com,
andersson@...nel.org, krzysztof.kozlowski+dt@...aro.org,
gregkh@...uxfoundation.org, Thinh.Nguyen@...opsys.com,
bgoswami@...cinc.com, tiwai@...e.com, robh+dt@...nel.org,
agross@...nel.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, alsa-devel@...a-project.org,
devicetree@...r.kernel.org, linux-usb@...r.kernel.org,
quic_jackp@...cinc.com, quic_plai@...cinc.com
Subject: Re: [RFC PATCH 06/14] usb: core: hcd: Introduce USB HCD APIs for
interrupter management
On Wed, Dec 28, 2022 at 09:59:03AM +0100, Oliver Neukum wrote:
>
>
> On 27.12.22 22:07, Wesley Cheng wrote:
>
> >
> > 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.
>
> That is a concept specific to XHCI, yet you are adding a generic
> API. The namin should reflect that. usb_quiesce_endpoint() ?
Or even xhci_send_stop_ep_cmd(), which is what the routine is intended
to do.
Alan Stern
Powered by blists - more mailing lists