Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1967143imm; Thu, 18 Oct 2018 07:08:19 -0700 (PDT) X-Google-Smtp-Source: ACcGV61MpxPHfBP08/Y2sUKnBJ98wE2l2Qjc2NBOpBSy5H0NfCxjmLaw5yIk1vyMxPvWQu9TdiD8 X-Received: by 2002:a63:8c4:: with SMTP id 187-v6mr28724567pgi.396.1539871699378; Thu, 18 Oct 2018 07:08:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539871699; cv=none; d=google.com; s=arc-20160816; b=XbtzkgP+CnVsWA01gv03YDCB3H8LxLjC4DgDziv1umNMHcT2ZlXVr52JxQO2VQG3Rn Ji5v9rWQtzshgluRf1fievmir16HojysvVgMsQO615wvOzle2eYqRywAJ7VStYsN0VLm j6Ihcl114ajCnETn9WgD5HUgCe3PW8ItTxr1ZkPtcJOr61ssqyhRLyxSW6o1s6+i4Qdq rRP89k6vG/thdSLXruBaeVAQdfS+Ftc1Wf33v8GBdl2ylhFoAifkjujqtGUS1miH1P3J hhhjvFEjpTnco8nnM7QMEjuOerwwxSwgMPtegPd8bV45heSXgRHSRGQ93cpkgxCha3U1 41RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=PcKtbKibQyDDLb+3lr/ZfyrmNvwufNkWaj69DuiTXZA=; b=F6ASqwjPpNzXXiToFfrki2gBei/iCpMzVeR3CgragvU3r0P+MN3grGHCkwKIV+JCZM gYsoG/HVG+xe5q8D7B54anhvZT/5mDnvruCvTf9XmnuMEheVxw0VLznv9y8/nhtMNRkA YENF6bz/OynGVCAS/YrWHSVQI3wGXzB5pGD64tZ/kd4XdsHPycpZqigE0t/vo7EMZKll 0xEEfEOCwlgdH/t1uKdykOCFbnKQjufRMrOqtwo28KO5BSnPh8UBoo7rDxJNrl7SBtrl ChiYp1aWmQpFWAO5ZDOYibTBuEDcld9W8dJM2yRurmaeGPBoQXrYNl+pw4N2IbtYYpHL SnjQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k20-v6si21019238pgm.574.2018.10.18.07.08.02; Thu, 18 Oct 2018 07:08:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728223AbeJRWIs (ORCPT + 99 others); Thu, 18 Oct 2018 18:08:48 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:45852 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1727062AbeJRWIs (ORCPT ); Thu, 18 Oct 2018 18:08:48 -0400 Received: (qmail 1612 invoked by uid 2102); 18 Oct 2018 10:07:36 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Oct 2018 10:07:36 -0400 Date: Thu, 18 Oct 2018 10:07:36 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Laurent Pinchart cc: Bin Liu , Paul Elder , , , , , , Subject: Re: [PATCH 4/6] usb: gadget: add functions to signal udc driver to delay status stage In-Reply-To: <3055233.Lvy0NcWSZ5@avalon> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 18 Oct 2018, Laurent Pinchart wrote: > Hi Bin, > > On Thursday, 11 October 2018 19:10:21 EEST Bin Liu wrote: > > On Tue, Oct 09, 2018 at 10:49:01PM -0400, Paul Elder wrote: > > > A usb gadget function driver may or may not want to delay the status > > > stage of a control OUT request. An instance it might want to is to > > > asynchronously validate the data of a class-specific request. > > > > > > Add a function usb_ep_delay_status to allow function drivers to choose > > > to delay the status stage in the request completion handler. The UDC > > > should then check the usb_ep->delayed_status flag and act accordingly to > > > delay the status stage. > > > > > > Also add a function usb_ep_send_response as a wrapper for > > > usb_ep->ops->send_response, whose prototype is added as well. This > > > function should be called by function drivers to tell the UDC what to > > > reply in the status stage that it has requested to be delayed. > > > > > > Signed-off-by: Paul Elder > > > Reviewed-by: Laurent Pinchart > > > --- > > > > > > drivers/usb/gadget/udc/core.c | 35 +++++++++++++++++++++++++++++++++++ > > > include/linux/usb/gadget.h | 11 +++++++++++ > > > 2 files changed, 46 insertions(+) > > > > > > diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c > > > index af88b48c1cea..1ec5ce6b43cd 100644 > > > --- a/drivers/usb/gadget/udc/core.c > > > +++ b/drivers/usb/gadget/udc/core.c > > > @@ -443,6 +443,41 @@ void usb_ep_fifo_flush(struct usb_ep *ep) > > > } > > > EXPORT_SYMBOL_GPL(usb_ep_fifo_flush); > > > > > > +/** > > > + * usb_ep_ep_delay_status - set delay_status flag > > > + * @ep: the endpoint whose delay_status flag is being set > > > + * > > > + * This function instructs the UDC to delay the status stage of a control > > > + * request. It can only be called from the request completion handler of > > > a > > > + * control request. > > > + */ > > > +void usb_ep_delay_status(struct usb_ep *ep) > > > +{ > > > + ep->delayed_status = true; > > > +} > > > +EXPORT_SYMBOL_GPL(usb_ep_delay_status); > > > > Is usb_ep_set_delay_status() better? I thought it implies get/return > > action if a verb is missing in the function name. > > For what it's worth, I understand the function name as "delay the status > stage", with "delay" being a verb. Maybe the short description could be > updated accordingly. Is there a reason for adding a new function for this? This is exactly what the USB_GADGET_DELAYED_STATUS return value from the setup callback is meant for (and it is already used by some gadget drivers). Is it a question of when the gadget driver learns that it will need to delay the status stage? If that's the case, why not always return USB_GADGET_DELAYED_STATUS from the setup callback? Then instead of calling usb_ep_delay_status() when a delay is needed, you could queue the status request when a delay isn't needed. As a more general solution, Felipe has said that a UDC driver should _never_ carry out the status stage transaction until the gadget driver has told it to do so. Then there would be no need for any sort of delay indicator. (But implementing this would require significant changes to a bunch of different drivers...) Alan Stern