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: <87d0riv4jw.fsf@linux.intel.com> Date: Tue, 06 Nov 2018 13:17:07 +0200 To: Laurent Pinchart , Alan Stern Cc: Paul Elder , Bin Liu , kieran.bingham@ideasonboard.com, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, rogerq@ti.com List-ID: SGksCgpMYXVyZW50IFBpbmNoYXJ0IDxsYXVyZW50LnBpbmNoYXJ0QGlkZWFzb25ib2FyZC5jb20+ IHdyaXRlczoKPj4gPj4+PiBGdXJ0aGVybW9yZSwgd2UgaGF2ZSBmb3VuZCB0aGF0IFVTQl9HQURH RVRfREVMQVlFRF9TVEFUVVMgaXMgcmFjZXksCj4+ID4+Pj4gd2hpY2ggaGFzIGFscmVhZHkgYmVl biBvYnNlcnZlZCBpbiB0aGUgVVZDIGdhZGdldCBkcml2ZXIgcHJldmlvdXNseQo+PiA+Pj4+IFsw XS4gVGhlIHJhY2VpbmVzcyBzdGVtcyBmcm9tIHRoZSBmYWN0IHRoYXQgdGhpbmdzIGNhbiBoYXBw ZW4gaW4KPj4gPj4+PiBiZXR3ZWVuIHJldHVybmluZyBVU0JfR0FER0VUX0RFTEFZRURfU1RBVFVT IGFuZCB0aGUgY29tcG9zaXRlIGxheWVyCj4+ID4+Pj4gcmVhY3RpbmcgdG8gaXQgLSBlc3BlY2lh bGx5IGlmIHVzYl9jb21wb3NpdGVfc2V0dXBfY29udGludWUgaXMgY2FsbGVkCj4+ID4+Pj4gd2l0 aGluIHRoYXQgd2luZG93IGl0IGNhdXNlcyBhIFdBUk4uIEluIGFueSBjYXNlLCB0aGUgZmFjdCB0 aGF0IHRoZQo+PiA+Pj4+IG1lY2hhbmlzbSBpdHNlbGYgaXMgcmFjZXkgc3VnZ2VzdHMgdGhhdCBp dCBuZWVkcyBpbXByb3ZlbWVudCwgYW5kIHVzaW5nCj4+ID4+Pj4gaXQgd291bGRuJ3QgYmUgYSBn b29kIHNvbHV0aW9uIGluIHRoaXMgY2FzZS4KPj4gCj4+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlz IGF0IGFsbC4gIFRoZSBjb21wb3NpdGUgbGF5ZXIgcmVhY3RzIHRvCj4+IFVTQl9HQURHRVRfREVM QVlFRF9TVEFUVVMgYXMgc29vbiBhcyBpdCByZWNlaXZlcyB0aGUgcmV0dXJuIHZhbHVlLiAgQ2Fu Cj4+IFBhdWwgb3IgTGF1cmVudCBnaXZlIGEgbW9yZSBleHBsaWNpdCBleGFtcGxlIG9mIHRoaXMg cmFjZT8KPgo+IFRoZSBjb21wb3NpdGUgbGF5ZXIgb25seSBoYW5kbGVzIFVTQl9HQURHRVRfREVM QVlFRF9TVEFUVVMgZm9yIAo+IFVTQl9SRVFfU0VUX0NPTkZJR1VSQVRJT04gKGluIHNldF9jb25m aWcoKSkgYW5kIGZvciBVU0JfUkVRX1NFVF9JTlRFUkZBQ0UgKGluIAo+IGNvbXBvc2l0ZV9zZXR1 cCgpKS4gSXQgaW5jcmVtZW50cyBjZGV2LT5kZWxheWVkX3N0YXR1cyBpbW1lZGlhdGVseS4gVGhl biwgaW4gCj4gdXNiX2NvbXBvc2l0ZV9zZXR1cF9jb250aW51ZSgpLCBpZiBjZGV2LT5kZWxheWVk X3N0YXR1cyBpcyBub3QgemVybywgaXQgcXVldWVzIAo+IGEgWkxQLCBhbmQgd2FybnMgb3RoZXJ3 aXNlLgo+Cj4gVGhpcyBtZWNoYW5pc20gZGVsYXlzIHRoZSBkYXRhIHN0YWdlLCBub3QgdGhlIHN0 YXR1cyBzdGFnZSAob3IsIHRvIGJlIHByZWNpc2UsIAo+IGl0IGRlbGF5cyB0aGUgc3RhdHVzIHN0 YWdlIGluc29mYXIgYXMgdGhlIHN0YXR1cyBzdGFnZSBjb21lcyBhZnRlciB0aGUgZGF0YSAKPiBz dGFnZSksIGFuZCBvbmx5IHN1cHBvcnRzIGNvbnRyb2wgT1VUIHJlcXVlc3RzIHdpdGggMCBieXRl cyBvZiBkYXRhICh3aGljaCBpcyAKPiB0aGUgY2FzZSBvZiBib3RoIFVTQl9SRVFfU0VUX0lOVEVS RkFDRSBhbmQgVVNCX1JFUV9TRVRfQ09ORklHVVJBVElPTikuIEZvciBhbGwgCj4gb3RoZXIgcmVx dWVzdHMsIHRoZSBjb21wb3NpdGUgbGF5ZXIgcGFzc2VzIFVTQl9HQURHRVRfREVMQVlFRF9TVEFU VVMgdG8gdGhlIAo+IFVEQy4KCkRBVEEgc3RhZ2UgYWx3YXlzIGRlcGVuZHMgb24gYSB1c2JfZXBf cXVldWUoKSBmcm9tIGdhZGdldCBkcml2ZXIuIFNvCml0J3MgYWx3YXlzICJkZWxheWVkIiBpbiB0 aGF0IHNlbnNlLgoKPiBUaGUgdGhyZWUgVURDcyB0aGF0IGltcGxlbWVudCBVU0JfR0FER0VUX0RF TEFZRURfU1RBVFVTIHN1cHBvcnQgc2V0IGEgCj4gZGVsYXllZF9zdGF0dXMgZmxhZyBpbiBhbiBp bnRlcm5hbCBzdHJ1Y3R1cmUuIEkgaGF2ZW4ndCBpbnNwZWN0ZWQgaW4gZGV0YWlscyAKPiB3aGF0 IHRoZXkgZG8gbmV4dCBhcyBJJ20gbm90IGZhbWlsaWFyIHdpdGggYWxsIG9mIHRoZW0sIGJ1dCB0 aGUgZHdjMyBkcml2ZXIgCj4ganVzdCBza2lwcyB0aGUgaGFuZGxpbmcgb2YgdGhlIHN0YXR1cyBw aGFzZSBpbiBkd2MzX2VwMF94ZmVybm90cmVhZHkoKSBhbmQgCj4gZGVsYXlzIGl0IHRvIF9fZHdj M19nYWRnZXRfZXAwX3F1ZXVlKCkuIFRoaXMgb25seSB3b3JrcyBmb3IgMC1sZW5ndGggcmVxdWVz dHMsIAo+IHdpdGggbm8gZGF0YSBwaGFzZS4KCmRhdGEgc3RhZ2UgYWx3YXlzIGRlcGVuZHMgb24g dXNiX2VwX3F1ZXVlKCkuIFRoZXJlIHdhcyBuZXZlciBhbnkgbmVlZApmb3IgVURDIHRvIGhhbmRs ZSBEYXRhIHN0YWdlIGludGVybmFsbHkuIEFsc28sIHN0YXR1cyBzdGFnZSBpcyBhbHdheXMgYSBa TFAuCgo+IEV2ZW4gd2hlbiBsaW1pdGVkIHRvIDAtbGVuZ3RoIGNvbnRyb2wgT1VUIHJlcXVlc3Rz LCB0aGlzIG1lY2hhbmlzbSBpcyByYWN5LiAKPiBUaGUgc2V0dXAgaGFuZGxlciwgd2hlbiBpdCB3 YW50cyB0byBkZWxheSB0aGUgc3RhdHVzIHBoYXNlLCB3aWxsIHF1ZXVlIAo+IGFzeW5jaHJvbm91 cyB3b3JrIHRoYXQgd2lsbCwgd2hlbiBpdCBjb21wbGV0ZXMsIGNhbGwgCj4gdXNiX2NvbXBvc2l0 ZV9zZXR1cF9jb250aW51ZSgpIHRvIHByb2NlZWQgd2l0aCB0aGUgc3RhdHVzIHBoYXNlLiBRdWV1 aW5nIHRoZSAKPiB3b3JrIGhhcyB0byBiZSBkb25lIGJlZm9yZSB0aGUgc2V0dXAgaGFuZGxlciBy ZXR1cm5zLCBhbmQgdGhlIGNkZXYtCj4+ZGVsYXllZF9zdGF0dXMgaXMgb25seSBpbmNyZW1lbnRl ZCBhZnRlciB0aGUgc2V0dXAgaGFuZGxlciByZXR1cm5zLCBpbiAKPiBjb21wb3NpdGVfc2V0dXAo KS4gVGhlcmUgaXMgdGh1cyBhIHRpbWUgd2luZG93IGR1cmluZyB3aGljaCB0aGUgYXN5bmNocm9u b3VzIAo+IHdvcmsgY2FuIGNhbGwgdXNiX2NvbXBvc2l0ZV9zZXR1cF9jb250aW51ZSgpIGJlZm9y ZSBjZGV2LT5kZWxheWVkX3N0YXR1cyBoYXMgCj4gYmVlbiBpbmNyZW1lbnRlZC4gV2UgaGF2ZSBt YW5hZ2VkIHRvIGhpdCB0aGlzIGluIHByYWN0aWNlLCB3aXRoIGEgc3VycHJpc2luZ2x5IAo+IGhp Z2ggcmF0ZSBzZWVpbmcgaG93IHNtYWxsIHRoZSB3aW5kb3cgaXMuCgp0aGF0J3Mgb25seSB0aGUg Y2FzZSBiZWNhdXNlIHdlIGhhdmUgdHdvIGRpZmZlcmVudCAibW9kZXMiIGZvciB0aGlzLiBPbmUK d2hlcmUgVURDIGhhbmRsZXMgaXQgaW50ZXJuYWxseSBhbmQgYW5vdGhlciB3aGVyZSBnYWRnZXQg ZHJpdmVyIGhhcyB0bwpxdWV1ZSBhIHJlcXVlc3QuIEknbSB2b3VjaGluZyBmb3IgbWFraW5nIHN0 YXR1cyBzdGFnZSBhbHdheXMgZXhwbGljaXQsCmkuZS4gd2Ugc2hvdWxkIGFsd2F5cyBleHBlY3Qg YSB1c2JfZXBfcXVldWUoKS4KCj4gTm93IHRoYXQgSSd2ZSB3cml0dGVuIGFsbCB0aGlzLCBJIHJl YWxpemUgdGhhdCBjZGV2LT5kZWxheWVkX3N0YXR1cyBpcyBndWFyZGVkIAo+IGJ5IGNkZXYtPmxv Y2suIEkgdGh1cyB3b25kZXIgd2hldGhlciBvdXIgYW5hbHlzaXMgd2FzIGNvcnJlY3QsIG9yIGlm IHdlIHdlcmUgCj4gaGl0dGluZyBhIGRpZmZlcmVudCBidWcgOi1TIFBhdWwsIGNvdWxkIHlvdSB0 ZXN0IHRoaXMgYWdhaW4gPyBQbGVhc2Ugbm90ZSwgCj4gaG93ZXZlciwgdGhhdCB0aGUgcmFjZSBk ZXNjcmliZWQgaGVyZSBpcyBub3QgcmVsYXRlZCB0byB0aGlzIHBhdGNoIHNlcmllcywgCj4gZXhj ZXB0IGluIGhvdyBpdCBpbmZsdWVuY2VzIHRoZSBBUEkgZGVzaWduIHRvIGF2b2lkIHJhY2UgY29u ZGl0aW9ucy4KPgo+PiBBc3N1bWluZyB5b3UgYXJlIGNvcnJlY3QsIHdvdWxkbid0IGl0IG1ha2Ug c2Vuc2UgdG8gZml4IG9yIGVsaW1pbmF0ZQo+PiB0aGUgcmFjZSBieSBjaGFuZ2luZyBjb21wb3Np dGUuYz8KPgo+IEkgd2FzIGFib3V0IHRvIHdyaXRlIHRoYXQgd2Ugd291bGQgbmVlZCB0byBsb2Nr IGFjY2VzcyB0byBjZGV2LQo+PmRlbGF5ZWRfc3RhdHVzLCBhbmQgZm91bmQgb3V0IHRoYXQgd2Ug YWxyZWFkeSB1c2UgY2Rldi0+bG9jayB0byBkbyBzby4gTW9yZSAKPiBpbnZlc3RpZ2F0aW9ucyBh cmUgbmVlZGVkLgo+Cj4gUGxlYXNlIG5vdGUsIGhvd2V2ZXIsIHRoYXQgVVNCX0dBREdFVF9ERUxB WUVEX1NUQVRVUyBpcyBsaW1pdGVkIHRvIDAtbGVuZ3RoIAo+IGNvbnRyb2wgT1VUIHJlcXVlc3Rz LCBzbyB0aGUgcHJvYmxlbSB0aGF0IGxlZCB0byB0aGlzIHBhdGNoIHNlcmllcyBzdGlsbCAKPiBl eGlzdHMsIGV2ZW4gaWYgdGhlIHJhY2UgY29uZGl0aW9uIEkgdGhvdWdodCB3YXMgdGhlcmUgZG9l c24ndCBleGlzdC4KCkFuZCB0aGF0IHByb2JsZW0gaXMuLi4/CgpEQVRBIHN0YWdlIGFsd2F5cyBk ZXBlbmRzIG9uIGEgdXNiX2VwX3F1ZXVlKCkgZnJvbSBnYWRnZXQgZHJpdmVyLgoKPj4gPj4gSWYg dGhpcyB3b3JrcyB3aXRoIGR3YzMgKyB1dmMsIHRoZW4gd2UgaGF2ZSBhIGdvb2QgcmVjaXBlIG9u IGhvdyB0bwo+PiA+PiBpbXBsZW1lbnQgZm9yIHRoZSBvdGhlciBkcml2ZXJzLgo+PiA+IAo+PiA+ IEdpdmVuIHRoYXQgd2UgbmVlZCB0byBkZWxheSB0aGUgc3RhdHVzIHN0YWdlIGFuZCBub3QgdGhl IGRhdGEgc3RhZ2UsIHdlCj4+ID4gY2FuJ3QgZXhwbGljaXRseSByZXF1ZXN0IHRoZSBzdGF0dXMg c3RhZ2UgdGhyb3VnaCBhIHVzYiByZXF1ZXN0IHF1ZXVlLgo+PiAKPj4gV2h5IG5vdD8gIFRoZSBz dGF0dXMgc3RhZ2UgZm9yIGEgY29udHJvbC1PVVQgdHJhbnNmZXIgaXMgc2ltcGx5IGEKPj4gemVy by1sZW5ndGggSU4gdHJhbnNhY3Rpb24uICBJdCdzIGVhc3kgdG8gcXVldWUgYSByZXF1ZXN0IGZv ciBzdWNoIGEKPj4gdHJhbnNhY3Rpb24uICBJcyB0aGUgaXNzdWUgdGhhdCB0aGVyZSdzIG5vIHdh eSB0byBzcGVjaWZ5IHRoZSBkaXJlY3Rpb24KPj4gb2YgdGhlIHJlcXVlc3QgKGhlbmNlIG5vIGRp cmVjdCB3YXkgdG8gdGVsbCB3aGV0aGVyIGEgemVyby1sZW5ndGgKPj4gcmVxdWVzdCBpcyBmb3Ig dGhlIGRhdGEgc3RhZ2Ugb3IgdGhlIHN0YXR1cyBzdGFnZSk/Cj4KPiBPSywgSSBzdXBwb3NlIHdl IGNvdWxkIHF1ZXVlIGEgcmVxdWVzdCBmb3IgdGhpcywgaW4gd2hpY2ggY2FzZSB3ZSB3b3VsZCBo YXZlIAo+IHRvIHF1ZXVlIHR3byByZXF1ZXN0cyBmb3IgY29udHJvbCBPVVQgdHJhbnNmZXJzIChv bmUgZm9yIHRoZSBkYXRhIHN0YWdlIGFuZCAKPiBvbmUgZm9yIHRoZSBzdGF0dXMgc3RhZ2UpLiBJ J20gaG93ZXZlciBub3QgY29udmluY2VkIHRoYXQgd291bGQgYmUgdGhlIGJlc3QgCgp0aGF0J3Mg Y29ycmVjdC4gVGhpcyBpcyB3aGF0ICJtYWtlIHN0YXR1cyBzdGFnZSBhbHdheXMgZXhwbGljaXQi IG1lYW4gOikKCj4gQVBJIHRvIGhhbmRsZSB0aGUgc3RhdHVzIHN0YWdlLCBhcyB0aGUgZnVuY3Rp b24gZHJpdmVyIHdvdWxkIG5lZWQgdG8gcXVldWUgYSAKCml0IGF2b2lkcyBhbGwgdGhlIHNwZWNp YWwgY2FzZXMuIFVEQyBkcml2ZXJzIGNhbiBpbXBsZW1lbnQgYSBzaW5nbGUKaGFuZGxpbmcgZm9y IHN0cnVjdCB1c2JfcmVxdWVzdC4gV2UgY291bGQgZG8gYXdheSB3aXRoIHNwZWNpYWwgcmV0dXJu CnZhbHVlcyBhbmQgc28gb24uLi4KCj4gcmVxdWVzdCBhbmQgdGhlIFVEQyB3b3VsZCB0aGVuIG5l ZWQgdG8gY2hlY2sgd2hldGhlciB0aGF0IHJlcXVlc3QgY29ycmVzcG9uZHMgCj4gdG8gYSBzdGF0 dXMgc3RhZ2UgYW5kIHByb2Nlc3MgaXQgYWNjb3JkaW5nbHkuIEEgbmV3IG9wZXJhdGlvbiBzcGVj aWZpYyB0byB0aGlzIAoKbm8sIGl0IHdvdWxkbid0LiBVREMgd291bGQgaGF2ZSB0byBjaGVjayB0 aGUgc2l6ZSBvZiByZXF1ZXN0LCB0aGF0J3MKYWxsOgoKCWlmIChyLT5sZW5ndGggPT0gMCkKICAg ICAgICAJc3BlY2lhbF96bHBfaGFuZGxpbmcoKTsKCWVsc2UKICAgICAgICAJcmVndWxhcl9ub25f emxwX2hhbmRsaW5nKCk7CgpCdXQgd2UgZG9uJ3QgbmVlZCB0byBjYXJlIGFib3V0IHNwZWNpYWwg cmV0dXJuIHZhbHVlcyBhbmQgdGhlIGxpa2UuIFdlCmRvbid0IGV2ZW4gbmVlZCB0byBjYXJlIChm cm9tIFVEQyBwZXJzcGVjdGl2ZSkgaWYgd2UncmUgZGVhbGluZyB3aXRoCjItc3RhZ2Ugb3IgMy1z dGFnZSBjb250cm9sIHRyYW5zZmVycyAod2VsbCwgZHdjMyBuZWVkcyB0byBjYXJlIGJlY2F1c2UK b2YgZGlmZmVyZW50IFRSQiB0eXBlcyB0aGF0IG5lZWRzIHRvIGJlIHVzZWQsIGJ1dCB0aGF0J3Mg YW5vdGhlciBzdG9yeSkKCj4gd291bGQgYmUgZWFzaWVyIGZvciBib3RoIHRoZSBmdW5jdGlvbiBk cml2ZXIgYW5kIHRoZSBVREMgaW4gbXkgb3Bpbmlvbi4gCgppdCB3b3VsZG4ndC4gV2Ugd291bGQg anVzdCBiZSBtb3ZpbmcgdGhlIHNwZWNpYWwgY2FzZSB0byBhbm90aGVyCmZ1bmN0aW9uLCByYXRo ZXIgdGhhbiBlbGltaW5hdGluZyBpdC4KCj4gVGhlcmUncyBhbHNvIHRoZSBmYWN0IHRoYXQgcmVx dWVzdHMgY2FuIHNwZWNpZnkgYSBjb21wbGV0aW9uIGhhbmRsZXIsIGJ1dCBvbmx5IAo+IHRoZSBk YXRhIHN0YWdlIHJlcXVlc3Qgd291bGQgc2VlIGl0cyBjb21wbGV0aW9uIGhhbmRsZXIgY2FsbGVk ICh1bmxlc3Mgd2UgCj4gcmVxdWlyZSBVRENzIHRvIGNhbGwgY29tcGxldGlvbiByZXF1ZXN0cyBh dCB0aGUgY29tcGxldGlvbiBvZiB0aGUgc3RhdHVzIAo+IHN0YWdlLCBidXQgSSdtIG5vdCBzdXJl IHRoYXQgYWxsIFVEQ3MgY2FuIHJlcG9ydCB0aGUgZXZlbnQgdG8gdGhlIGRyaXZlciwgYW5kIAo+ IHRoYXQgd291bGQgbGlrZWx5IGJlIHVzZWxlc3MgYXMgbm9ib2R5IG5lZWRzIHRoYXQgZmVhdHVy ZSkuCgp5b3Ugc3RpbGwgd2FubmEga25vdyBpZiB0aGUgaG9zdCBhY3R1YWxseSBwcm9jZXNzZWQg eW91ciBzdGF0dXMKc3RhZ2UuIHVkYy1jb3JlIGNhbiAoYW5kIHNob3VsZCkgcHJvdmlkZSBhIGdl bmVyaWMgc3RhdHVzIHN0YWdlCmNvbXBsZXRpb24gZnVuY3Rpb24gd2hpY2gsIGF0IGEgbWluaW11 bSwgYWlkcyB3aXRoIHNvbWUgdHJhY2Vwb2ludHMuCgpPbmUgd2F5IHRvIHNhdGlzZnkgd2hhdCB5 b3Ugd2FudCwgd2l0aCB3aGF0IEkgd2FudCBpcyB0byBoYXZlIFVEQyBjb3JlCmltcGxlbWVudCBz b21ldGhpbmcgbGlrZSBiZWxvdzoKCmludCB1c2JfZXBfc3RhcnRfc3RhdHVzX3N0YWdlKHN0cnVj dCB1c2JfZ2FkZ2V0ICpnKQp7CglyZXR1cm4gdXNiX2VwX3F1ZXVlKGctPmVwMCwgJmctPmVwMF9z dGF0dXNfcmVxdWVzdCk7Cn0KCnNwZWNpYWwgZnVuY3Rpb24gZm9yIHlvdSwgdXNiX2VwX3F1ZXVl KCkgZm9yIG1lIDotcAoKPj4gQWRtaXR0ZWRseSwgaXQgbWlnaHQgYmUgbmljZSB0byBwcm92aWRl IGEgbGlicmFyeSByb3V0aW5lIGluIHRoZSBVREMKPj4gY29yZSB0byBxdWV1ZSBzdWNoIHJlcXVl c3RzLCBzaW5jZSBpdCBpbnZvbHZlcyBhIGJ1bmNoIG9mIHVuaW50ZXJlc3RpbmcKPj4gYm9pbGVy cGxhdGUgb3BlcmF0aW9ucy4KPj4gCj4+ID4gV291bGQgYSBuZXcgZXhwbGljaXQgZnVuY3Rpb24g Y2FsbCB3b3JrIGZvciB5b3UgZm9yIHRoYXQgcHVycG9zZSA/Cj4+IAo+PiBJdCB3b3VsZCBiZSBv a2F5LCBidXQgSSBxdWVzdGlvbiB3aGV0aGVyIG9uZSBpcyByZWFsbHkgbmVlZGVkLgo+Cj4gSSB0 aGluayB0aGUgQVBJIHdvdWxkIGJlIGNsZWFuZXIsIGJ1dCBpdCBtaWdodCBqdXN0IGJlIGEgbWF0 dGVyIG9mIHRhc3RlLgoKRnJvbSBhIFVEQyBwZXJzcGVjdGl2ZSwgSSdtIG1vcmUgaW5jbGluZWQg dG8gcmVtb3Zpbmcgc3BlY2lhbCBjYXNlcywKcmF0aGVyIHRoYW4gbWFraW5nIHRoZW0gbW9yZSBh cHBhcmVudC4gSGF2aW5nIGEgc2luZ2xlIG1ldGhvZCBmb3IKaGFuZGxpbmcgYWxsIHRocmVlIHN0 YWdlcyBvZiBhIGNvbnRyb2wgdHJhbnNmZXIsIElNTywgaXMgZmFyIG1vcmUKYmVuZWZpY2lhbCBh cyBpdCByZW1vdmVzIG1hZ2ljIHJldHVybiB2YWx1ZXMgYW5kIHNldmVyYWwgYnJhbmNoZXMgb24g VURDCmRyaXZlci4KCj4+ID4+PiAtIFRoZSBtZWNoYW5pc20gaXMgcG9vcmx5IGRvY3VtZW50ZWQu IEFzIFBhdWwgbWVudGlvbmVkLCBjb21tZW50cyBpbgo+PiA+Pj4gdGhlIGNvZGUgc3RhdGUgdGhh dCBVU0JfR0FER0VUX0RFTEFZRURfU1RBVFVTIGRlbGF5IHRoZSAiZGF0YS9zdGF0dXMKPj4gPj4+ IHN0YWdlcyIuIFRoaXMgaXMgdmVyeSB1bmNsZWFyLCBhbmQgdGhlIG9ubHkgdGhyZWUgVURDcyB0 aGF0IGltcGxlbWVudAo+PiA+Pj4gdGhlIG1lY2hhbmlzbSBzZWVtIHRvIGRvIHNvIGluIGRpZmZl cmVudCB3YXlzOgo+PiAKPj4gV2UgY2FuIGZpeCBjb21tZW50cyBhbmQgZG9jdW1lbnRhdGlvbiBw cmV0dHkgZWFzaWx5LiAgOi0pCj4KPiBJdCdzIGhhcmRlciB0byBmaXggdGhlbSBpZiBkaWZmZXJl bnQgaW1wbGVtZW50YXRpb25zIGludGVycHJldCB0aGVtIGluIAo+IGRpZmZlcmVudCB3YXlzIDot KSBUaGF0IG1pZ2h0IG5vdCBiZSB0aGUgY2FzZSB0aG91Z2gsIGFzIG1lbnRpb25lZCBhYm92ZSBJ IAoKdGhhdCdzIHdoZXJlIGEgcHJvcGVyIGF1ZGl0IG9mIHRoZSBjb2RlIGNvbWVzIGludG8gcGxh eSA6KQoKPiBoYXZlbid0IHN0dWRpZWQgdGhlIHRocmVlIFVEQ3MgdGhhdCBpbXBsZW1lbnQgdGhp cyBpbiBkZXRhaWxzLCBJIG9ubHkgaGFkIGEgCj4gbG9vayBhdCB0aGUgZHdjMy4KCnRoYXQncyBw ZXJmZWN0bHkgZmluZS4gV2UgY2FuIENjIG90aGVyIGZvbGtzIGludm9sdmVkIHdpdGggdGhlIG90 aGVyClVEQ3MgYW5kIGhhdmUgdGhlbSBjaGlwIGluLgoKPj4gVGhpcyByZXF1aXJlcyB0aGUgVURD IHRvIHNwZWNpZmljYWxseSBrZWVwIHRyYWNrIG9mIHRoZSBkaXJlY3Rpb24gb2YKPj4gdGhlIGN1 cnJlbnQgdHJhbnNmZXIgYW5kIHdoZXRoZXIgb3Igbm90IGEgZGF0YS1zdGFnZSB0cmFuc2ZlciBo YXMKPj4gYWxyZWFkeSBiZWVuIHF1ZXVlZC4gIFRoYXQgc2hvdWxkbid0IGJlIGhhcmQuCj4KPiBJ dCdzICJqdXN0IiBhIHN0YXRlIG1hY2hpbmUgc28gaXQgd291bGRuJ3QgYmUgdG9vIGhhcmQuIFdo YXQgd2UgbmVlZCB0byBhZ3JlZSAKPiBvbiBpcyBob3cgdGhlIHN0YXRlIG1hY2hpbmUgb3BlcmF0 ZXMsIGFuZCB0aGVuIHRoZSBBUEkgdG8gY29udHJvbCBpdC4gVGhhdCdzIAo+IHdoYXQgSSB0cmll ZCB0byBkZXNjcmliZSBiZWxvdyBpbiBteSBwcmV2aW91cyBlLW1haWwuCj4KPj4gKEJ1dCBpdCBk b2VzIGludm9sdmUgYQo+PiByYWNlIGluIGNhc2VzIHdoZXJlIHRoZSBob3N0IGdldHMgdGlyZWQg b2Ygd2FpdGluZyBhbmQgaXNzdWVzIGFub3RoZXIKPj4gU0VUVVAgcGFja2V0IGJlZm9yZSB0aGUg cHJvY2Vzc2luZyBvZiB0aGUgZmlyc3QgdHJhbnNmZXIgaXMgZmluaXNoZWQuKQoKSG9zdCB3b3Vs ZCBzdGFsbCBmaXJzdCBpbiB0aGF0IGNhc2UuIERyaXZlciBpcyBhbHJlYWR5IHJlcXVpcmVkIHRv CmhhbmRsZSBzdGFsbHMgZm9yIHNldmVyYWwgb3RoZXIgY29uZGl0aW9ucy4gSWYgdGhlaHJlIGFy ZSBidWdzIGluIHRoYXQKYXJlYSwgSSdkIHByZWZlciBjYXRjaGluZyB0aGVtLgoKPj4gPiBJIHdv bmRlciBpZiB0aGVyZSdzIHJlYWxseSBhIHVzZSBjYXNlIGZvciBkZWxheWluZyB0aGUgZGF0YSBz dGFnZSBvZgo+PiA+IGNvbnRyb2wgT1VUIHJlcXVlc3RzLCBhcyBpdCBzZWVtcyB0byBtZSB0aGF0 IHdlIGNhbiBwZXJmb3JtIHRoZQo+PiA+IGFzeW5jaHJvbm91cyB2YWxpZGF0aW9uIG9mIHRoZSBz ZXR1cCBhbmQgZGF0YSBzdGFnZXMgdG9nZXRoZXIsIGluIHdoaWNoCj4+ID4gY2FzZSB3ZSB3b3Vs ZCBhbHdheXMgcHJvY2VlZCB0byB0aGUgZGF0YSBzdGFnZSwgYW5kIG9ubHkgcG90ZW50aWFsbHkK Pj4gPiBkZWxheSB0aGUgc3RhdHVzIHN0YWdlLiBIb3dldmVyLCBpZiB3ZSBzd2l0Y2ggdG8gYW4g ZXhwbGljaXQgQVBJIHdoZXJlCj4+ID4gdGhlIHRyYW5zaXRpb24gZnJvbSB0aGUgc2V0dXAgdG8g dGhlIGRhdGEgc3RhZ2UgaXMgdHJpZ2dlcmVkIGJ5IHF1ZXVlaW5nCj4+ID4gYSByZXF1ZXN0LCBh bmQgZ2l2ZW4gdGhhdCBzdWNoIGEgdHJhbnNpdGlvbiBtYXkgbmVlZCB0byBiZSBkZWxheWVkIGZv cgo+PiA+IHRoZSBjb250cm9sIElOIGNhc2UsIGRlbGF5aW5nIHRoZSBkYXRhIHN0YWdlIGZvciBj b250cm9sIE9VVCB3b3VsZAo+PiA+IGVzc2VudGlhbGx5IGNvbWUgZm9yIGZyZWUuCj4KPiBXaGF0 IGRvIHlvdSB0aGluayBhYm91dCB0aGlzID8gU2hvdWxkIHdlIGFsbG93IGZ1bmN0aW9uIGRyaXZl cnMgdG8gZGVsYXkgdGhlIAo+IGRhdGEgc3RhZ2Ugb2YgY29udHJvbCBPVVQgcmVxdWVzdHMgPwoK aXQncyBhbHJlYWR5IGRlbGF5ZWQuIFVEQyB3b24ndCBzdGFydCBkYXRhIHN0YWdlIHVubGVzcyBp dCBoYXMgYSBidWZmZXIKdG8gcHV0IHRoZSBkYXRhLiBXaXRob3V0IGEgdXNiX2VwX3F1ZXVlKCks IFVEQyBkb2Vzbid0IGhhdmUgYSBidWZmZXIuCgo+PiA+IElmIHdlIGVuZCB1cCBtb3ZpbmcgdG8g ZXhwbGljaXQgc3RhdGUgaGFuZGxpbmcsIHdpdGggdGhlIGRhdGEgc3RhZ2UgYmVpbmcKPj4gPiBl bnRlcmVkIGJ5IHF1ZXVlaW5nIGEgcmVxdWVzdCwgYW5kIHRoZSBzdGF0dXMgc3RhZ2UgYmVpbmcg ZW50ZXJlZCBieQo+PiA+IGNhbGxpbmcgYSBuZXcgZnVuY3Rpb24sIGNvbnRyb2wgT1VUIHJlcXVl c3RzIHdpdGggMCBieXRlcyBvZiBkYXRhIHRoYXQKPj4gPiBjYW4gYmUgaGFuZGxlZCBzeW5jaHJv bm91c2x5IGluIHRoZSBzZXR1cCBoYW5kbGVyIHdvdWxkIHJlcXVpcmUgZnVuY3Rpb24KPj4gPiBk cml2ZXJzIHRvIGJvdGggcXVldWUgYSB6ZXJvLWxlbmd0aCByZXF1ZXN0IGFuZCBjYWxsIHRoZSBz dGF0dXMgZnVuY3Rpb24uCj4+ID4gVGhpcyB3b3VsZCBtYWtlIHRoZSBmdW5jdGlvbiBjb2RlIG1v cmUgY29tcGxleCwgYW5kIEkgd29uZGVyIHdoZXRoZXIgYQo+PiA+IHNob3J0Y3V0IHdvdWxkIGJl IGEgZ29vZCBpZGVhLCBwZXJoYXBzIGluIHRoZSBmb3JtIG9mIGEgZmxhZyBpbiB0aGUKPj4gPiBy ZXF1ZXN0IHRoYXQgdGVsbHMgdGhlIFVEQyB0byBhdXRvbWF0aWNhbGx5IHByb2NlZWQgdG8gdGhl IHN0YXR1cyBzdGFnZQo+PiA+IGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBkYXRhIHN0YWdlLiBPciB3 ZSBjb3VsZCBtYWtlIHRoYXQgYmVoYXZpb3VyIHRoZQo+PiA+IGRlZmF1bHQgd2hlbiB0aGUgcmVx dWVzdCBkb2Vzbid0IGhhdmUgYSBjb21wbGV0aW9uIGhhbmRsZXIgKGFzIG1vdmluZwo+PiA+IGV4 cGxpY2l0bHkgdG8gdGhlIHN0YXR1cyBzdGFnZSBzaG91bGQgYmUgZG9uZSBhdCB0aGUgZWFybGll c3QgZnJvbSB0aGUKPj4gPiBkYXRhIHN0YWdlIGNvbXBsZXRpb24gaGFuZGxlcikuCj4KPiBGcm9t IGFuIEFQSSBwb2ludCBvZiB2aWV3LCB0b3dhcmRzIGZ1bmN0aW9uIGRyaXZlcnMsIEkgcmVhbGx5 IHdhbnQgYW4gZXhwbGljaXQgCj4gZnVuY3Rpb24gdG8gcHJvY2VlZCB3aXRoIHRoZSBzdGF0dXMg c3RhZ2UuIFRoYXQgY291bGQgaW50ZXJuYWxseSBxdWV1ZSBhIFpMUCAKPiByZXF1ZXN0IG9yIGNh bGwgYW5vdGhlciBBUEksIGJ1dCBpbiBhbnkgY2FzZSBJIGRvbid0IHdhbnQgdGhlIHN0YXR1cyBz dGFnZSBaTFAgCj4gcmVxdWVzdCB0byBiZSB2aXNpYmxlIHRvIHRoZSBmdW5jdGlvbiBkcml2ZXJz LiBEbyB5b3UgYWdyZWUgd2l0aCB0aGlzID8KCndoeSBjYW4ndCBpdCBiZSB2aXNpYmxlPyBJIGRv bid0IG1pbmQgaGF2aW5nIGEgZnVuY3Rpb24gd3JhcHBpbmcKdXNiX2VwX3F1ZXVlKCksIGJ1dCB3 aHkgaXMgaXQgYmFkIHRvIGhhdmUgZnVuY3Rpb25zIGNhbGwgdXNiX2VwX3F1ZXVlKCkKZGlyZWN0 bHk/Cgo+IFRvIHNpbXBsaWZ5IGZ1bmN0aW9uIGRyaXZlcnMsIGRvIHlvdSB0aGluayB0aGUgYWJv dmUgcHJvcG9zYWwgb2YgYWRkaW5nIGEgZmxhZyAKPiB0byB0aGUgKGRhdGEgc3RhZ2UpIHJlcXVl c3QgdG8gcmVxdWVzdCBhbiBhdXRvbWF0aWMgdHJhbnNpdGlvbiB0byB0aGUgc3RhdHVzIAo+IHN0 YWdlIGlzIGEgZ29vZCBpZGVhID8gV2UgY291bGQgZXZlbiBwb3NzaWJseSBpbnZlcnQgdGhlIGxv Z2ljIGFuZCB0cmFuc2l0aW9uIAoKbm8sIEkgZG9uJ3QgdGhpbmsgc28uIE1ha2luZyB0aGUgc3Rh dHVzIHBoYXNlIGFsd2F5cyBleHBsaWNpdCBpcyBmYXIKYmV0dGVyLiBVRENzIHdvbid0IGhhdmUg dG8gY2hlY2sgZmxhZ3MsIG9yIGFjdCBvbiBtYWdpYyByZXR1cm4KdmFsdWVzLiBJdCBqdXN0IHdv bid0IGRvIGFueXRoaW5nIHVudGlsIGEgcmVxdWVzdCBpcyBxdWV1ZWQuCg== 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 8F7CAC32789 for ; Tue, 6 Nov 2018 11:17:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 37FC720869 for ; Tue, 6 Nov 2018 11:17:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 37FC720869 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 S1730322AbeKFUl6 (ORCPT ); Tue, 6 Nov 2018 15:41:58 -0500 Received: from mga18.intel.com ([134.134.136.126]:18871 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726976AbeKFUl6 (ORCPT ); Tue, 6 Nov 2018 15:41:58 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 03:17:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,471,1534834800"; d="asc'?scan'208";a="105680863" Received: from pipin.fi.intel.com (HELO localhost) ([10.237.72.128]) by fmsmga001.fm.intel.com with ESMTP; 06 Nov 2018 03:17:11 -0800 From: Felipe Balbi To: Laurent Pinchart , Alan Stern Cc: Paul Elder , Bin Liu , kieran.bingham@ideasonboard.com, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, rogerq@ti.com Subject: Re: [PATCH 4/6] usb: gadget: add functions to signal udc driver to delay status stage In-Reply-To: <3595344.euAgJ7Kpbg@avalon> References: <3595344.euAgJ7Kpbg@avalon> Date: Tue, 06 Nov 2018 13:17:07 +0200 Message-ID: <87d0riv4jw.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, Laurent Pinchart writes: >> >>>> Furthermore, we have found that USB_GADGET_DELAYED_STATUS is racey, >> >>>> which has already been observed in the UVC gadget driver previously >> >>>> [0]. The raceiness stems from the fact that things can happen in >> >>>> between returning USB_GADGET_DELAYED_STATUS and the composite layer >> >>>> reacting to it - especially if usb_composite_setup_continue is call= ed >> >>>> within that window it causes a WARN. In any case, the fact that the >> >>>> mechanism itself is racey suggests that it needs improvement, and u= sing >> >>>> it wouldn't be a good solution in this case. >>=20 >> I don't understand this at all. The composite layer reacts to >> USB_GADGET_DELAYED_STATUS as soon as it receives the return value. Can >> Paul or Laurent give a more explicit example of this race? > > The composite layer only handles USB_GADGET_DELAYED_STATUS for=20 > USB_REQ_SET_CONFIGURATION (in set_config()) and for USB_REQ_SET_INTERFACE= (in=20 > composite_setup()). It increments cdev->delayed_status immediately. Then,= in=20 > usb_composite_setup_continue(), if cdev->delayed_status is not zero, it q= ueues=20 > a ZLP, and warns otherwise. > > This mechanism delays the data stage, not the status stage (or, to be pre= cise,=20 > it delays the status stage insofar as the status stage comes after the da= ta=20 > stage), and only supports control OUT requests with 0 bytes of data (whic= h is=20 > the case of both USB_REQ_SET_INTERFACE and USB_REQ_SET_CONFIGURATION). Fo= r all=20 > other requests, the composite layer passes USB_GADGET_DELAYED_STATUS to t= he=20 > UDC. DATA stage always depends on a usb_ep_queue() from gadget driver. So it's always "delayed" in that sense. > The three UDCs that implement USB_GADGET_DELAYED_STATUS support set a=20 > delayed_status flag in an internal structure. I haven't inspected in deta= ils=20 > what they do next as I'm not familiar with all of them, but the dwc3 driv= er=20 > just skips the handling of the status phase in dwc3_ep0_xfernotready() an= d=20 > delays it to __dwc3_gadget_ep0_queue(). This only works for 0-length requ= ests,=20 > with no data phase. data stage always depends on usb_ep_queue(). There was never any need for UDC to handle Data stage internally. Also, status stage is always a ZLP. > Even when limited to 0-length control OUT requests, this mechanism is rac= y.=20 > The setup handler, when it wants to delay the status phase, will queue=20 > asynchronous work that will, when it completes, call=20 > usb_composite_setup_continue() to proceed with the status phase. Queuing = the=20 > work has to be done before the setup handler returns, and the cdev- >>delayed_status is only incremented after the setup handler returns, in=20 > composite_setup(). There is thus a time window during which the asynchron= ous=20 > work can call usb_composite_setup_continue() before cdev->delayed_status = has=20 > been incremented. We have managed to hit this in practice, with a surpris= ingly=20 > high rate seeing how small the window is. that's only the case because we have two different "modes" for this. One where UDC handles it internally and another where gadget driver has to queue a request. I'm vouching for making status stage always explicit, i.e. we should always expect a usb_ep_queue(). > Now that I've written all this, I realize that cdev->delayed_status is gu= arded=20 > by cdev->lock. I thus wonder whether our analysis was correct, or if we w= ere=20 > hitting a different bug :-S Paul, could you test this again ? Please note= ,=20 > however, that the race described here is not related to this patch series= ,=20 > except in how it influences the API design to avoid race conditions. > >> Assuming you are correct, wouldn't it make sense to fix or eliminate >> the race by changing composite.c? > > I was about to write that we would need to lock access to cdev- >>delayed_status, and found out that we already use cdev->lock to do so. Mo= re=20 > investigations are needed. > > Please note, however, that USB_GADGET_DELAYED_STATUS is limited to 0-leng= th=20 > control OUT requests, so the problem that led to this patch series still= =20 > exists, even if the race condition I thought was there doesn't exist. And that problem is...? DATA stage always depends on a usb_ep_queue() from gadget driver. >> >> If this works with dwc3 + uvc, then we have a good recipe on how to >> >> implement for the other drivers. >> >=20 >> > Given that we need to delay the status stage and not the data stage, we >> > can't explicitly request the status stage through a usb request queue. >>=20 >> Why not? The status stage for a control-OUT transfer is simply a >> zero-length IN transaction. It's easy to queue a request for such a >> transaction. Is the issue that there's no way to specify the direction >> of the request (hence no direct way to tell whether a zero-length >> request is for the data stage or the status stage)? > > OK, I suppose we could queue a request for this, in which case we would h= ave=20 > to queue two requests for control OUT transfers (one for the data stage a= nd=20 > one for the status stage). I'm however not convinced that would be the be= st=20 that's correct. This is what "make status stage always explicit" mean :) > API to handle the status stage, as the function driver would need to queu= e a=20 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... > request and the UDC would then need to check whether that request corresp= onds=20 > to a status stage and process it accordingly. A new operation specific to= this=20 no, it wouldn't. UDC would have to check the size of request, that's all: if (r->length =3D=3D 0) special_zlp_handling(); else regular_non_zlp_handling(); 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) > would be easier for both the function driver and the UDC in my opinion.=20 it wouldn't. We would just be moving the special case to another function, rather than eliminating it. > There's also the fact that requests can specify a completion handler, but= only=20 > the data stage request would see its completion handler called (unless we= =20 > require UDCs to call completion requests at the completion of the status= =20 > stage, but I'm not sure that all UDCs can report the event to the driver,= and=20 > 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. 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 >> Admittedly, it might be nice to provide a library routine in the UDC >> core to queue such requests, since it involves a bunch of uninteresting >> boilerplate operations. >>=20 >> > Would a new explicit function call work for you for that purpose ? >>=20 >> It would be okay, but I question whether one is really needed. > > I think the API would be cleaner, but it might just be a matter of taste. From=20a UDC perspective, I'm more inclined to removing special cases, rather than making them more apparent. Having a single method for handling all three stages of a control transfer, IMO, is far more beneficial as it removes magic return values and several branches on UDC driver. >> >>> - The mechanism is poorly documented. As Paul mentioned, comments in >> >>> the code state that USB_GADGET_DELAYED_STATUS delay the "data/status >> >>> stages". This is very unclear, and the only three UDCs that implement >> >>> the mechanism seem to do so in different ways: >>=20 >> We can fix comments and documentation pretty easily. :-) > > It's harder to fix them if different implementations interpret them in=20 > different ways :-) That might not be the case though, as mentioned above = I=20 that's where a proper audit of the code comes into play :) > haven't studied the three UDCs that implement this in details, I only had= a=20 > look at the dwc3. that's perfectly fine. We can Cc other folks involved with the other UDCs and have them chip in. >> This requires the UDC to specifically keep track of the direction of >> the current transfer and whether or not a data-stage transfer has >> already been queued. That shouldn't be hard. > > It's "just" a state machine so it wouldn't be too hard. What we need to a= gree=20 > on is how the state machine operates, and then the API to control it. Tha= t's=20 > what I tried to describe below in my previous e-mail. > >> (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. Driver is already required to handle stalls for several other conditions. If thehre are bugs in that area, I'd prefer catching them. >> > I wonder if there's really a use case for delaying the data stage of >> > control OUT requests, as it seems to me that we can perform the >> > asynchronous validation of the setup and data stages together, in which >> > case we would always proceed to the data stage, and only potentially >> > delay the status stage. However, if we switch to an explicit API where >> > the transition from the setup to the data stage is triggered by queuei= ng >> > a request, and given that such a transition may need to be delayed for >> > the control IN case, delaying the data stage for control OUT would >> > essentially come for free. > > What do you think about this ? Should we allow function drivers to delay = the=20 > data stage of control OUT requests ? it's already delayed. UDC won't start data stage unless it has a buffer to put the data. Without a usb_ep_queue(), UDC doesn't have a buffer. >> > If we end up moving to explicit state handling, with the data stage be= ing >> > entered by queueing a request, and the status stage being entered by >> > calling a new function, control OUT requests with 0 bytes of data that >> > can be handled synchronously in the setup handler would require functi= on >> > drivers to both queue a zero-length request and call the status functi= on. >> > This would make the function code more complex, and I wonder whether a >> > shortcut would be a good idea, perhaps in the form of a flag in the >> > request that tells the UDC to automatically proceed to the status stage >> > immediately after the data stage. Or we could make that behaviour the >> > default when the request doesn't have a completion handler (as moving >> > explicitly to the status stage should be done at the earliest from the >> > data stage completion handler). > > From an API point of view, towards function drivers, I really want an exp= licit=20 > function to proceed with the status stage. That could internally queue a = ZLP=20 > request or call another API, but in any case I don't want the status stag= e ZLP=20 > request to be visible to the function drivers. Do you agree with this ? why can't it be visible? I don't mind having a function wrapping usb_ep_queue(), but why is it bad to have functions call usb_ep_queue() directly? > To simplify function drivers, do you think the above proposal of adding a= flag=20 > to the (data stage) request to request an automatic transition to the sta= tus=20 > stage is a good idea ? We could even possibly invert the logic and transi= tion=20 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. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAlvheDMACgkQzL64meEa mQbqIw/+OxXDZuCyjq5oKFpo8zmeM09kv+BBTYhMqdeRncaDfMAeZqZhrbYgz02n OgtGy+PUBodFxWI23hbE1HdtaZ+xIUkHisTVJ8lJsaPyqoKp21ICbv/XOD0yEdao aHAakUGemPRNWEyLmeILUZNL2IVJqBmnBTfXjT01sX7oRnv5w4bHuG8LqR6kZRzm qNJhpgnpOE94smc4HvdG2I3V/jJ5Sg7XR8m3QiRyEKbO1ffeO+3kU5cseoD2qlHp /SAOcQaPSYgM8RuBeGpOt4gUT3PaMMjhzcPK3JpHs6DSSKajqFh4rmyN+h7r1NG5 2BoX7T4nrGY6Uy/LixTrjustepwN1DQprbeSV91G7+77/se/HymcjBV5oS+Tpf/I PyEIeVgdiS8+23anhV5wmTA9qm1w2pe1hE8ebqsueQJSfFwG8hLN1cgxqNhnNJS7 A+/CABTTrIWcF3EihjyqpYx7pa5aPk2p3TQPGLedkE3nBM6SVQkJSwYO2MpgV0YV WSY8qR89LXDUtcszlIsorR8UKBw1UjClk8StFsi3zhC4ta6dtrh+XvXWO1rtQDg1 upglVYTXahMLd950c2zmpkSMcdfTl74RlIsLz3/GMQALTrQFC0RaI47XAPnicGfl GUDSDwkuIdHgTdXka6+EQjdN8aXIREUZeRGLYCO8YobOG9vCyeM= =cBEn -----END PGP SIGNATURE----- --=-=-=--