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: Laurent Pinchart Message-Id: <2683135.rrYvd4LdR5@avalon> Date: Fri, 02 Nov 2018 14:44:55 +0200 To: Paul Elder Cc: Alan Stern , Bin Liu , kieran.bingham@ideasonboard.com, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, balbi@kernel.org, rogerq@ti.com List-ID: SGVsbG8sCgpPbiBGcmlkYXksIDIgTm92ZW1iZXIgMjAxOCAwMTo0MDo1OSBFRVQgUGF1bCBFbGRl ciB3cm90ZToKPiBPbiBUaHUsIE9jdCAxOCwgMjAxOCBhdCAxMDowNzozNkFNIC0wNDAwLCBBbGFu IFN0ZXJuIHdyb3RlOgo+ID4gT24gVGh1LCAxOCBPY3QgMjAxOCwgTGF1cmVudCBQaW5jaGFydCB3 cm90ZToKPiA+PiBPbiBUaHVyc2RheSwgMTEgT2N0b2JlciAyMDE4IDE5OjEwOjIxIEVFU1QgQmlu IExpdSB3cm90ZToKPiA+Pj4gT24gVHVlLCBPY3QgMDksIDIwMTggYXQgMTA6NDk6MDFQTSAtMDQw MCwgUGF1bCBFbGRlciB3cm90ZToKPiA+Pj4+IEEgdXNiIGdhZGdldCBmdW5jdGlvbiBkcml2ZXIg bWF5IG9yIG1heSBub3Qgd2FudCB0byBkZWxheSB0aGUgc3RhdHVzCj4gPj4+PiBzdGFnZSBvZiBh IGNvbnRyb2wgT1VUIHJlcXVlc3QuIEFuIGluc3RhbmNlIGl0IG1pZ2h0IHdhbnQgdG8gaXMgdG8K PiA+Pj4+IGFzeW5jaHJvbm91c2x5IHZhbGlkYXRlIHRoZSBkYXRhIG9mIGEgY2xhc3Mtc3BlY2lm aWMgcmVxdWVzdC4KPiA+Pj4+IAo+ID4+Pj4gQWRkIGEgZnVuY3Rpb24gdXNiX2VwX2RlbGF5X3N0 YXR1cyB0byBhbGxvdyBmdW5jdGlvbiBkcml2ZXJzIHRvCj4gPj4+PiBjaG9vc2UgdG8gZGVsYXkg dGhlIHN0YXR1cyBzdGFnZSBpbiB0aGUgcmVxdWVzdCBjb21wbGV0aW9uIGhhbmRsZXIuCj4gPj4+ PiBUaGUgVURDIHNob3VsZCB0aGVuIGNoZWNrIHRoZSB1c2JfZXAtPmRlbGF5ZWRfc3RhdHVzIGZs YWcgYW5kIGFjdAo+ID4+Pj4gYWNjb3JkaW5nbHkgdG8gZGVsYXkgdGhlIHN0YXR1cyBzdGFnZS4K PiA+Pj4+IAo+ID4+Pj4gQWxzbyBhZGQgYSBmdW5jdGlvbiB1c2JfZXBfc2VuZF9yZXNwb25zZSBh cyBhIHdyYXBwZXIgZm9yCj4gPj4+PiB1c2JfZXAtPm9wcy0+c2VuZF9yZXNwb25zZSwgd2hvc2Ug cHJvdG90eXBlIGlzIGFkZGVkIGFzIHdlbGwuIFRoaXMKPiA+Pj4+IGZ1bmN0aW9uIHNob3VsZCBi ZSBjYWxsZWQgYnkgZnVuY3Rpb24gZHJpdmVycyB0byB0ZWxsIHRoZSBVREMgd2hhdAo+ID4+Pj4g dG8gcmVwbHkgaW4gdGhlIHN0YXR1cyBzdGFnZSB0aGF0IGl0IGhhcyByZXF1ZXN0ZWQgdG8gYmUg ZGVsYXllZC4KPiA+Pj4+IAo+ID4+Pj4gU2lnbmVkLW9mZi1ieTogUGF1bCBFbGRlciA8cGF1bC5l bGRlckBpZGVhc29uYm9hcmQuY29tPgo+ID4+Pj4gUmV2aWV3ZWQtYnk6IExhdXJlbnQgUGluY2hh cnQgPGxhdXJlbnQucGluY2hhcnRAaWRlYXNvbmJvYXJkLmNvbT4KPiA+Pj4+IC0tLQo+ID4+Pj4g Cj4gPj4+PiAgZHJpdmVycy91c2IvZ2FkZ2V0L3VkYy9jb3JlLmMgfCAzNSArKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKwo+ID4+Pj4gIGluY2x1ZGUvbGludXgvdXNiL2dhZGdldC5oICAg IHwgMTEgKysrKysrKysrKysKPiA+Pj4+ICAyIGZpbGVzIGNoYW5nZWQsIDQ2IGluc2VydGlvbnMo KykKPiA+Pj4+IAo+ID4+Pj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvdXNiL2dhZGdldC91ZGMvY29y ZS5jCj4gPj4+PiBiL2RyaXZlcnMvdXNiL2dhZGdldC91ZGMvY29yZS5jCj4gPj4+PiBpbmRleCBh Zjg4YjQ4YzFjZWEuLjFlYzVjZTZiNDNjZCAxMDA2NDQKPiA+Pj4+IC0tLSBhL2RyaXZlcnMvdXNi L2dhZGdldC91ZGMvY29yZS5jCj4gPj4+PiArKysgYi9kcml2ZXJzL3VzYi9nYWRnZXQvdWRjL2Nv cmUuYwo+ID4+Pj4gQEAgLTQ0Myw2ICs0NDMsNDEgQEAgdm9pZCB1c2JfZXBfZmlmb19mbHVzaChz dHJ1Y3QgdXNiX2VwICplcCkKPiA+Pj4+IAo+ID4+Pj4gIH0KPiA+Pj4+ICBFWFBPUlRfU1lNQk9M X0dQTCh1c2JfZXBfZmlmb19mbHVzaCk7Cj4gPj4+PiAKPiA+Pj4+ICsvKioKPiA+Pj4+ICsgKiB1 c2JfZXBfZXBfZGVsYXlfc3RhdHVzIC0gc2V0IGRlbGF5X3N0YXR1cyBmbGFnCj4gPj4+PiArICog QGVwOiB0aGUgZW5kcG9pbnQgd2hvc2UgZGVsYXlfc3RhdHVzIGZsYWcgaXMgYmVpbmcgc2V0Cj4g Pj4+PiArICoKPiA+Pj4+ICsgKiBUaGlzIGZ1bmN0aW9uIGluc3RydWN0cyB0aGUgVURDIHRvIGRl bGF5IHRoZSBzdGF0dXMgc3RhZ2Ugb2YgYQo+ID4+Pj4gY29udHJvbAo+ID4+Pj4gKyAqIHJlcXVl c3QuIEl0IGNhbiBvbmx5IGJlIGNhbGxlZCBmcm9tIHRoZSByZXF1ZXN0IGNvbXBsZXRpb24KPiA+ Pj4+IGhhbmRsZXIgb2YgYQo+ID4+Pj4gKyAqIGNvbnRyb2wgcmVxdWVzdC4KPiA+Pj4+ICsgKi8K PiA+Pj4+ICt2b2lkIHVzYl9lcF9kZWxheV9zdGF0dXMoc3RydWN0IHVzYl9lcCAqZXApCj4gPj4+ PiArewo+ID4+Pj4gKwllcC0+ZGVsYXllZF9zdGF0dXMgPSB0cnVlOwo+ID4+Pj4gK30KPiA+Pj4+ ICtFWFBPUlRfU1lNQk9MX0dQTCh1c2JfZXBfZGVsYXlfc3RhdHVzKTsKPiA+Pj4gCj4gPj4+IElz IHVzYl9lcF9zZXRfZGVsYXlfc3RhdHVzKCkgYmV0dGVyPyBJIHRob3VnaHQgaXQgaW1wbGllcyBn ZXQvcmV0dXJuCj4gPj4+IGFjdGlvbiBpZiBhIHZlcmIgaXMgbWlzc2luZyBpbiB0aGUgZnVuY3Rp b24gbmFtZS4KPiA+PiAKPiA+PiBGb3Igd2hhdCBpdCdzIHdvcnRoLCBJIHVuZGVyc3RhbmQgdGhl IGZ1bmN0aW9uIG5hbWUgYXMgImRlbGF5IHRoZSBzdGF0dXMKPiA+PiBzdGFnZSIsIHdpdGggImRl bGF5IiBiZWluZyBhIHZlcmIuIE1heWJlIHRoZSBzaG9ydCBkZXNjcmlwdGlvbiBjb3VsZCBiZQo+ ID4+IHVwZGF0ZWQgYWNjb3JkaW5nbHkuCj4gPiAKPiA+IElzIHRoZXJlIGEgcmVhc29uIGZvciBh ZGRpbmcgYSBuZXcgZnVuY3Rpb24gZm9yIHRoaXM/ICBUaGlzIGlzIGV4YWN0bHkKPiA+IHdoYXQg dGhlIFVTQl9HQURHRVRfREVMQVlFRF9TVEFUVVMgcmV0dXJuIHZhbHVlIGZyb20gdGhlIHNldHVw IGNhbGxiYWNrCj4gPiBpcyBtZWFudCBmb3IgKGFuZCBpdCBpcyBhbHJlYWR5IHVzZWQgYnkgc29t ZSBnYWRnZXQgZHJpdmVycykuCj4gCj4gSW4gdGhlb3J5LCB3ZSBtaWdodCBiZSBhYmxlIHRvIHVz ZSBVU0JfR0FER0VUX0RFTEFZRURfU1RBVFVTIGZvciB0aGlzLgo+IEhvd2V2ZXIsIHRoZXJlIGFy ZSBhIGZldyBhbWJpZ3VpdGllcyB0aGF0IHByZXZlbnQgdXMgZnJvbSBkb2luZyBzby4KPiAKPiBG aXJzdCBvZiBhbGwsIHdlIHdhbnQgdG8gZGVsYXkgb25seSB0aGUgc3RhdHVzIHN0YWdlIGZvciBj b250cm9sIE9VVAo+IHJlcXVlc3RzOyBhY2NvcmRpbmcgdG8gY29tcG9zaXRlLmgsIFVTQl9HQURH RVRfREVMQVlFRF9TVEFUVVMgaXMgZm9yCj4gZGVsYXlpbmcgdGhlICJkYXRhL3N0YXR1cyBzdGFn ZXMiLiBEb2VzIHRoaXMgbWVhbiB0aGF0IGl0IGRlbGF5cyB0aGUKPiBzdGF0dXMgc3RhZ2Ugb25s eSBvciBkb2VzIGl0IGRlbGF5IGJvdGggc3RhZ2VzPyBJZiB0aGUgc2xhc2ggbWVhbnMKPiAiYW5k IiwgdGhlbiB3ZSBjYW5ub3QgdXNlIFVTQl9HQURHRVRfREVMQVlFRF9TVEFUVVMuCj4gCj4gRnVy dGhlcm1vcmUsIHdlIGhhdmUgZm91bmQgdGhhdCBVU0JfR0FER0VUX0RFTEFZRURfU1RBVFVTIGlz IHJhY2V5LAo+IHdoaWNoIGhhcyBhbHJlYWR5IGJlZW4gb2JzZXJ2ZWQgaW4gdGhlIFVWQyBnYWRn ZXQgZHJpdmVyIHByZXZpb3VzbHkgWzBdLgo+IFRoZSByYWNlaW5lc3Mgc3RlbXMgZnJvbSB0aGUg ZmFjdCB0aGF0IHRoaW5ncyBjYW4gaGFwcGVuIGluIGJldHdlZW4KPiByZXR1cm5pbmcgVVNCX0dB REdFVF9ERUxBWUVEX1NUQVRVUyBhbmQgdGhlIGNvbXBvc2l0ZSBsYXllciByZWFjdGluZyB0bwo+ IGl0IC0gZXNwZWNpYWxseSBpZiB1c2JfY29tcG9zaXRlX3NldHVwX2NvbnRpbnVlIGlzIGNhbGxl ZCB3aXRoaW4gdGhhdAo+IHdpbmRvdyBpdCBjYXVzZXMgYSBXQVJOLiBJbiBhbnkgY2FzZSwgdGhl IGZhY3QgdGhhdCB0aGUgbWVjaGFuaXNtIGl0c2VsZgo+IGlzIHJhY2V5IHN1Z2dlc3RzIHRoYXQg aXQgbmVlZHMgaW1wcm92ZW1lbnQsIGFuZCB1c2luZyBpdCB3b3VsZG4ndCBiZSBhCj4gZ29vZCBz b2x1dGlvbiBpbiB0aGlzIGNhc2UuCj4gCj4gPiBJcyBpdCBhIHF1ZXN0aW9uIG9mIHdoZW4gdGhl IGdhZGdldCBkcml2ZXIgbGVhcm5zIHRoYXQgaXQgd2lsbCBuZWVkIHRvCj4gPiBkZWxheSB0aGUg c3RhdHVzIHN0YWdlPyAgSWYgdGhhdCdzIHRoZSBjYXNlLAo+IAo+IE5vdCByZWFsbHkuCj4gCj4g PiB3aHkgbm90IGFsd2F5cyByZXR1cm4KPiA+IFVTQl9HQURHRVRfREVMQVlFRF9TVEFUVVMgZnJv bSB0aGUgc2V0dXAgY2FsbGJhY2s/ICBUaGVuIGluc3RlYWQgb2YKPiA+IGNhbGxpbmcgdXNiX2Vw X2RlbGF5X3N0YXR1cygpIHdoZW4gYSBkZWxheSBpcyBuZWVkZWQsIHlvdSBjb3VsZCBxdWV1ZQo+ ID4gdGhlIHN0YXR1cyByZXF1ZXN0IHdoZW4gYSBkZWxheSBpc24ndCBuZWVkZWQuCj4gCj4gVGhl b3JldGljYWxseSB0aGlzIG1pZ2h0IHdvcmssIGJ1dCBzZWUgdGhlIHByb2JsZW1zIG1lbnRpb25l ZCBhYm92ZS4KPiAKPiA+IEFzIGEgbW9yZSBnZW5lcmFsIHNvbHV0aW9uLCBGZWxpcGUgaGFzIHNh aWQgdGhhdCBhIFVEQyBkcml2ZXIgc2hvdWxkCj4gPiBfbmV2ZXJfIGNhcnJ5IG91dCB0aGUgc3Rh dHVzIHN0YWdlIHRyYW5zYWN0aW9uIHVudGlsIHRoZSBnYWRnZXQgZHJpdmVyCj4gPiBoYXMgdG9s ZCBpdCB0byBkbyBzby4gIFRoZW4gdGhlcmUgd291bGQgYmUgbm8gbmVlZCBmb3IgYW55IHNvcnQg b2YKPiA+IGRlbGF5IGluZGljYXRvci4KPiAKPiBZZWFoLCBidXQsCj4gCj4gPiAoQnV0IGltcGxl bWVudGluZyB0aGlzIHdvdWxkIHJlcXVpcmUgc2lnbmlmaWNhbnQKPiA+IGNoYW5nZXMgdG8gYSBi dW5jaCBvZiBkaWZmZXJlbnQgZHJpdmVycy4uLikKPiAKPiBleGFjdGx5IDovCj4gCj4gWzBdIGh0 dHBzOi8vd3d3LnNwaW5pY3MubmV0L2xpc3RzL2xpbnV4LXVzYi9tc2cxNjkyMDguaHRtbAoKQWxh biwgRmVsaXBlLCBob3cgZG8gd2UgbW92ZSBmb3J3YXJkIHdpdGggdGhpcyA/IFRoZXJlIGFyZSBz ZXZlcmFsIGlzc3VlcyB3aXRoIAp0aGUgZXhpc3RpbmcgY29udHJvbCByZXF1ZXN0IGhhbmRsaW5n IG1lY2hhbmlzbSBpbiB0aGUgVVNCIGdhZGdldCBzdGFjaywgYW5kIAp3aGlsZSBQYXVsIGNvdWxk IHdvcmsgb24gaW1wcm92aW5nIHRoZSBtZWNoYW5pc20sIHdlIG5lZWQgdG8gcHJvdmlkZSBjbGVh ciAKZ3VpZGFuY2UgcmVnYXJkaW5nIHRoZSBkaXJlY3Rpb24gd2Ugd2FudCB0byB0YWtlLgoKRm9y IHJlZmVyZW5jZSwgdGhlIGlzc3VlcyBJIGtub3cgYWJvdXQgZm9yIHRoZSBVU0JfR0FER0VUX0RF TEFZRURfU1RBVFVTIAptZWNoYW5pc20gYXJlCgotIFRoZSBtZWNoYW5pc20gaXMgaW5oZXJlbnRs eSByYWN5LiBJdCByZWxpZXMgb24gc2lnbmFsaW5nIHRoZSBkZWxheSBhdCB0aGUgCnZlcnkgZW5k IG9mIHRoZSBwcm9jZXNzaW5nIGluIHRoZSBzZXR1cCBoYW5kbGVyLCB3aGljaCBieSBkZWZpbml0 aW9uIG9jY3VycyAKYWZ0ZXIgdGhlIHdvcmsgdG8gcHJvY2VzcyB0aGUgY29udHJvbCByZXF1ZXN0 IGlzIHF1ZXVlZCAoaW4gdGhlIGdlbmVyaWMgc2Vuc2UsIApyZWdhcmRsZXNzIG9mIHdoZXRoZXIg dGhpcyBpbnZvbHZlcyBhIGtlcm5lbCB3b3JrcXVldWUgb3IgcGFzc2luZyB0aGUgd29yayB0byAK dXNlcnNwYWNlKS4gVGhlcmUgaXMgdGh1cyBhIHJhY2Ugd2luZG93IGFmdGVyIHF1ZXVpbmcgdGhl IHdvcmsgYW5kIGJlZm9yZSAKc2lnbmFsaW5nIHRoZSBkZWxheSBkdXJpbmcgd2hpY2ggdGhlIHdv cmsgaGFuZGxlciBjb3VsZCBzaWduYWwgY29tcGxldGlvbi4KCi0gVGhlIG1lY2hhbmlzbSBpcyBw b29ybHkgZG9jdW1lbnRlZC4gQXMgUGF1bCBtZW50aW9uZWQsIGNvbW1lbnRzIGluIHRoZSBjb2Rl IApzdGF0ZSB0aGF0IFVTQl9HQURHRVRfREVMQVlFRF9TVEFUVVMgZGVsYXkgdGhlICJkYXRhL3N0 YXR1cyBzdGFnZXMiLiBUaGlzIGlzIAp2ZXJ5IHVuY2xlYXIsIGFuZCB0aGUgb25seSB0aHJlZSBV RENzIHRoYXQgaW1wbGVtZW50IHRoZSBtZWNoYW5pc20gc2VlbSB0byBkbyAKc28gaW4gZGlmZmVy ZW50IHdheXM6CgogIC0gVGhlIG10dSBkcml2ZXIgc3RhdGVzIGluIGEgY29tbWVudCB0aGF0IGl0 IHdpbGwgImhhbmRsZSB0aGUgZGVsYXkgU1RBVFVTIApwaGFzZSB0aWxsIHJlY2VpdmUgZXBfcXVl dWUgb24gZXAwIi4KCiAgLSBUaGUgYmRjIGRyaXZlciBzdGF0ZXMgaW4gYSBjb21tZW50IHRoYXQg IlRoZSBlcDAgc3RhdGUgd2lsbCByZW1haW4gCldBSVRfRk9SX0RBVEFfU1RBUlQgdGlsbCB3ZSBy ZWNlaXZlZCBlcF9xdWV1ZSBvbiBlcDAiLgoKICAtIFRoZSBkd2MzIGRyaXZlciBzZWVtcyB0byBo YW5kbGUgVVNCX0dBREdFVF9ERUxBWUVEX1NUQVRVUyBmb3IgdGhlIApTRVRfQ09ORklHIHJlcXVl c3Qgb25seS4KCi0gVGhlIG1lY2hhbmlzbSByZWxpZXMgb24gcXVldWVpbmcgYSByZXF1ZXN0IHRv IHRoZSBVREMgdG8gc2lnbmFsIHRoYXQgaXQgCnNob3VsZCBjb250aW51ZSB3aXRoIHRoZSBzdGF0 dXMgc3RhZ2UuIFRoYXQgcmVxdWVzdCBjYW4gYmUgcXVldWVkIGVpdGhlciBieSAKdGhlIFVTQiBn YWRnZXQgZnVuY3Rpb24gZHJpdmVyIGRpcmVjdGx5LCBvciBieSB0aGUgY29tcG9zaXRlIGxheWVy IGluIAp1c2JfY29tcG9zaXRlX3NldHVwX2NvbnRpbnVlKCkgKHRoZSBsYXR0ZXIgaXMgcmVzdHJp Y3RlZCB0byByZXF1ZXN0cyB0aGF0IApjYXJyeSBubyBkYXRhIGFzIGl0IHNldHMgdGhlIHJlcXVl c3QgbGVuZ3RoIHRvIDApLiBUaGlzIGlzIHByb2JsZW1hdGljIGlmIHdlIAp3YW50IHRvIGRlbGF5 IHRoZSBzdGF0dXMgcGhhc2UgYWZ0ZXIgY29tcGxldGluZyB0aGUgZGF0YSBwaGFzZSwgaW4gb3Jk ZXIgdG8gCnZhbGlkYXRlIHRoZSBzZXR1cCBwaGFzZSBkYXRhIGFuZCB0aGUgZGF0YSBwaGFzZSBk YXRhIChmb3IgYSBjb250cm9sIE9VVCAKcmVxdWVzdCkgdG9nZXRoZXIuCgoKRm9yIHRob3NlIHJl YXNvbnMgSSB0aGluayBhIG5ldyBtZWNoYW5pc20gaXMgbmVlZGVkLiBJdCBzaG91bGQgZWl0aGVy IHNpZ25hbCAKdGhlIHN0YXR1cyBwaGFzZSBkZWxheSB0aHJvdWdoIGFuIGV4cGxpY2l0IGZ1bmN0 aW9uIGNhbGwgaW5zdGVhZCBvZiBhIHJldHVybiAKdmFsdWUgKHRvIHNvbHZlIHRoZSByYWNlIG1l bnRpb25lZCBhYm92ZSksIG9yIGJ5IHJlcXVpcmluZyBhbGwgcmVxdWVzdHMgdG8gYmUgCmV4cGxp Y2l0bHkgY29tcGxldGVkIChidXQgdGhhdCB3aWxsIHJlcXVpcmUgY2hhbmdpbmcgYWxsIFVTQiBm dW5jdGlvbiAKZHJpdmVycykuIEZ1cnRoZXJtb3JlLCB0aGUgbWVjaGFuaXNtIG5lZWQgdG8gc3Vw cG9ydCBkZWxheWluZyB0aGUgc3RhdHVzIHBoYXNlIAphZnRlciBxdWV1aW5nIHRoZSByZXF1ZXN0 IGZvciB0aGUgZGF0YSBwaGFzZSwgc28gd2UgbmVlZCBhbiBleHBsaWNpdCB3YXkgdG8gCnNpZ25h bCB0aGF0IHRoZSBVREMgc2hvdWxkIHByb2NlZWQgd2l0aCB0aGUgc3RhdHVzIHBoYXNlLCBvdGhl ciB0aGFuIHF1ZXVlaW5nIAp0aGUgcmVxdWVzdC4KClRob3VnaHRzID8gUHJlZmVyZW5jZXMgPwo= 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=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,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 77554C32789 for ; Fri, 2 Nov 2018 12:44:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 218722082E for ; Fri, 2 Nov 2018 12:44:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="AYbENIea" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 218722082E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com 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 S1727308AbeKBVvz (ORCPT ); Fri, 2 Nov 2018 17:51:55 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:41400 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726094AbeKBVvz (ORCPT ); Fri, 2 Nov 2018 17:51:55 -0400 Received: from avalon.localnet (dfj612ybrt5fhg77mgycy-3.rev.dnainternet.fi [IPv6:2001:14ba:21f5:5b00:2e86:4862:ef6a:2804]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 7E0E21263; Fri, 2 Nov 2018 13:44:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1541162689; bh=ioT0gc0zgmXjaCLgmsvz2MdRFpVVTX4Uk7SaK+uIXAg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AYbENIeaIMWtbZJyZIUMrGv9uGwF3ynZPF3ASW+DiCE/UGcdVRC1+ZVQt0IKwn45I meHEfx7Mpew0GQrPZImZ+fJWi58H81Wlz97pGSA3NddpDcBwqgilsZI3utyxq8wmWc kbQqVbcl8ikRgaJhuTmQDt3iq1MKE5El/t6OnXn8= From: Laurent Pinchart To: Paul Elder Cc: Alan Stern , Bin Liu , kieran.bingham@ideasonboard.com, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, balbi@kernel.org, rogerq@ti.com Subject: Re: [PATCH 4/6] usb: gadget: add functions to signal udc driver to delay status stage Date: Fri, 02 Nov 2018 14:44:55 +0200 Message-ID: <2683135.rrYvd4LdR5@avalon> Organization: Ideas on Board Oy In-Reply-To: <20181101234059.GA28068@garnet.amanokami.net> References: <3055233.Lvy0NcWSZ5@avalon> <20181101234059.GA28068@garnet.amanokami.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit 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 Hello, On Friday, 2 November 2018 01:40:59 EET Paul Elder wrote: > On Thu, Oct 18, 2018 at 10:07:36AM -0400, Alan Stern wrote: > > On Thu, 18 Oct 2018, Laurent Pinchart wrote: > >> 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). > > In theory, we might be able to use USB_GADGET_DELAYED_STATUS for this. > However, there are a few ambiguities that prevent us from doing so. > > First of all, we want to delay only the status stage for control OUT > requests; according to composite.h, USB_GADGET_DELAYED_STATUS is for > delaying the "data/status stages". Does this mean that it delays the > status stage only or does it delay both stages? If the slash means > "and", then we cannot use USB_GADGET_DELAYED_STATUS. > > 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 called within that > window it causes a WARN. In any case, the fact that the mechanism itself > is racey suggests that it needs improvement, and using it wouldn't be a > good solution in this case. > > > Is it a question of when the gadget driver learns that it will need to > > delay the status stage? If that's the case, > > Not really. > > > 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. > > Theoretically this might work, but see the problems mentioned above. > > > 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. > > Yeah, but, > > > (But implementing this would require significant > > changes to a bunch of different drivers...) > > exactly :/ > > [0] https://www.spinics.net/lists/linux-usb/msg169208.html Alan, Felipe, how do we move forward with this ? There are several issues with the existing control request handling mechanism in the USB gadget stack, and while Paul could work on improving the mechanism, we need to provide clear guidance regarding the direction we want to take. For reference, the issues I know about for the USB_GADGET_DELAYED_STATUS mechanism are - The mechanism is inherently racy. It relies on signaling the delay at the very end of the processing in the setup handler, which by definition occurs after the work to process the control request is queued (in the generic sense, regardless of whether this involves a kernel workqueue or passing the work to userspace). There is thus a race window after queuing the work and before signaling the delay during which the work handler could signal completion. - 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: - The mtu driver states in a comment that it will "handle the delay STATUS phase till receive ep_queue on ep0". - The bdc driver states in a comment that "The ep0 state will remain WAIT_FOR_DATA_START till we received ep_queue on ep0". - The dwc3 driver seems to handle USB_GADGET_DELAYED_STATUS for the SET_CONFIG request only. - The mechanism relies on queueing a request to the UDC to signal that it should continue with the status stage. That request can be queued either by the USB gadget function driver directly, or by the composite layer in usb_composite_setup_continue() (the latter is restricted to requests that carry no data as it sets the request length to 0). This is problematic if we want to delay the status phase after completing the data phase, in order to validate the setup phase data and the data phase data (for a control OUT request) together. For those reasons I think a new mechanism is needed. It should either signal the status phase delay through an explicit function call instead of a return value (to solve the race mentioned above), or by requiring all requests to be explicitly completed (but that will require changing all USB function drivers). Furthermore, the mechanism need to support delaying the status phase after queuing the request for the data phase, so we need an explicit way to signal that the UDC should proceed with the status phase, other than queueing the request. Thoughts ? Preferences ? -- Regards, Laurent Pinchart