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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS 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 EE1E0C0044C for ; Wed, 7 Nov 2018 16:23:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B78E920827 for ; Wed, 7 Nov 2018 16:23:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B78E920827 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rowland.harvard.edu 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 S1731356AbeKHByW (ORCPT ); Wed, 7 Nov 2018 20:54:22 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:47664 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1727546AbeKHByV (ORCPT ); Wed, 7 Nov 2018 20:54:21 -0500 Received: (qmail 3368 invoked by uid 2102); 7 Nov 2018 11:23:17 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Nov 2018 11:23:17 -0500 Date: Wed, 7 Nov 2018 11:23:17 -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: <87r2fxtlrj.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 Wed, 7 Nov 2018, Felipe Balbi wrote: > 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. > >> > >> 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). Hmmm. So there must be a mechanism for the driver to tell the hardware that the endpoint's ring should start up again, right? (I'm assuming the controller stops the ring when the SETUP is received, to avoid taking invalid actions for TRBs that are now out of date.) > >> > 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. > >> > >> 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. Yes, it doesn't make a lot of sense. However, STALLing the status stage of a control-OUT transfer does make sense, so we should be able to do it. The obvious approach is to call ep0's set_halt() method instead of submitting an explicit status request. > > Checking the length isn't enough. A data stage can have 0 length. > > apologies, I meant wLength, like so: > > len = le16_to_cpu(ctrl->wLength); > if (!len) { > dwc->three_stage_setup = false; > dwc->ep0_expect_in = false; > dwc->ep0_next_event = DWC3_EP0_NRDY_STATUS; > } else { > dwc->three_stage_setup = true; > dwc->ep0_expect_in = !!(ctrl->bRequestType & USB_DIR_IN); > dwc->ep0_next_event = DWC3_EP0_NRDY_DATA; > } Presumably you invert the value of ep0_expect_in and set ep0_next_event to DWC3_EP0_NRDY_STATUS when the next (data-stage) request is submitted for ep0. Okay. > special return values would be rendered uncessary if there's agreement > that status stage is always explicit. Why would need > USB_GADGET_DELAYED_STATUS if every case returns that? Agreed. > >> > 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? > > If you know your STATUS stage completed, you have a guarantee that your > previous control transfer is complete. It's a very clear signal that you > should prepare for more control transfers. That doesn't seem to make sense, because in reality you don't have this guarantee. Consider the following scenario: The host starts a control-IN transfer. You send the data-stage request succesfully and then submit the status-stage request. That request will complete before the host receives the ACK for its 0-length status OUT transaction. In fact, the host may never receive that ACK and so the transfer may never complete. Besides, you don't need a signal (clear or otherwise) to prepare for more control transfers. You should start preparing as soon as the status-stage request has been submitted. At that point, what else is there for you to do? For that matter, you should be prepared to receive a new setup callback at any time. The host doesn't have to wait for an old control transfer to complete before starting a new one. I just don't see any value in knowing the completion code of a status-stage request. > >> > 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. > > I don't follow what you mean here. Suppose we have a core library routine like this: void usb_gadget_control_complete(struct usb_gadget *gadget, unsigned int no_implicit_status, int status) { struct usb_request *req; if (no_implicit_status || status != 0) return; /* Send an implicit status-stage request for ep0 */ req = usb_ep_alloc_request(gadget->ep0, GFP_ATOMIC); if (req) { req->length = 0; req->no_implicit_status = 1; req->complete = /* req's deallocation routine */ usb_ep_queue(gadget->ep0, req, GFP_ATOMIC); } } Then all a UDC driver would need to do is call usb_gadget_control_complete() after invoking a control request's completion handler. The no_implicit_status and status arguments would be taken from the request that was just completed. With this one call added to each UDC, all the existing function drivers would work correctly. Even though they don't explicitly queue status-stage requests, the new routine will do so for them, transparently. Function drivers that want to handle their own status-stage requests explicitly will merely have to set the req->no_implicit_status bit. (We might or might not need to watch out for 0-length control-OUT transfers. Function drivers _do_ queue status-stage requests for those.) Alan Stern 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: Alan Stern Message-Id: Date: Wed, 7 Nov 2018 11:23:17 -0500 (EST) To: Felipe Balbi Cc: Laurent Pinchart , 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: T24gV2VkLCA3IE5vdiAyMDE4LCBGZWxpcGUgQmFsYmkgd3JvdGU6Cgo+IEhpLAo+IAo+IEFsYW4g U3Rlcm4gPHN0ZXJuQHJvd2xhbmQuaGFydmFyZC5lZHU+IHdyaXRlczoKPiA+PiBBbGFuIFN0ZXJu IDxzdGVybkByb3dsYW5kLmhhcnZhcmQuZWR1PiB3cml0ZXM6Cj4gPj4gPiBUaGVyZSdzIGEgc2lt aWxhciByYWNlIGF0IHRoZSBoYXJkd2FyZSBsZXZlbC4gIFdoYXQgaGFwcGVucyBpZiB0aGUKPiA+ PiA+IGNvbnRyb2xsZXIgcmVjZWl2ZXMgYSBuZXcgU0VUVVAgcGFja2V0IGFuZCBjb25jdXJyZW50 bHkgdGhlIGRyaXZlciBpcwo+ID4+ID4gc2V0dGluZyB1cCB0aGUgY29udHJvbGxlciByZWdpc3Rl cnMgZm9yIGEgcmVzcG9uc2UgdG8gYW4gZWFybGllcgo+ID4+ID4gU0VUVVA/ICBJIGRvbid0IGtu b3cgaG93IHJlYWwgY29udHJvbGxlcnMgaGFuZGxlIHRoaXMuCj4gPj4gCj4gPj4gVGhhdCdzIEhX IGltcGxlbWVudGF0aW9uIGRldGFpbC4gRFdDMywgZm9yIGluc3RhbmNlLCB3aWxsIGlnbm9yZSB0 aGUKPiA+PiBUUkJzIGFuZCByZXR1cm4gbWUgdGhlIHN0YXR1cyAic2V0dXAgcGFja2V0IHBlbmRp bmciLiBUaGVuIEkganVzdCBzdGFydAo+ID4+IGEgbmV3IFNFVFVQIFRSQi4KPiA+Cj4gPiBZb3Ug bWVhbiB0aGUgVURDIGhhcmR3YXJlIHNldHMgYSAic2V0dXAgcGVuZGluZyIgZmxhZyBpbiBzb21l IHJlZ2lzdGVyLAo+ID4gYW5kIHRoZW4gaWdub3JlcyBhbnkgYXR0ZW1wdHMgdG8gZG8gYW55dGhp bmcgd2l0aCBlcDAgdW50aWwgdGhlIGRyaXZlcgo+ID4gY2xlYXJzIHRoaXMgZmxhZz8KPiAKPiBZ ZXMsIGV4Y2VwdCB0aGF0IHRoZSAiZmxhZyIgaXMgYSBzdGF0dXMgb24gdGhlIFRSQiBpdHNlbGYg KFRSQiBpcyBkd2MzJ3MKPiBETUEgdHJhbnNmZXIgZGVzY3JpcHRvcikuCgpIbW1tLiAgU28gdGhl cmUgbXVzdCBiZSBhIG1lY2hhbmlzbSBmb3IgdGhlIGRyaXZlciB0byB0ZWxsIHRoZSBoYXJkd2Fy ZSAKdGhhdCB0aGUgZW5kcG9pbnQncyByaW5nIHNob3VsZCBzdGFydCB1cCBhZ2FpbiwgcmlnaHQ/ ICAoSSdtIGFzc3VtaW5nIAp0aGUgY29udHJvbGxlciBzdG9wcyB0aGUgcmluZyB3aGVuIHRoZSBT RVRVUCBpcyByZWNlaXZlZCwgdG8gYXZvaWQgCnRha2luZyBpbnZhbGlkIGFjdGlvbnMgZm9yIFRS QnMgdGhhdCBhcmUgbm93IG91dCBvZiBkYXRlLikKCgo+ID4+ID4gQW5vdGhlciB0aGluZyB3ZSBz aG91bGQgZG8gaXMgZ2l2ZSBmdW5jdGlvbiBkcml2ZXJzIGEgd2F5IHRvIHNlbmQgYQo+ID4+ID4g U1RBTEwgcmVzcG9uc2UgZm9yIHRoZSBzdGF0dXMgc3RhZ2UuICBDdXJyZW50bHkgdGhlcmUncyBu byB3YXkgdG8gZG8KPiA+PiA+IGl0LCBpZiBhIGRhdGEgc3RhZ2UgaXMgcHJlc2VudC4KPiA+PiAK PiA+PiBTdGF0dXMgc3RhZ2UgY2FuIG9ubHkgYmUgc3RhbGxlZCBpZiBob3N0IHRyaWVzIHRvIG1v dmUgZGF0YSBvbiB0aGUgd3JvbmcKPiA+PiBkaXJlY3Rpb24uCj4gPgo+ID4gVGhlIFVTQi0yIHNw ZWMgZGlzYWdyZWVzLiAgU2VlIFRhYmxlIDgtNyBpbiBzZWN0aW9uIDguNS4zLjEgYW5kIHRoZQo+ ID4gZm9sbG93aW5nIHBhcmFncmFwaHMuICAoQWx0aG91Z2gsIEkgY2FuJ3Qgc2VlIHdoeSBhIGZ1 bmN0aW9uIHdvdWxkIGV2ZXIKPiA+IGZhaWwgdG8gY29tcGxldGUgdGhlIGNvbW1hbmQgc2VxdWVu Y2UgZm9yIGEgY29udHJvbC1JTiB0cmFuc2ZlciBhZnRlcgo+ID4gdGhlIGRhdGEgaGFkIGFscmVh ZHkgYmVlbiBzZW50LikKPiAKPiBJIGNhbid0IHNlZSBob3cgd2UgY291bGQgZXZlciBTVEFMTCBh ZnRlciByZXR1cm5pbmcgdGhlIGRhdGEgcmVxdWVzdGVkCj4gYnkgdGhlIGhvc3QuIFNlZW1zIGxp a2UgdGhhdCB3YXNuJ3Qgd2VsbCB0aG91Z2h0IG91dC4KClllcywgaXQgZG9lc24ndCBtYWtlIGEg bG90IG9mIHNlbnNlLiAgSG93ZXZlciwgU1RBTExpbmcgdGhlIHN0YXR1cwpzdGFnZSBvZiBhIGNv bnRyb2wtT1VUIHRyYW5zZmVyIGRvZXMgbWFrZSBzZW5zZSwgc28gd2Ugc2hvdWxkIGJlIGFibGUK dG8gZG8gaXQuICBUaGUgb2J2aW91cyBhcHByb2FjaCBpcyB0byBjYWxsIGVwMCdzIHNldF9oYWx0 KCkgbWV0aG9kCmluc3RlYWQgb2Ygc3VibWl0dGluZyBhbiBleHBsaWNpdCBzdGF0dXMgcmVxdWVz dC4KCgo+ID4gQ2hlY2tpbmcgdGhlIGxlbmd0aCBpc24ndCBlbm91Z2guICBBIGRhdGEgc3RhZ2Ug Y2FuIGhhdmUgMCBsZW5ndGguCj4gCj4gYXBvbG9naWVzLCBJIG1lYW50IHdMZW5ndGgsIGxpa2Ug c286Cj4gCj4gCWxlbiA9IGxlMTZfdG9fY3B1KGN0cmwtPndMZW5ndGgpOwo+IAlpZiAoIWxlbikg ewo+IAkJZHdjLT50aHJlZV9zdGFnZV9zZXR1cCA9IGZhbHNlOwo+IAkJZHdjLT5lcDBfZXhwZWN0 X2luID0gZmFsc2U7Cj4gCQlkd2MtPmVwMF9uZXh0X2V2ZW50ID0gRFdDM19FUDBfTlJEWV9TVEFU VVM7Cj4gCX0gZWxzZSB7Cj4gCQlkd2MtPnRocmVlX3N0YWdlX3NldHVwID0gdHJ1ZTsKPiAJCWR3 Yy0+ZXAwX2V4cGVjdF9pbiA9ICEhKGN0cmwtPmJSZXF1ZXN0VHlwZSAmIFVTQl9ESVJfSU4pOwo+ IAkJZHdjLT5lcDBfbmV4dF9ldmVudCA9IERXQzNfRVAwX05SRFlfREFUQTsKPiAJfQoKUHJlc3Vt YWJseSB5b3UgaW52ZXJ0IHRoZSB2YWx1ZSBvZiBlcDBfZXhwZWN0X2luIGFuZCBzZXQgZXAwX25l eHRfZXZlbnQKdG8gRFdDM19FUDBfTlJEWV9TVEFUVVMgd2hlbiB0aGUgbmV4dCAoZGF0YS1zdGFn ZSkgcmVxdWVzdCBpcyBzdWJtaXR0ZWQKZm9yIGVwMC4gIE9rYXkuCgo+IHNwZWNpYWwgcmV0dXJu IHZhbHVlcyB3b3VsZCBiZSByZW5kZXJlZCB1bmNlc3NhcnkgaWYgdGhlcmUncyBhZ3JlZW1lbnQK PiB0aGF0IHN0YXR1cyBzdGFnZSBpcyBhbHdheXMgZXhwbGljaXQuIFdoeSB3b3VsZCBuZWVkCj4g VVNCX0dBREdFVF9ERUxBWUVEX1NUQVRVUyBpZiBldmVyeSBjYXNlIHJldHVybnMgdGhhdD8KCkFn cmVlZC4KCj4gPj4gPiBUaGVyZSdzIGFsc28gdGhlIGZhY3QgdGhhdCByZXF1ZXN0cyBjYW4gc3Bl Y2lmeSBhIGNvbXBsZXRpb24gaGFuZGxlciwgYnV0IG9ubHkgCj4gPj4gPiB0aGUgZGF0YSBzdGFn ZSByZXF1ZXN0IHdvdWxkIHNlZSBpdHMgY29tcGxldGlvbiBoYW5kbGVyIGNhbGxlZCAodW5sZXNz IHdlIAo+ID4+ID4gcmVxdWlyZSBVRENzIHRvIGNhbGwgY29tcGxldGlvbiByZXF1ZXN0cyBhdCB0 aGUgY29tcGxldGlvbiBvZiB0aGUgc3RhdHVzIAo+ID4+ID4gc3RhZ2UsIGJ1dCBJJ20gbm90IHN1 cmUgdGhhdCBhbGwgVURDcyBjYW4gcmVwb3J0IHRoZSBldmVudCB0byB0aGUgZHJpdmVyLCBhbmQg Cj4gPj4gPiB0aGF0IHdvdWxkIGxpa2VseSBiZSB1c2VsZXNzIGFzIG5vYm9keSBuZWVkcyB0aGF0 IGZlYXR1cmUpLgo+ID4+IAo+ID4+IHlvdSBzdGlsbCB3YW5uYSBrbm93IGlmIHRoZSBob3N0IGFj dHVhbGx5IHByb2Nlc3NlZCB5b3VyIHN0YXR1cwo+ID4+IHN0YWdlLiB1ZGMtY29yZSBjYW4gKGFu ZCBzaG91bGQpIHByb3ZpZGUgYSBnZW5lcmljIHN0YXR1cyBzdGFnZQo+ID4+IGNvbXBsZXRpb24g ZnVuY3Rpb24gd2hpY2gsIGF0IGEgbWluaW11bSwgYWlkcyB3aXRoIHNvbWUgdHJhY2Vwb2ludHMu Cj4gPgo+ID4gSGVscGluZyB3aXRoIHRyYWNlcG9pbnRzIGlzIGZpbmUuICBIb3dldmVyLCBJIGRv bid0IHRoaW5rIGZ1bmN0aW9uIAo+ID4gZHJpdmVycyByZWFsbHkgbmVlZCB0byBrbm93IHdoZXRo ZXIgdGhlIHN0YXR1cyBzdGFnZSB3YXMgcHJvY2Vzc2VkIGJ5IAo+ID4gdGhlIGhvc3QuICBDYW4g eW91IHBvaW50IG91dCBhbnkgZXhhbXBsZXMgd2hlcmUgc3VjaCBpbmZvcm1hdGlvbiB3b3VsZCAK PiA+IGJlIHVzZWZ1bD8KPiAKPiBJZiB5b3Uga25vdyB5b3VyIFNUQVRVUyBzdGFnZSBjb21wbGV0 ZWQsIHlvdSBoYXZlIGEgZ3VhcmFudGVlIHRoYXQgeW91cgo+IHByZXZpb3VzIGNvbnRyb2wgdHJh bnNmZXIgaXMgY29tcGxldGUuIEl0J3MgYSB2ZXJ5IGNsZWFyIHNpZ25hbCB0aGF0IHlvdQo+IHNo b3VsZCBwcmVwYXJlIGZvciBtb3JlIGNvbnRyb2wgdHJhbnNmZXJzLgoKVGhhdCBkb2Vzbid0IHNl ZW0gdG8gbWFrZSBzZW5zZSwgYmVjYXVzZSBpbiByZWFsaXR5IHlvdSBkb24ndCBoYXZlCnRoaXMg Z3VhcmFudGVlLiAgQ29uc2lkZXIgdGhlIGZvbGxvd2luZyBzY2VuYXJpbzogVGhlIGhvc3Qgc3Rh cnRzIGEKY29udHJvbC1JTiB0cmFuc2Zlci4gIFlvdSBzZW5kIHRoZSBkYXRhLXN0YWdlIHJlcXVl c3Qgc3VjY2VzZnVsbHkgYW5kCnRoZW4gc3VibWl0IHRoZSBzdGF0dXMtc3RhZ2UgcmVxdWVzdC4g IFRoYXQgcmVxdWVzdCB3aWxsIGNvbXBsZXRlCmJlZm9yZSB0aGUgaG9zdCByZWNlaXZlcyB0aGUg QUNLIGZvciBpdHMgMC1sZW5ndGggc3RhdHVzIE9VVAp0cmFuc2FjdGlvbi4gIEluIGZhY3QsIHRo ZSBob3N0IG1heSBuZXZlciByZWNlaXZlIHRoYXQgQUNLIGFuZCBzbyB0aGUKdHJhbnNmZXIgbWF5 IG5ldmVyIGNvbXBsZXRlLgoKQmVzaWRlcywgeW91IGRvbid0IG5lZWQgYSBzaWduYWwgKGNsZWFy IG9yIG90aGVyd2lzZSkgdG8gcHJlcGFyZSBmb3IKbW9yZSBjb250cm9sIHRyYW5zZmVycy4gIFlv dSBzaG91bGQgc3RhcnQgcHJlcGFyaW5nIGFzIHNvb24gYXMgdGhlCnN0YXR1cy1zdGFnZSByZXF1 ZXN0IGhhcyBiZWVuIHN1Ym1pdHRlZC4gIEF0IHRoYXQgcG9pbnQsIHdoYXQgZWxzZSBpcwp0aGVy ZSBmb3IgeW91IHRvIGRvPwoKRm9yIHRoYXQgbWF0dGVyLCB5b3Ugc2hvdWxkIGJlIHByZXBhcmVk IHRvIHJlY2VpdmUgYSBuZXcgc2V0dXAgY2FsbGJhY2sgCmF0IGFueSB0aW1lLiAgVGhlIGhvc3Qg ZG9lc24ndCBoYXZlIHRvIHdhaXQgZm9yIGFuIG9sZCBjb250cm9sIHRyYW5zZmVyIAp0byBjb21w bGV0ZSBiZWZvcmUgc3RhcnRpbmcgYSBuZXcgb25lLgoKSSBqdXN0IGRvbid0IHNlZSBhbnkgdmFs dWUgaW4ga25vd2luZyB0aGUgY29tcGxldGlvbiBjb2RlIG9mIGEKc3RhdHVzLXN0YWdlIHJlcXVl c3QuCgo+ID4+ID4gVG8gc2ltcGxpZnkgZnVuY3Rpb24gZHJpdmVycywgZG8geW91IHRoaW5rIHRo ZSBhYm92ZSBwcm9wb3NhbCBvZiBhZGRpbmcgYSBmbGFnIAo+ID4+ID4gdG8gdGhlIChkYXRhIHN0 YWdlKSByZXF1ZXN0IHRvIHJlcXVlc3QgYW4gYXV0b21hdGljIHRyYW5zaXRpb24gdG8gdGhlIHN0 YXR1cyAKPiA+PiA+IHN0YWdlIGlzIGEgZ29vZCBpZGVhID8gV2UgY291bGQgZXZlbiBwb3NzaWJs eSBpbnZlcnQgdGhlIGxvZ2ljIGFuZCB0cmFuc2l0aW9uIAo+ID4+IAo+ID4+IG5vLCBJIGRvbid0 IHRoaW5rIHNvLiBNYWtpbmcgdGhlIHN0YXR1cyBwaGFzZSBhbHdheXMgZXhwbGljaXQgaXMgZmFy Cj4gPj4gYmV0dGVyLiBVRENzIHdvbid0IGhhdmUgdG8gY2hlY2sgZmxhZ3MsIG9yIGFjdCBvbiBt YWdpYyByZXR1cm4KPiA+PiB2YWx1ZXMuIEl0IGp1c3Qgd29uJ3QgZG8gYW55dGhpbmcgdW50aWwg YSByZXF1ZXN0IGlzIHF1ZXVlZC4KPiA+Cj4gPiBJIGRvbid0IGFncmVlLiAgVGhpcyB3b3VsZCBi ZSBhIHNpbXBsZSB0ZXN0IGluIGEgbG9jYWxpemVkIGFyZWEgKHRoZSAKPiA+IGNvbXBsZXRpb24g Y2FsbGJhY2sgZm9yIGNvbnRyb2wgcmVxdWVzdHMpLiAgSXQgY291bGQgZXZlbiBiZSAKPiA+IGlt cGxlbWVudGVkIGJ5IGEgbGlicmFyeSByb3V0aW5lOyB0aGUgVURDIGRyaXZlciB3b3VsZCBzaW1w bHkgaGF2ZSB0byAKPiA+IGNhbGwgdGhpcyByb3V0aW5lIGltbWVkaWF0ZWx5IGFmdGVyIGludm9r aW5nIHRoZSBjYWxsYmFjay4KPiAKPiBJIGRvbid0IGZvbGxvdyB3aGF0IHlvdSBtZWFuIGhlcmUu CgpTdXBwb3NlIHdlIGhhdmUgYSBjb3JlIGxpYnJhcnkgcm91dGluZSBsaWtlIHRoaXM6Cgp2b2lk IHVzYl9nYWRnZXRfY29udHJvbF9jb21wbGV0ZShzdHJ1Y3QgdXNiX2dhZGdldCAqZ2FkZ2V0LAoJ CXVuc2lnbmVkIGludCBub19pbXBsaWNpdF9zdGF0dXMsIGludCBzdGF0dXMpCnsKCXN0cnVjdCB1 c2JfcmVxdWVzdCAqcmVxOwoKCWlmIChub19pbXBsaWNpdF9zdGF0dXMgfHwgc3RhdHVzICE9IDAp CgkJcmV0dXJuOwoKCS8qIFNlbmQgYW4gaW1wbGljaXQgc3RhdHVzLXN0YWdlIHJlcXVlc3QgZm9y IGVwMCAqLwoJcmVxID0gdXNiX2VwX2FsbG9jX3JlcXVlc3QoZ2FkZ2V0LT5lcDAsIEdGUF9BVE9N SUMpOwoJaWYgKHJlcSkgewoJCXJlcS0+bGVuZ3RoID0gMDsKCQlyZXEtPm5vX2ltcGxpY2l0X3N0 YXR1cyA9IDE7CgkJcmVxLT5jb21wbGV0ZSA9IC8qIHJlcSdzIGRlYWxsb2NhdGlvbiByb3V0aW5l ICovCgkJdXNiX2VwX3F1ZXVlKGdhZGdldC0+ZXAwLCByZXEsIEdGUF9BVE9NSUMpOwoJfQp9CgpU aGVuIGFsbCBhIFVEQyBkcml2ZXIgd291bGQgbmVlZCB0byBkbyBpcyBjYWxsIAp1c2JfZ2FkZ2V0 X2NvbnRyb2xfY29tcGxldGUoKSBhZnRlciBpbnZva2luZyBhIGNvbnRyb2wgcmVxdWVzdCdzIApj b21wbGV0aW9uIGhhbmRsZXIuICBUaGUgbm9faW1wbGljaXRfc3RhdHVzIGFuZCBzdGF0dXMgYXJn dW1lbnRzIHdvdWxkIApiZSB0YWtlbiBmcm9tIHRoZSByZXF1ZXN0IHRoYXQgd2FzIGp1c3QgY29t cGxldGVkLgoKV2l0aCB0aGlzIG9uZSBjYWxsIGFkZGVkIHRvIGVhY2ggVURDLCBhbGwgdGhlIGV4 aXN0aW5nIGZ1bmN0aW9uIGRyaXZlcnMKd291bGQgd29yayBjb3JyZWN0bHkuICBFdmVuIHRob3Vn aCB0aGV5IGRvbid0IGV4cGxpY2l0bHkgcXVldWUKc3RhdHVzLXN0YWdlIHJlcXVlc3RzLCB0aGUg bmV3IHJvdXRpbmUgd2lsbCBkbyBzbyBmb3IgdGhlbSwKdHJhbnNwYXJlbnRseS4gIEZ1bmN0aW9u IGRyaXZlcnMgdGhhdCB3YW50IHRvIGhhbmRsZSB0aGVpciBvd24Kc3RhdHVzLXN0YWdlIHJlcXVl c3RzIGV4cGxpY2l0bHkgd2lsbCBtZXJlbHkgaGF2ZSB0byBzZXQgdGhlCnJlcS0+bm9faW1wbGlj aXRfc3RhdHVzIGJpdC4KCihXZSBtaWdodCBvciBtaWdodCBub3QgbmVlZCB0byB3YXRjaCBvdXQg Zm9yIDAtbGVuZ3RoIGNvbnRyb2wtT1VUIAp0cmFuc2ZlcnMuICBGdW5jdGlvbiBkcml2ZXJzIF9k b18gcXVldWUgc3RhdHVzLXN0YWdlIHJlcXVlc3RzIGZvciAKdGhvc2UuKQoKQWxhbiBTdGVybgo=