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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 60BA9C43381 for ; Mon, 11 Mar 2019 08:15:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1F92F2075C for ; Mon, 11 Mar 2019 08:15:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Ji1HGDAs" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726897AbfCKIPX (ORCPT ); Mon, 11 Mar 2019 04:15:23 -0400 Received: from mail-it1-f195.google.com ([209.85.166.195]:40003 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725869AbfCKIPX (ORCPT ); Mon, 11 Mar 2019 04:15:23 -0400 Received: by mail-it1-f195.google.com with SMTP id l139so5848174ita.5; Mon, 11 Mar 2019 01:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=K07E/QDORE/5xOYpE1ki6Uu5itRwFTUaYYr1JCVmvPw=; b=Ji1HGDAsHcUPuw6E0NCgwLWhjGwGPrG3Luhib+D5Smnw8ZIRAZ0GRwZwzNbqmMW/0q EuhVvvpjH+wzcMTWaiIKdraIVaSn6rtukdEeWDN12bueOJiMeZ2AFWBsFoutEFCJUBNt VqHBCxMRaAf2gSPWAuTeGvRHuS50XOQuYqjwWir3PG3xE1/EZscTlVP4nRUTaDFHLjpQ 8kIf8zyCwW0OZUWbYa/0MTDFeJkPJmUWUMUtCOkX074zd170H6uHUBNNQOYKj1Y0v3ea Je/F0Pdjyeuy5E0TkvqBqdRFmAoNW2dpwcHk+BnH3zcmLPSIiR/PuIQZmMD32+46758c 1WAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=K07E/QDORE/5xOYpE1ki6Uu5itRwFTUaYYr1JCVmvPw=; b=IWEPLOFnj4xNuxh8x777gkU47Va+DGWcgaaznmeBwW/3C9KlXGUjcZfwSKpFa5QA7Z 1QIeInQxA0Wk7cSMXtC33E/fSlOOw+e9PeyijGypsQnMykwXJF6MQRWSHvyQE1hRs5/+ 8+wzpriMQYT+hqbcr5IKAqCXT467evdqhYrEreRnhWJwAnoe3nenROMe+LaeDbvH6tVs BLTNc9pt+WAx9EkO2hgP3+od5ooMmE9UnntvtUbDlw0DlDm+heFv0I3PlFQs1sErf++3 x9n8l0oPovjZLqaBJoRc1v4ZGWndOK2hTfe9Ae4UBKIZAMHXBzG2um7G65x9mS7rAKNi r4Dw== X-Gm-Message-State: APjAAAWOZJFHOncpiOM0oWXVYgarBG0DaA9BVLKs0kR7lK6xlFnlJC5k wqRW0edEykPH5As2n4EQ7VM8jtqPfW+h0pUWzbY= X-Google-Smtp-Source: APXvYqzfeYAR9sniHauY3eKItIIGSQomQtQ/z/O73fpoK6VY8IkvzqyiBj/mVujfNbKK+Z8fufXawol8PkLdql0TKbc= X-Received: by 2002:a02:2a83:: with SMTP id w125mr3728469jaw.44.1552292121715; Mon, 11 Mar 2019 01:15:21 -0700 (PDT) MIME-Version: 1.0 References: <1550173514-23573-1-git-send-email-pawell@cadence.com> <1550173514-23573-7-git-send-email-pawell@cadence.com> <67da432f-9c95-d644-65b5-dbc5b942d24c@ti.com> <87va1dbokp.fsf@linux.intel.com> <70967a02-2f02-9ac8-e205-cdbfac5fbbae@ti.com> <11e29bea-98c1-03c4-a7d5-c529df2cc341@ti.com> In-Reply-To: <11e29bea-98c1-03c4-a7d5-c529df2cc341@ti.com> From: Peter Chen Date: Mon, 11 Mar 2019 16:15:09 +0800 Message-ID: Subject: Re: [PATCH v4 6/6] usb:cdns3 Fix for stuck packets in on-chip OUT buffer. To: Roger Quadros Cc: Pawel Laszczak , Felipe Balbi , "devicetree@vger.kernel.org" , "gregkh@linuxfoundation.org" , "mark.rutland@arm.com" , "linux-usb@vger.kernel.org" , "hdegoede@redhat.com" , "heikki.krogerus@linux.intel.com" , "andy.shevchenko@gmail.com" , "robh+dt@kernel.org" , "linux-kernel@vger.kernel.org" , "jbergsagel@ti.com" , "nsekhar@ti.com" , "nm@ti.com" , Suresh Punnoose , "peter.chen@nxp.com" , Rahul Kumar Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > On 07/03/2019 09:06, Pawel Laszczak wrote: > > Hi, > > > >> Hi, > >> > >> On 21/02/2019 09:14, Felipe Balbi wrote: > >>> > >>> Hi, > >>> > >>> (please break your emails at 80-columns) > >>> > >>> Pawel Laszczak writes: > >>>>>> One more thing. Workaround has implemented algorithm that decide f= or which > >>>>>> endpoint it should be enabled. e.g for composite device MSC+NCM+A= CM it > >>>>>> should work only for ACM OUT endpoint. > >>>>>> > >>>>> > >>>>> If ACM driver didn't queue the request for ACM OUT endpoint, why do= es the > >>>>> controller accept the data at all? > >>>>> > >>>>> I didn't understand why we need a workaround for this. It should be= standard > >>>>> behaviour to NAK data if function driver didn't request for all end= points. > >>>> > >>>> Yes, I agree with you. Controller shouldn=E2=80=99t accept such pack= et. As I know this > >>>> behavior will be fixed in RTL. > >>>> > >>>> But I assume that some older version of this controller are one the = market, > >>>> and driver should work correct with them. > >>>> > >>>> In the feature this workaround can be limited only to selected contr= ollers. > >>>> > >>>> Even now I assume that it can be enabled/disabled by module paramete= r. > >>> > >>> no module parameters, please. Use revision detection in runtime. > >>> > >> > >> This is about whether to enable or disable the workaround. > >> By default we don't want this workaround to be enabled. > >> > >> I'm debating whether we should have this workaround at all or not. > >> > >> It has the following problems. > >> > >> 1) It ACKs packets even when gadget end is not ready to accept the tra= nsfers. > >> 2) It stores these packets in a temporary buffer and then pushes them = to the > >> gadget driver whenever the gadget driver is ready to process the data. > >> 3) Since the gadget driver can become ready at an indefinite time in t= he > >> future, it poses 2 problems: > >> a) It is sending stale data to the sink. (problematic at next protocol= level?) > >> b) If this temporary buffer runs out we still hit the lock up issue. > >> > >> I think the right solution is to make sure that the gadget driver is a= lways > >> reading all the enabled OUT endpoints *or* (keep the OUT endpoints dis= abled > >> if gadget driver is not ready to process OUT transfers). > > > > If driver disable endpoint then it not answer for packets from host. > > It will result that host reset the device, so I can't disable such endp= oints. > > > > Other good solution is to change ACM driver in a way that it sends requ= ests > > to controller driver after enabling endpoint. The class driver could de= cide > > The ACM driver is doing exactly that. However, there is a large delay (de= pending > on when user opens the ttyACM) between endpoint enable and request queue = and > that's the issue for this controller. > > The endpoint is enabled whenever the host sends a SET_INTERFACE > [acm_set_alt()->gserial_connect()] > but the first request is queued only when user opens the ttyACM > [gs_open()->gs_start_io()->gs_start_rx()]. > > I'm don't think this sequence can be changed. > What happens if you defer gserial_connect() to be done at gs_open()? > The host controller receives error due to there is no NAK either ACK for endpoint which should have already enabled. The host may send bus reset due to the response timeout for specific endpoint. This issue only affects multiple OUT use case, we run this issue after configuring gadget as ACM + NCM, NCM can't work (always responds NAKs for OUT) due to ACM endp= oint receives host's data but the user doesn't receive it, since all OUT endpoints share the same FIFOs. So, if we do not enable this workaround, the multiple OUT endpoints use case may not work well since one OUT endpoint may affect other OUT endpoints due to it occupies the common OUT FIFO. If we enable this workaround, for your below question: > >> It has the following problems. > >> > >> 1) It ACKs packets even when gadget end is not ready to accept the tra= nsfers. This can't be controlled by software, HW does it automatically once we enable endpoint. > >> 2) It stores these packets in a temporary buffer and then pushes them = to the > >> gadget driver whenever the gadget driver is ready to process the data. > >> 3) Since the gadget driver can become ready at an indefinite time in t= he > >> future, it poses 2 problems: > >> a) It is sending stale data to the sink. (problematic at next protocol= level?) Maybe. The protocol may be recovered after several talks, eg, the device fi= nds the stale data, and let the host re-send. > >> b) If this temporary buffer runs out we still hit the lock up issue. > >> It can be improved, if the temporary buffer is full, we could discard some oldest data. So, if not enable this workaround, the USB function is affected due to physical data can't be received, else, we may receive the stale data for some specific use cases, it only affect its own OUT endpoint, it may be recovered by protocol layer. I prefer enabling it by default if this workaround is well tested. Peter From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Chen Subject: Re: [PATCH v4 6/6] usb:cdns3 Fix for stuck packets in on-chip OUT buffer. Date: Mon, 11 Mar 2019 16:15:09 +0800 Message-ID: References: <1550173514-23573-1-git-send-email-pawell@cadence.com> <1550173514-23573-7-git-send-email-pawell@cadence.com> <67da432f-9c95-d644-65b5-dbc5b942d24c@ti.com> <87va1dbokp.fsf@linux.intel.com> <70967a02-2f02-9ac8-e205-cdbfac5fbbae@ti.com> <11e29bea-98c1-03c4-a7d5-c529df2cc341@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <11e29bea-98c1-03c4-a7d5-c529df2cc341@ti.com> Sender: linux-kernel-owner@vger.kernel.org To: Roger Quadros Cc: Pawel Laszczak , Felipe Balbi , "devicetree@vger.kernel.org" , "gregkh@linuxfoundation.org" , "mark.rutland@arm.com" , "linux-usb@vger.kernel.org" , "hdegoede@redhat.com" , "heikki.krogerus@linux.intel.com" , "andy.shevchenko@gmail.com" , "robh+dt@kernel.org" , "linux-kernel@vger.kernel.org" , "jbergsagel@ti.com" , "nsekhar@ti.com" , "nm@ti.com" , Suresh Punnoose , "peter.chen@nxp.com" , Rahul List-Id: devicetree@vger.kernel.org > > On 07/03/2019 09:06, Pawel Laszczak wrote: > > Hi, > > > >> Hi, > >> > >> On 21/02/2019 09:14, Felipe Balbi wrote: > >>> > >>> Hi, > >>> > >>> (please break your emails at 80-columns) > >>> > >>> Pawel Laszczak writes: > >>>>>> One more thing. Workaround has implemented algorithm that decide f= or which > >>>>>> endpoint it should be enabled. e.g for composite device MSC+NCM+A= CM it > >>>>>> should work only for ACM OUT endpoint. > >>>>>> > >>>>> > >>>>> If ACM driver didn't queue the request for ACM OUT endpoint, why do= es the > >>>>> controller accept the data at all? > >>>>> > >>>>> I didn't understand why we need a workaround for this. It should be= standard > >>>>> behaviour to NAK data if function driver didn't request for all end= points. > >>>> > >>>> Yes, I agree with you. Controller shouldn=E2=80=99t accept such pack= et. As I know this > >>>> behavior will be fixed in RTL. > >>>> > >>>> But I assume that some older version of this controller are one the = market, > >>>> and driver should work correct with them. > >>>> > >>>> In the feature this workaround can be limited only to selected contr= ollers. > >>>> > >>>> Even now I assume that it can be enabled/disabled by module paramete= r. > >>> > >>> no module parameters, please. Use revision detection in runtime. > >>> > >> > >> This is about whether to enable or disable the workaround. > >> By default we don't want this workaround to be enabled. > >> > >> I'm debating whether we should have this workaround at all or not. > >> > >> It has the following problems. > >> > >> 1) It ACKs packets even when gadget end is not ready to accept the tra= nsfers. > >> 2) It stores these packets in a temporary buffer and then pushes them = to the > >> gadget driver whenever the gadget driver is ready to process the data. > >> 3) Since the gadget driver can become ready at an indefinite time in t= he > >> future, it poses 2 problems: > >> a) It is sending stale data to the sink. (problematic at next protocol= level?) > >> b) If this temporary buffer runs out we still hit the lock up issue. > >> > >> I think the right solution is to make sure that the gadget driver is a= lways > >> reading all the enabled OUT endpoints *or* (keep the OUT endpoints dis= abled > >> if gadget driver is not ready to process OUT transfers). > > > > If driver disable endpoint then it not answer for packets from host. > > It will result that host reset the device, so I can't disable such endp= oints. > > > > Other good solution is to change ACM driver in a way that it sends requ= ests > > to controller driver after enabling endpoint. The class driver could de= cide > > The ACM driver is doing exactly that. However, there is a large delay (de= pending > on when user opens the ttyACM) between endpoint enable and request queue = and > that's the issue for this controller. > > The endpoint is enabled whenever the host sends a SET_INTERFACE > [acm_set_alt()->gserial_connect()] > but the first request is queued only when user opens the ttyACM > [gs_open()->gs_start_io()->gs_start_rx()]. > > I'm don't think this sequence can be changed. > What happens if you defer gserial_connect() to be done at gs_open()? > The host controller receives error due to there is no NAK either ACK for endpoint which should have already enabled. The host may send bus reset due to the response timeout for specific endpoint. This issue only affects multiple OUT use case, we run this issue after configuring gadget as ACM + NCM, NCM can't work (always responds NAKs for OUT) due to ACM endp= oint receives host's data but the user doesn't receive it, since all OUT endpoints share the same FIFOs. So, if we do not enable this workaround, the multiple OUT endpoints use case may not work well since one OUT endpoint may affect other OUT endpoints due to it occupies the common OUT FIFO. If we enable this workaround, for your below question: > >> It has the following problems. > >> > >> 1) It ACKs packets even when gadget end is not ready to accept the tra= nsfers. This can't be controlled by software, HW does it automatically once we enable endpoint. > >> 2) It stores these packets in a temporary buffer and then pushes them = to the > >> gadget driver whenever the gadget driver is ready to process the data. > >> 3) Since the gadget driver can become ready at an indefinite time in t= he > >> future, it poses 2 problems: > >> a) It is sending stale data to the sink. (problematic at next protocol= level?) Maybe. The protocol may be recovered after several talks, eg, the device fi= nds the stale data, and let the host re-send. > >> b) If this temporary buffer runs out we still hit the lock up issue. > >> It can be improved, if the temporary buffer is full, we could discard some oldest data. So, if not enable this workaround, the USB function is affected due to physical data can't be received, else, we may receive the stale data for some specific use cases, it only affect its own OUT endpoint, it may be recovered by protocol layer. I prefer enabling it by default if this workaround is well tested. Peter 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: [v4,6/6] usb:cdns3 Fix for stuck packets in on-chip OUT buffer. From: Peter Chen Message-Id: Date: Mon, 11 Mar 2019 16:15:09 +0800 To: Roger Quadros Cc: Pawel Laszczak , Felipe Balbi , "devicetree@vger.kernel.org" , "gregkh@linuxfoundation.org" , "mark.rutland@arm.com" , "linux-usb@vger.kernel.org" , "hdegoede@redhat.com" , "heikki.krogerus@linux.intel.com" , "andy.shevchenko@gmail.com" , "robh+dt@kernel.org" , "linux-kernel@vger.kernel.org" , "jbergsagel@ti.com" , "nsekhar@ti.com" , "nm@ti.com" , Suresh Punnoose , "peter.chen@nxp.com" , Rahul Kumar List-ID: Pgo+IE9uIDA3LzAzLzIwMTkgMDk6MDYsIFBhd2VsIExhc3pjemFrIHdyb3RlOgo+ID4gSGksCj4g Pgo+ID4+IEhpLAo+ID4+Cj4gPj4gT24gMjEvMDIvMjAxOSAwOToxNCwgRmVsaXBlIEJhbGJpIHdy b3RlOgo+ID4+Pgo+ID4+PiBIaSwKPiA+Pj4KPiA+Pj4gKHBsZWFzZSBicmVhayB5b3VyIGVtYWls cyBhdCA4MC1jb2x1bW5zKQo+ID4+Pgo+ID4+PiBQYXdlbCBMYXN6Y3phayA8cGF3ZWxsQGNhZGVu Y2UuY29tPiB3cml0ZXM6Cj4gPj4+Pj4+IE9uZSBtb3JlIHRoaW5nLiBXb3JrYXJvdW5kIGhhcyBp bXBsZW1lbnRlZCBhbGdvcml0aG0gdGhhdCBkZWNpZGUgZm9yIHdoaWNoCj4gPj4+Pj4+IGVuZHBv aW50IGl0IHNob3VsZCBiZSBlbmFibGVkLiAgZS5nIGZvciBjb21wb3NpdGUgZGV2aWNlIE1TQytO Q00rQUNNIGl0Cj4gPj4+Pj4+IHNob3VsZCB3b3JrIG9ubHkgZm9yIEFDTSBPVVQgZW5kcG9pbnQu Cj4gPj4+Pj4+Cj4gPj4+Pj4KPiA+Pj4+PiBJZiBBQ00gZHJpdmVyIGRpZG4ndCBxdWV1ZSB0aGUg cmVxdWVzdCBmb3IgQUNNIE9VVCBlbmRwb2ludCwgd2h5IGRvZXMgdGhlCj4gPj4+Pj4gY29udHJv bGxlciBhY2NlcHQgdGhlIGRhdGEgYXQgYWxsPwo+ID4+Pj4+Cj4gPj4+Pj4gSSBkaWRuJ3QgdW5k ZXJzdGFuZCB3aHkgd2UgbmVlZCBhIHdvcmthcm91bmQgZm9yIHRoaXMuIEl0IHNob3VsZCBiZSBz dGFuZGFyZAo+ID4+Pj4+IGJlaGF2aW91ciB0byBOQUsgZGF0YSBpZiBmdW5jdGlvbiBkcml2ZXIg ZGlkbid0IHJlcXVlc3QgZm9yIGFsbCBlbmRwb2ludHMuCj4gPj4+Pgo+ID4+Pj4gWWVzLCBJIGFn cmVlIHdpdGggeW91LiBDb250cm9sbGVyIHNob3VsZG7igJl0IGFjY2VwdCBzdWNoIHBhY2tldC4g QXMgSSBrbm93IHRoaXMKPiA+Pj4+IGJlaGF2aW9yIHdpbGwgYmUgZml4ZWQgaW4gUlRMLgo+ID4+ Pj4KPiA+Pj4+IEJ1dCBJIGFzc3VtZSB0aGF0IHNvbWUgb2xkZXIgdmVyc2lvbiBvZiB0aGlzIGNv bnRyb2xsZXIgYXJlIG9uZSB0aGUgbWFya2V0LAo+ID4+Pj4gYW5kIGRyaXZlciBzaG91bGQgd29y ayBjb3JyZWN0IHdpdGggdGhlbS4KPiA+Pj4+Cj4gPj4+PiBJbiB0aGUgZmVhdHVyZSB0aGlzIHdv cmthcm91bmQgY2FuIGJlIGxpbWl0ZWQgb25seSB0byBzZWxlY3RlZCBjb250cm9sbGVycy4KPiA+ Pj4+Cj4gPj4+PiBFdmVuIG5vdyBJIGFzc3VtZSB0aGF0IGl0IGNhbiBiZSBlbmFibGVkL2Rpc2Fi bGVkIGJ5IG1vZHVsZSBwYXJhbWV0ZXIuCj4gPj4+Cj4gPj4+IG5vIG1vZHVsZSBwYXJhbWV0ZXJz LCBwbGVhc2UuIFVzZSByZXZpc2lvbiBkZXRlY3Rpb24gaW4gcnVudGltZS4KPiA+Pj4KPiA+Pgo+ ID4+IFRoaXMgaXMgYWJvdXQgd2hldGhlciB0byBlbmFibGUgb3IgZGlzYWJsZSB0aGUgd29ya2Fy b3VuZC4KPiA+PiBCeSBkZWZhdWx0IHdlIGRvbid0IHdhbnQgdGhpcyB3b3JrYXJvdW5kIHRvIGJl IGVuYWJsZWQuCj4gPj4KPiA+PiBJJ20gZGViYXRpbmcgd2hldGhlciB3ZSBzaG91bGQgaGF2ZSB0 aGlzIHdvcmthcm91bmQgYXQgYWxsIG9yIG5vdC4KPiA+Pgo+ID4+IEl0IGhhcyB0aGUgZm9sbG93 aW5nIHByb2JsZW1zLgo+ID4+Cj4gPj4gMSkgSXQgQUNLcyBwYWNrZXRzIGV2ZW4gd2hlbiBnYWRn ZXQgZW5kIGlzIG5vdCByZWFkeSB0byBhY2NlcHQgdGhlIHRyYW5zZmVycy4KPiA+PiAyKSBJdCBz dG9yZXMgdGhlc2UgcGFja2V0cyBpbiBhIHRlbXBvcmFyeSBidWZmZXIgYW5kIHRoZW4gcHVzaGVz IHRoZW0gdG8gdGhlCj4gPj4gZ2FkZ2V0IGRyaXZlciB3aGVuZXZlciB0aGUgZ2FkZ2V0IGRyaXZl ciBpcyByZWFkeSB0byBwcm9jZXNzIHRoZSBkYXRhLgo+ID4+IDMpIFNpbmNlIHRoZSBnYWRnZXQg ZHJpdmVyIGNhbiBiZWNvbWUgcmVhZHkgYXQgYW4gaW5kZWZpbml0ZSB0aW1lIGluIHRoZQo+ID4+ IGZ1dHVyZSwgaXQgcG9zZXMgMiBwcm9ibGVtczoKPiA+PiBhKSBJdCBpcyBzZW5kaW5nIHN0YWxl IGRhdGEgdG8gdGhlIHNpbmsuIChwcm9ibGVtYXRpYyBhdCBuZXh0IHByb3RvY29sIGxldmVsPykK PiA+PiBiKSBJZiB0aGlzIHRlbXBvcmFyeSBidWZmZXIgcnVucyBvdXQgd2Ugc3RpbGwgaGl0IHRo ZSBsb2NrIHVwIGlzc3VlLgo+ID4+Cj4gPj4gSSB0aGluayB0aGUgcmlnaHQgc29sdXRpb24gaXMg dG8gbWFrZSBzdXJlIHRoYXQgdGhlIGdhZGdldCBkcml2ZXIgaXMgYWx3YXlzCj4gPj4gcmVhZGlu ZyBhbGwgdGhlIGVuYWJsZWQgT1VUIGVuZHBvaW50cyAqb3IqIChrZWVwIHRoZSBPVVQgZW5kcG9p bnRzIGRpc2FibGVkCj4gPj4gaWYgZ2FkZ2V0IGRyaXZlciBpcyBub3QgcmVhZHkgdG8gcHJvY2Vz cyBPVVQgdHJhbnNmZXJzKS4KPiA+Cj4gPiBJZiBkcml2ZXIgZGlzYWJsZSBlbmRwb2ludCB0aGVu IGl0IG5vdCBhbnN3ZXIgZm9yIHBhY2tldHMgZnJvbSBob3N0Lgo+ID4gSXQgd2lsbCByZXN1bHQg dGhhdCBob3N0IHJlc2V0IHRoZSBkZXZpY2UsIHNvIEkgY2FuJ3QgZGlzYWJsZSBzdWNoIGVuZHBv aW50cy4KPiA+Cj4gPiBPdGhlciBnb29kIHNvbHV0aW9uIGlzIHRvIGNoYW5nZSBBQ00gZHJpdmVy IGluIGEgd2F5IHRoYXQgaXQgc2VuZHMgcmVxdWVzdHMKPiA+IHRvIGNvbnRyb2xsZXIgZHJpdmVy IGFmdGVyIGVuYWJsaW5nIGVuZHBvaW50LiBUaGUgY2xhc3MgZHJpdmVyIGNvdWxkIGRlY2lkZQo+ Cj4gVGhlIEFDTSBkcml2ZXIgaXMgZG9pbmcgZXhhY3RseSB0aGF0LiBIb3dldmVyLCB0aGVyZSBp cyBhIGxhcmdlIGRlbGF5IChkZXBlbmRpbmcKPiBvbiB3aGVuIHVzZXIgb3BlbnMgdGhlIHR0eUFD TSkgYmV0d2VlbiBlbmRwb2ludCBlbmFibGUgYW5kIHJlcXVlc3QgcXVldWUgYW5kCj4gdGhhdCdz IHRoZSBpc3N1ZSBmb3IgdGhpcyBjb250cm9sbGVyLgo+Cj4gVGhlIGVuZHBvaW50IGlzIGVuYWJs ZWQgd2hlbmV2ZXIgdGhlIGhvc3Qgc2VuZHMgYSBTRVRfSU5URVJGQUNFCj4gW2FjbV9zZXRfYWx0 KCktPmdzZXJpYWxfY29ubmVjdCgpXQo+IGJ1dCB0aGUgZmlyc3QgcmVxdWVzdCBpcyBxdWV1ZWQg b25seSB3aGVuIHVzZXIgb3BlbnMgdGhlIHR0eUFDTQo+IFtnc19vcGVuKCktPmdzX3N0YXJ0X2lv KCktPmdzX3N0YXJ0X3J4KCldLgo+Cj4gSSdtIGRvbid0IHRoaW5rIHRoaXMgc2VxdWVuY2UgY2Fu IGJlIGNoYW5nZWQuCj4gV2hhdCBoYXBwZW5zIGlmIHlvdSBkZWZlciBnc2VyaWFsX2Nvbm5lY3Qo KSB0byBiZSBkb25lIGF0IGdzX29wZW4oKT8KPgoKVGhlIGhvc3QgY29udHJvbGxlciByZWNlaXZl cyBlcnJvciBkdWUgdG8gdGhlcmUgaXMgbm8gTkFLIGVpdGhlciBBQ0sKZm9yIGVuZHBvaW50Cndo aWNoIHNob3VsZCBoYXZlIGFscmVhZHkgZW5hYmxlZC4gVGhlIGhvc3QgbWF5IHNlbmQgYnVzIHJl c2V0IGR1ZSB0bwp0aGUgcmVzcG9uc2UKdGltZW91dCBmb3Igc3BlY2lmaWMgZW5kcG9pbnQuCgpU aGlzIGlzc3VlIG9ubHkgYWZmZWN0cyBtdWx0aXBsZSBPVVQgdXNlIGNhc2UsIHdlIHJ1biB0aGlz IGlzc3VlIGFmdGVyCmNvbmZpZ3VyaW5nIGdhZGdldAphcyBBQ00gKyBOQ00sIE5DTSBjYW4ndCB3 b3JrIChhbHdheXMgcmVzcG9uZHMgTkFLcyBmb3IgT1VUKSBkdWUgdG8gQUNNIGVuZHBvaW50CnJl Y2VpdmVzIGhvc3QncyBkYXRhIGJ1dCB0aGUgdXNlciBkb2Vzbid0IHJlY2VpdmUgaXQsIHNpbmNl IGFsbCBPVVQKZW5kcG9pbnRzIHNoYXJlIHRoZSBzYW1lIEZJRk9zLgoKU28sIGlmIHdlIGRvIG5v dCBlbmFibGUgdGhpcyB3b3JrYXJvdW5kLCB0aGUgbXVsdGlwbGUgT1VUIGVuZHBvaW50cwp1c2Ug Y2FzZSBtYXkgbm90Cndvcmsgd2VsbCBzaW5jZSBvbmUgT1VUIGVuZHBvaW50IG1heSBhZmZlY3Qg b3RoZXIgT1VUIGVuZHBvaW50cyBkdWUgdG8KaXQgb2NjdXBpZXMgdGhlCmNvbW1vbiBPVVQgRklG Ty4KCklmIHdlIGVuYWJsZSB0aGlzIHdvcmthcm91bmQsIGZvciB5b3VyIGJlbG93IHF1ZXN0aW9u OgoKPiA+PiBJdCBoYXMgdGhlIGZvbGxvd2luZyBwcm9ibGVtcy4KPiA+Pgo+ID4+IDEpIEl0IEFD S3MgcGFja2V0cyBldmVuIHdoZW4gZ2FkZ2V0IGVuZCBpcyBub3QgcmVhZHkgdG8gYWNjZXB0IHRo ZSB0cmFuc2ZlcnMuCgpUaGlzIGNhbid0IGJlIGNvbnRyb2xsZWQgYnkgc29mdHdhcmUsIEhXIGRv ZXMgaXQgYXV0b21hdGljYWxseSBvbmNlIHdlCmVuYWJsZSBlbmRwb2ludC4KCj4gPj4gMikgSXQg c3RvcmVzIHRoZXNlIHBhY2tldHMgaW4gYSB0ZW1wb3JhcnkgYnVmZmVyIGFuZCB0aGVuIHB1c2hl cyB0aGVtIHRvIHRoZQo+ID4+IGdhZGdldCBkcml2ZXIgd2hlbmV2ZXIgdGhlIGdhZGdldCBkcml2 ZXIgaXMgcmVhZHkgdG8gcHJvY2VzcyB0aGUgZGF0YS4KPiA+PiAzKSBTaW5jZSB0aGUgZ2FkZ2V0 IGRyaXZlciBjYW4gYmVjb21lIHJlYWR5IGF0IGFuIGluZGVmaW5pdGUgdGltZSBpbiB0aGUKPiA+ PiBmdXR1cmUsIGl0IHBvc2VzIDIgcHJvYmxlbXM6Cj4gPj4gYSkgSXQgaXMgc2VuZGluZyBzdGFs ZSBkYXRhIHRvIHRoZSBzaW5rLiAocHJvYmxlbWF0aWMgYXQgbmV4dCBwcm90b2NvbCBsZXZlbD8p CgpNYXliZS4gVGhlIHByb3RvY29sIG1heSBiZSByZWNvdmVyZWQgYWZ0ZXIgc2V2ZXJhbCB0YWxr cywgZWcsIHRoZSBkZXZpY2UgZmluZHMKdGhlIHN0YWxlIGRhdGEsIGFuZCBsZXQgdGhlIGhvc3Qg cmUtc2VuZC4KCj4gPj4gYikgSWYgdGhpcyB0ZW1wb3JhcnkgYnVmZmVyIHJ1bnMgb3V0IHdlIHN0 aWxsIGhpdCB0aGUgbG9jayB1cCBpc3N1ZS4KPiA+PgoKSXQgY2FuIGJlIGltcHJvdmVkLCBpZiB0 aGUgdGVtcG9yYXJ5IGJ1ZmZlciBpcyBmdWxsLCB3ZSBjb3VsZCBkaXNjYXJkCnNvbWUgb2xkZXN0 IGRhdGEuCgpTbywgaWYgbm90IGVuYWJsZSB0aGlzIHdvcmthcm91bmQsIHRoZSBVU0IgZnVuY3Rp b24gaXMgYWZmZWN0ZWQgZHVlIHRvCnBoeXNpY2FsIGRhdGEgY2FuJ3QKYmUgcmVjZWl2ZWQsIGVs c2UsIHdlIG1heSByZWNlaXZlIHRoZSBzdGFsZSBkYXRhIGZvciBzb21lIHNwZWNpZmljIHVzZQpj YXNlcywgaXQgb25seSBhZmZlY3QKaXRzIG93biBPVVQgZW5kcG9pbnQsIGl0IG1heSBiZSByZWNv dmVyZWQgYnkgcHJvdG9jb2wgbGF5ZXIuICBJIHByZWZlcgplbmFibGluZyBpdCBieSBkZWZhdWx0 CmlmIHRoaXMgd29ya2Fyb3VuZCBpcyB3ZWxsIHRlc3RlZC4KClBldGVyCg==