Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1948885imu; Tue, 6 Nov 2018 06:51:56 -0800 (PST) X-Google-Smtp-Source: AJdET5eAOOoss+Q0ZJsvrk7V7fxZVZu9FxkKzjdIB1W/fqjBJOVr2Xj+r6mH+ApV5ocDf+FX5iDI X-Received: by 2002:a17:902:bb88:: with SMTP id m8-v6mr25782152pls.120.1541515916911; Tue, 06 Nov 2018 06:51:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541515916; cv=none; d=google.com; s=arc-20160816; b=rswDYfqM5M7fTZyv4TETk7i59Bc7LChleTkqwYjSPzT0jf3SQzzB7lL5StYL0c0Wh7 ETuG++dbzoIHLVAD93v/NLmjdvc2Nj+YO7d5O2PJzRQ2+Ub539PKggnRyGn7eAMOL3DI RpIn93xb25l1/3pqbwK+FxnINxom9MzBk1hwC7LqXEBM7KxRnKxp938Ru/lhq6I1H73n KtHqEfIF05IuBzjTDUXJF1KgkMTLLZi6FKPL00vLCfGfcLAHUheoJOhNy33khbppxE9E gH+LO7J2bbTfIv45PKuukCdEf5Qc34Hlv9/gozelUsZxdZxZoWX8RjLsXvLURKyAWoJe J8dw== 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=0YaeE1qW7ciaNlMa6ineSQNt4WzwikjVx4KQP2t7Gkc=; b=JOU8V+KQMzWm1Pc9siUFiGFkso88ID+Jo1p4AR5LDcc1/HDgIdRV/dLmIUEXweC0LP /tvZ8Srp2O1nr+5/kvrvIb6VF0XMNyK9ePgc/92pcatf3aoUC1DRosMA9AFCiBu9jSCg Ev5eWrKT+eMHQcB53LGmNkkoFpdFf91VsExOo0/GcCczBRMD4lGsrHDbIjzqfaLnIpZF dAnb/JbKsvtokSfh8mQiclHe7ziFZ5JkEuYgng+mOLJcIAkcB36lRmaxsvKQ/Q2rlkW0 tcgehb0tgAVNSvFyNV/D5WWaIG6NTfeTjx0KF3Bb/H5U1VOLZ1bpGsvMF40YZKNC12hj ONug== 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 e3-v6si46525249pgg.530.2018.11.06.06.51.35; Tue, 06 Nov 2018 06:51:56 -0800 (PST) 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 S2388905AbeKGAQl (ORCPT + 99 others); Tue, 6 Nov 2018 19:16:41 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:36610 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S2388428AbeKGAQl (ORCPT ); Tue, 6 Nov 2018 19:16:41 -0500 Received: (qmail 2264 invoked by uid 2102); 6 Nov 2018 09:51:06 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Nov 2018 09:51:06 -0500 Date: Tue, 6 Nov 2018 09:51:06 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Felipe Balbi cc: Laurent Pinchart , Paul Elder , Bin Liu , , , , , Subject: Re: [PATCH 4/6] usb: gadget: add functions to signal udc driver to delay status stage In-Reply-To: <87d0riv4jw.fsf@linux.intel.com> 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 Tue, 6 Nov 2018, Felipe Balbi wrote: > DATA stage always depends on a usb_ep_queue() from gadget driver. So > it's always "delayed" in that sense. However, it's conceivable that some UDC drivers might behave differently depending on whether the usb_ep_queue call occurs within the setup callback or after that callback returns. They _shouldn't_, but they might. > it avoids all the special cases. UDC drivers can implement a single > handling for struct usb_request. We could do away with special return > values and so on... It's not quite so simple, because the UDC driver will need to keep track of whether a request queued on ep0 should be in the IN or the OUT direction. (Maybe they have to do this already, I don't know.) > > request and the UDC would then need to check whether that request corresponds > > to a status stage and process it accordingly. A new operation specific to this > > no, it wouldn't. UDC would have to check the size of request, that's > all: > > if (r->length == 0) > special_zlp_handling(); > else > regular_non_zlp_handling(); Checking the length isn't enough. A data stage can have 0 length. > But we don't need to care about special return values and the like. We > don't even need to care (from UDC perspective) if we're dealing with > 2-stage or 3-stage control transfers (well, dwc3 needs to care because > of different TRB types that needs to be used, but that's another story) No, we do need to care because of the direction issue. > > There's also the fact that requests can specify a completion handler, but only > > the data stage request would see its completion handler called (unless we > > require UDCs to call completion requests at the completion of the status > > stage, but I'm not sure that all UDCs can report the event to the driver, and > > that would likely be useless as nobody needs that feature). > > you still wanna know if the host actually processed your status > stage. udc-core can (and should) provide a generic status stage > completion function which, at a minimum, aids with some tracepoints. Helping with tracepoints is fine. However, I don't think function drivers really need to know whether the status stage was processed by the host. Can you point out any examples where such information would be useful? > One way to satisfy what you want, with what I want is to have UDC core > implement something like below: > > int usb_ep_start_status_stage(struct usb_gadget *g) > { > return usb_ep_queue(g->ep0, &g->ep0_status_request); > } > > special function for you, usb_ep_queue() for me :-p Sure, this is one of the options Laurent and I have discussed. > >> (But it does involve a > >> race in cases where the host gets tired of waiting and issues another > >> SETUP packet before the processing of the first transfer is finished.) > > Host would stall first in that case. I don't follow. Suppose the host sends a SETUP packet for an IN transfer, but the gadget takes so long to send the IN data back that the host times out. So then the host sends a SETUP packet for a new transfer. No stalls. (Besides, hosts never send STALL packets anyway. Only peripherals do.) > Driver is already required to > handle stalls for several other conditions. If thehre are bugs in that > area, I'd prefer catching them. > > To simplify function drivers, do you think the above proposal of adding a flag > > to the (data stage) request to request an automatic transition to the status > > stage is a good idea ? We could even possibly invert the logic and transition > > no, I don't think so. Making the status phase always explicit is far > better. UDCs won't have to check flags, or act on magic return > values. It just won't do anything until a request is queued. I don't agree. This would be a simple test in a localized area (the completion callback for control requests). It could even be implemented by a library routine; the UDC driver would simply have to call this routine immediately after invoking the callback. Alan Stern