[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bf1011a8-c746-c465-f161-f0293409d922@suse.com>
Date: Wed, 28 Dec 2022 09:59:03 +0100
From: Oliver Neukum <oneukum@...e.com>
To: Wesley Cheng <quic_wcheng@...cinc.com>,
Alan Stern <stern@...land.harvard.edu>
Cc: 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 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() ?
Regards
Oliver
Powered by blists - more mailing lists