From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [4/6] usb: gadget: add functions to signal udc driver to delay status stage From: Felipe Balbi Message-Id: <87tvkttm2w.fsf@linux.intel.com> Date: Wed, 07 Nov 2018 08:53:43 +0200 To: Alan Stern Cc: Laurent Pinchart , Paul Elder , Bin Liu , kieran.bingham@ideasonboard.com, gregkh@linuxfoundation.org, USB list , Kernel development list , rogerq@ti.com List-ID: SGksCgpBbGFuIFN0ZXJuIDxzdGVybkByb3dsYW5kLmhhcnZhcmQuZWR1PiB3cml0ZXM6Cj4+IEFs YW4gU3Rlcm4gPHN0ZXJuQHJvd2xhbmQuaGFydmFyZC5lZHU+IHdyaXRlczoKPj4gPiBUaGVyZSdz IGEgc2ltaWxhciByYWNlIGF0IHRoZSBoYXJkd2FyZSBsZXZlbC4gIFdoYXQgaGFwcGVucyBpZiB0 aGUKPj4gPiBjb250cm9sbGVyIHJlY2VpdmVzIGEgbmV3IFNFVFVQIHBhY2tldCBhbmQgY29uY3Vy cmVudGx5IHRoZSBkcml2ZXIgaXMKPj4gPiBzZXR0aW5nIHVwIHRoZSBjb250cm9sbGVyIHJlZ2lz dGVycyBmb3IgYSByZXNwb25zZSB0byBhbiBlYXJsaWVyCj4+ID4gU0VUVVA/ICBJIGRvbid0IGtu b3cgaG93IHJlYWwgY29udHJvbGxlcnMgaGFuZGxlIHRoaXMuCj4+IAo+PiBUaGF0J3MgSFcgaW1w bGVtZW50YXRpb24gZGV0YWlsLiBEV0MzLCBmb3IgaW5zdGFuY2UsIHdpbGwgaWdub3JlIHRoZQo+ PiBUUkJzIGFuZCByZXR1cm4gbWUgdGhlIHN0YXR1cyAic2V0dXAgcGFja2V0IHBlbmRpbmciLiBU aGVuIEkganVzdCBzdGFydAo+PiBhIG5ldyBTRVRVUCBUUkIuCj4KPiBZb3UgbWVhbiB0aGUgVURD IGhhcmR3YXJlIHNldHMgYSAic2V0dXAgcGVuZGluZyIgZmxhZyBpbiBzb21lIHJlZ2lzdGVyLAo+ IGFuZCB0aGVuIGlnbm9yZXMgYW55IGF0dGVtcHRzIHRvIGRvIGFueXRoaW5nIHdpdGggZXAwIHVu dGlsIHRoZSBkcml2ZXIKPiBjbGVhcnMgdGhpcyBmbGFnPwoKWWVzLCBleGNlcHQgdGhhdCB0aGUg ImZsYWciIGlzIGEgc3RhdHVzIG9uIHRoZSBUUkIgaXRzZWxmIChUUkIgaXMgZHdjMydzCkRNQSB0 cmFuc2ZlciBkZXNjcmlwdG9yKS4KCj4+ID4gWW91IG1lYW4sIHNob3VsZCB3ZSBhbGxvdyBmdW5j dGlvbiBkcml2ZXJzIHRvIHF1ZXVlIHRoZSBkYXRhLXN0YWdlCj4+ID4gcmVxdWVzdCBhZnRlciB0 aGUgc2V0dXAgaGFuZGxlciBoYXMgcmV0dXJuZWQ/ICBJIGRvbid0IHNlZSBhbnkgcmVhc29uCj4+ IAo+PiB0aGF0J3MgYWxyZWFkeSBkb25lOgo+PiAKPj4gc3RhdGljIHZvaWQgZHdjM19lcDBfeGZl cl9jb21wbGV0ZShzdHJ1Y3QgZHdjMyAqZHdjLAo+PiAJCQljb25zdCBzdHJ1Y3QgZHdjM19ldmVu dF9kZXBldnQgKmV2ZW50KQo+PiB7Cj4+IAlzdHJ1Y3QgZHdjM19lcAkJKmRlcCA9IGR3Yy0+ZXBz W2V2ZW50LT5lbmRwb2ludF9udW1iZXJdOwo+PiAKPj4gCWRlcC0+ZmxhZ3MgJj0gfkRXQzNfRVBf VFJBTlNGRVJfU1RBUlRFRDsKPj4gCWRlcC0+cmVzb3VyY2VfaW5kZXggPSAwOwo+PiAJZHdjLT5z ZXR1cF9wYWNrZXRfcGVuZGluZyA9IGZhbHNlOwo+PiAKPj4gCXN3aXRjaCAoZHdjLT5lcDBzdGF0 ZSkgewo+PiAJY2FzZSBFUDBfU0VUVVBfUEhBU0U6Cj4+IAkJZHdjM19lcDBfaW5zcGVjdF9zZXR1 cChkd2MsIGV2ZW50KTsKPj4gCQlicmVhazsKPj4gWy4uLl0KPj4gfQo+Cj4gLi4uCj4KPiBZb3Ug bWVhbiwgaXQncyBhbHJlYWR5IGRvbmUgaW4gRFdDMy4gIFdoYXQgYWJvdXQgb3RoZXIgVURDIGRy aXZlcnM/CgppZiB0aGV5J3JlIG5vdCBpbXBsZW1lbnRpbmcgdGhpcyBwb3NzaWJpbGl0eSwgdGhl biB0aGF0J3MgYSBidWcgb24KdGhvc2UgVURDIGRyaXZlcnMgOikKCj4+ID4gd2h5IG5vdC4gIEFm dGVyIGFsbCwgc29tZSBkcml2ZXJzIG1heSByZXF1aXJlIHRoaXMuICBMaWtld2lzZSBmb3IgdGhl IAo+PiA+IGRhdGEgc3RhZ2Ugb2YgYSBjb250cm9sLUlOLgo+PiA+Cj4+ID4gQW5vdGhlciB0aGlu ZyB3ZSBzaG91bGQgZG8gaXMgZ2l2ZSBmdW5jdGlvbiBkcml2ZXJzIGEgd2F5IHRvIHNlbmQgYQo+ PiA+IFNUQUxMIHJlc3BvbnNlIGZvciB0aGUgc3RhdHVzIHN0YWdlLiAgQ3VycmVudGx5IHRoZXJl J3Mgbm8gd2F5IHRvIGRvCj4+ID4gaXQsIGlmIGEgZGF0YSBzdGFnZSBpcyBwcmVzZW50Lgo+PiAK Pj4gU3RhdHVzIHN0YWdlIGNhbiBvbmx5IGJlIHN0YWxsZWQgaWYgaG9zdCB0cmllcyB0byBtb3Zl IGRhdGEgb24gdGhlIHdyb25nCj4+IGRpcmVjdGlvbi4KPgo+IFRoZSBVU0ItMiBzcGVjIGRpc2Fn cmVlcy4gIFNlZSBUYWJsZSA4LTcgaW4gc2VjdGlvbiA4LjUuMy4xIGFuZCB0aGUKPiBmb2xsb3dp bmcgcGFyYWdyYXBocy4gIChBbHRob3VnaCwgSSBjYW4ndCBzZWUgd2h5IGEgZnVuY3Rpb24gd291 bGQgZXZlcgo+IGZhaWwgdG8gY29tcGxldGUgdGhlIGNvbW1hbmQgc2VxdWVuY2UgZm9yIGEgY29u dHJvbC1JTiB0cmFuc2ZlciBhZnRlcgo+IHRoZSBkYXRhIGhhZCBhbHJlYWR5IGJlZW4gc2VudC4p CgpJIGNhbid0IHNlZSBob3cgd2UgY291bGQgZXZlciBTVEFMTCBhZnRlciByZXR1cm5pbmcgdGhl IGRhdGEgcmVxdWVzdGVkCmJ5IHRoZSBob3N0LiBTZWVtcyBsaWtlIHRoYXQgd2Fzbid0IHdlbGwg dGhvdWdodCBvdXQuCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52009C0044C for ; Wed, 7 Nov 2018 06:53:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1D49A20862 for ; Wed, 7 Nov 2018 06:53:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D49A20862 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729969AbeKGQWu (ORCPT ); Wed, 7 Nov 2018 11:22:50 -0500 Received: from mga12.intel.com ([192.55.52.136]:44374 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726194AbeKGQWu (ORCPT ); Wed, 7 Nov 2018 11:22:50 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 22:53:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,474,1534834800"; d="asc'?scan'208";a="247663066" Received: from pipin.fi.intel.com (HELO localhost) ([10.237.72.128]) by orsmga004.jf.intel.com with ESMTP; 06 Nov 2018 22:53:47 -0800 From: Felipe Balbi To: Alan Stern Cc: Laurent Pinchart , Paul Elder , Bin Liu , kieran.bingham@ideasonboard.com, gregkh@linuxfoundation.org, USB list , Kernel development list , rogerq@ti.com Subject: Re: [PATCH 4/6] usb: gadget: add functions to signal udc driver to delay status stage In-Reply-To: References: Date: Wed, 07 Nov 2018 08:53:43 +0200 Message-ID: <87tvkttm2w.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Alan Stern writes: >> Alan Stern writes: >> > There's a similar race at the hardware level. What happens if the >> > controller receives a new SETUP packet and concurrently the driver is >> > setting up the controller registers for a response to an earlier >> > SETUP? I don't know how real controllers handle this. >>=20 >> That's HW implementation detail. DWC3, for instance, will ignore the >> TRBs and return me the status "setup packet pending". Then I just start >> a new SETUP TRB. > > You mean the UDC hardware sets a "setup pending" flag in some register, > and then ignores any attempts to do anything with ep0 until the driver > clears this flag? Yes, except that the "flag" is a status on the TRB itself (TRB is dwc3's DMA transfer descriptor). >> > You mean, should we allow function drivers to queue the data-stage >> > request after the setup handler has returned? I don't see any reason >>=20 >> that's already done: >>=20 >> static void dwc3_ep0_xfer_complete(struct dwc3 *dwc, >> const struct dwc3_event_depevt *event) >> { >> struct dwc3_ep *dep =3D dwc->eps[event->endpoint_number]; >>=20 >> dep->flags &=3D ~DWC3_EP_TRANSFER_STARTED; >> dep->resource_index =3D 0; >> dwc->setup_packet_pending =3D false; >>=20 >> switch (dwc->ep0state) { >> case EP0_SETUP_PHASE: >> dwc3_ep0_inspect_setup(dwc, event); >> break; >> [...] >> } > > ... > > You mean, it's already done in DWC3. What about other UDC drivers? if they're not implementing this possibility, then that's a bug on those UDC drivers :) >> > why not. After all, some drivers may require this. Likewise for the= =20 >> > data stage of a control-IN. >> > >> > Another thing we should do is give function drivers a way to send a >> > STALL response for the status stage. Currently there's no way to do >> > it, if a data stage is present. >>=20 >> Status stage can only be stalled if host tries to move data on the wrong >> direction. > > The USB-2 spec disagrees. See Table 8-7 in section 8.5.3.1 and the > following paragraphs. (Although, I can't see why a function would ever > fail to complete the command sequence for a control-IN transfer after > the data had already been sent.) I can't see how we could ever STALL after returning the data requested by the host. Seems like that wasn't well thought out. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlvii/cACgkQzL64meEa mQYKvQ/8CCBf3FwaXqIL/mvCQqt1ze3zs8mcp1rxg7hVqSt6y7uQ5xknxV8/QGZ4 P9kj3C5FyV9ezFNK0eyWyaZ8EK/juEiLR2QIGy8gaa4UifNO7HU3o8L9cUIIZNy3 biWQmTuj8ZUUt2CIQI2Yh1AzVFvNwbthtAA3AKtiid977VGJgxA7HUZlzk/0ZHxG MxqdwHPmjxP3IQAVj1SxNQn3XQKDeUMBmaYmMBMDSlYQghIQXJKEzfp1P0oGJKkx YYG9VgK7YQYoMMU6jWvClod9pCucyRibokmMzVoOdo0Iik8vpmDQhQEHR/9UeNu6 aP70k0kkSKSSq57JtmagOdzysmlKEQ6LNaybwtOv2VHwiCKB2P/yss77LI61eIhp /pmvUGg6xNfz6F9dMf3FCp3XAIvVW2ZFdYN8znjA2hltkh8FuKYHa09NGbilEbk1 MJ4gKsxmYazFiM0QkDHjzw7bTEHtVOwmnWGDdo+F794Rr2JNbKmKD2OM6FxuecTg xZq+ByUc02hANHKw7yHJNachaCYxaj5urZTzkHPCh57aLeO3WGVfmHaEZPI3GcMF 1T8BTK53FJKVY1VBCc7KciBuCIA4Zdphw3pSu9I4XkprztOvRtm/MbxEHt7Z/QIy USUteLY7V+GNPjf6a3SXtxupxDr3+QdSWYJHU8sgforaYYZK5LA= =bVC5 -----END PGP SIGNATURE----- --=-=-=--