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=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 1FFDCC433FE for ; Tue, 8 Dec 2020 14:21:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CF24B23A69 for ; Tue, 8 Dec 2020 14:21:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729833AbgLHOVW (ORCPT ); Tue, 8 Dec 2020 09:21:22 -0500 Received: from foss.arm.com ([217.140.110.172]:49658 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726738AbgLHOVV (ORCPT ); Tue, 8 Dec 2020 09:21:21 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DFA9613D5; Tue, 8 Dec 2020 06:20:35 -0800 (PST) Received: from [10.57.23.55] (unknown [10.57.23.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3A96B3F718; Tue, 8 Dec 2020 06:20:33 -0800 (PST) Subject: Re: [PATCH v2 2/5] thermal: devfreq_cooling: get a copy of device status From: Lukasz Luba To: Daniel Lezcano Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, dri-devel@lists.freedesktop.org, rui.zhang@intel.com, amit.kucheria@verdurent.com, orjan.eide@arm.com, robh@kernel.org, alyssa.rosenzweig@collabora.com, steven.price@arm.com, airlied@linux.ie, daniel@ffwll.ch, ionela.voinescu@arm.com References: <20201118120358.17150-1-lukasz.luba@arm.com> <20201118120358.17150-3-lukasz.luba@arm.com> <5d4743b9-5b2f-8494-8d10-6a5fd2c0fdfd@linaro.org> <224c6b9b-977a-d553-f22b-2056223a84bc@linaro.org> <947a3afc-5dd6-892b-6987-ad81a5a96197@arm.com> Message-ID: <9b19373f-2dd9-368c-6d38-cd885fcde5e1@arm.com> Date: Tue, 8 Dec 2020 14:20:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <947a3afc-5dd6-892b-6987-ad81a5a96197@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, On 12/7/20 12:41 PM, Lukasz Luba wrote: > > > On 12/3/20 4:09 PM, Daniel Lezcano wrote: >> On 03/12/2020 16:38, Lukasz Luba wrote: >>> >>> >>> On 12/3/20 1:09 PM, Daniel Lezcano wrote: >>>> On 18/11/2020 13:03, Lukasz Luba wrote: >>>>> Devfreq cooling needs to now the correct status of the device in order >>>>> to operate. Do not rely on Devfreq last_status which might be a stale >>>>> data >>>>> and get more up-to-date values of the load. >>>>> >>>>> Devfreq framework can change the device status in the background. To >>>>> mitigate this situation make a copy of the status structure and use it >>>>> for internal calculations. >>>>> >>>>> In addition this patch adds normalization function, which also makes >>>>> sure >>>>> that whatever data comes from the device, it is in a sane range. >>>>> >>>>> Signed-off-by: Lukasz Luba >>>>> --- >>>>>    drivers/thermal/devfreq_cooling.c | 52 >>>>> +++++++++++++++++++++++++------ >>>>>    1 file changed, 43 insertions(+), 9 deletions(-) >>>>> >>>>> diff --git a/drivers/thermal/devfreq_cooling.c >>>>> b/drivers/thermal/devfreq_cooling.c >>>>> index 659c0143c9f0..925523694462 100644 >>>>> --- a/drivers/thermal/devfreq_cooling.c >>>>> +++ b/drivers/thermal/devfreq_cooling.c >>>>> @@ -227,20 +227,46 @@ static inline unsigned long >>>>> get_total_power(struct devfreq_cooling_device *dfc, >>>>>                                       voltage); >>>>>    } >>>>>    +static void _normalize_load(struct devfreq_dev_status *status) >>>>> +{ >>>>> +    /* Make some space if needed */ >>>>> +    if (status->busy_time > 0xffff) { >>>>> +        status->busy_time >>= 10; >>>>> +        status->total_time >>= 10; >>>>> +    } >>>>> + >>>>> +    if (status->busy_time > status->total_time) >>>>> +        status->busy_time = status->total_time; >>>> >>>> How the condition above is possible? >>> >>> They should, be checked by the driver, but I cannot trust >>> and have to check for all corner cases: (div by 0, overflow >>> one of them, etc). The busy_time and total_time are unsigned long, >>> which means 4B on 32bit machines. >>> If these values are coming from device counters, which count every >>> busy cycle and total cycles of a clock of a device running at e.g. >>> 1GHz they would overflow every ~4s. >> >> I don't think it is up to this routine to check the driver is correctly >> implemented, especially at every call to get_requested_power. >> >> If the normalization ends up by doing this kind of thing, there is >> certainly something wrong in the 'status' computation to be fixed before >> submitting this series. >> >> >>> Normally IPA polling are 1s and 100ms, it's platform specific. But there >>> are also 'empty' periods when IPA sees temperature very low and does not >>> even call the .get_requested_power() callbacks for the cooling devices, >>> just grants max freq to all. This is problematic. I am investigating it >>> and will propose a solution for IPA soon. >>> >>> I would avoid all of this if devfreq core would have default for all >>> devices a reliable polling timer... Let me check some possibilities also >>> for this case. >> >> Ok, may be create an API to compute the 'idle,busy,total times' to be >> used by the different the devfreq drivers and then fix the overflow in >> this common place. > > Yes, I have this plan, but I have to close this patch series. To go > forward with this, I will drop the normalization function and will keep > only the code of safe copy of the 'status', so using busy_time and > total_time will be safe. I did experiments and actually I cannot drop this function. Drivers can feed total_time and busy_time which are in nanoseconds, e.g. [1] 50ms => 50.000.000ns which is then when multiplied by 1024 and exceed the u32. I want to avoid 64bit variables and divisions, so shifting them earlier would help. IMHO it does not harm this devfreq cooling to make that check and handle ns values. I am going to use the normalization into 0..1024 as you and Ionela suggested. I will also drop the direct device status check. That would be a different patch series. In that patch set I will try to come with a generic solution and some API. Regards, Lukasz [1] https://elixir.bootlin.com/linux/v5.10-rc5/source/drivers/gpu/drm/panfrost/panfrost_devfreq.c#L66 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=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 E9E5CC433FE for ; Wed, 9 Dec 2020 08:32:16 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A57D223B98 for ; Wed, 9 Dec 2020 08:32:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A57D223B98 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CF5716E22F; Wed, 9 Dec 2020 08:32:02 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 40D796E952 for ; Tue, 8 Dec 2020 14:20:37 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DFA9613D5; Tue, 8 Dec 2020 06:20:35 -0800 (PST) Received: from [10.57.23.55] (unknown [10.57.23.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3A96B3F718; Tue, 8 Dec 2020 06:20:33 -0800 (PST) Subject: Re: [PATCH v2 2/5] thermal: devfreq_cooling: get a copy of device status From: Lukasz Luba To: Daniel Lezcano References: <20201118120358.17150-1-lukasz.luba@arm.com> <20201118120358.17150-3-lukasz.luba@arm.com> <5d4743b9-5b2f-8494-8d10-6a5fd2c0fdfd@linaro.org> <224c6b9b-977a-d553-f22b-2056223a84bc@linaro.org> <947a3afc-5dd6-892b-6987-ad81a5a96197@arm.com> Message-ID: <9b19373f-2dd9-368c-6d38-cd885fcde5e1@arm.com> Date: Tue, 8 Dec 2020 14:20:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <947a3afc-5dd6-892b-6987-ad81a5a96197@arm.com> Content-Language: en-US X-Mailman-Approved-At: Wed, 09 Dec 2020 08:32:01 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: amit.kucheria@verdurent.com, linux-pm@vger.kernel.org, airlied@linux.ie, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, steven.price@arm.com, alyssa.rosenzweig@collabora.com, rui.zhang@intel.com, ionela.voinescu@arm.com, orjan.eide@arm.com Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" SGkgRGFuaWVsLAoKT24gMTIvNy8yMCAxMjo0MSBQTSwgTHVrYXN6IEx1YmEgd3JvdGU6Cj4gCj4g Cj4gT24gMTIvMy8yMCA0OjA5IFBNLCBEYW5pZWwgTGV6Y2FubyB3cm90ZToKPj4gT24gMDMvMTIv MjAyMCAxNjozOCwgTHVrYXN6IEx1YmEgd3JvdGU6Cj4+Pgo+Pj4KPj4+IE9uIDEyLzMvMjAgMTow OSBQTSwgRGFuaWVsIExlemNhbm8gd3JvdGU6Cj4+Pj4gT24gMTgvMTEvMjAyMCAxMzowMywgTHVr YXN6IEx1YmEgd3JvdGU6Cj4+Pj4+IERldmZyZXEgY29vbGluZyBuZWVkcyB0byBub3cgdGhlIGNv cnJlY3Qgc3RhdHVzIG9mIHRoZSBkZXZpY2UgaW4gb3JkZXIKPj4+Pj4gdG8gb3BlcmF0ZS4gRG8g bm90IHJlbHkgb24gRGV2ZnJlcSBsYXN0X3N0YXR1cyB3aGljaCBtaWdodCBiZSBhIHN0YWxlCj4+ Pj4+IGRhdGEKPj4+Pj4gYW5kIGdldCBtb3JlIHVwLXRvLWRhdGUgdmFsdWVzIG9mIHRoZSBsb2Fk Lgo+Pj4+Pgo+Pj4+PiBEZXZmcmVxIGZyYW1ld29yayBjYW4gY2hhbmdlIHRoZSBkZXZpY2Ugc3Rh dHVzIGluIHRoZSBiYWNrZ3JvdW5kLiBUbwo+Pj4+PiBtaXRpZ2F0ZSB0aGlzIHNpdHVhdGlvbiBt YWtlIGEgY29weSBvZiB0aGUgc3RhdHVzIHN0cnVjdHVyZSBhbmQgdXNlIGl0Cj4+Pj4+IGZvciBp bnRlcm5hbCBjYWxjdWxhdGlvbnMuCj4+Pj4+Cj4+Pj4+IEluIGFkZGl0aW9uIHRoaXMgcGF0Y2gg YWRkcyBub3JtYWxpemF0aW9uIGZ1bmN0aW9uLCB3aGljaCBhbHNvIG1ha2VzCj4+Pj4+IHN1cmUK Pj4+Pj4gdGhhdCB3aGF0ZXZlciBkYXRhIGNvbWVzIGZyb20gdGhlIGRldmljZSwgaXQgaXMgaW4g YSBzYW5lIHJhbmdlLgo+Pj4+Pgo+Pj4+PiBTaWduZWQtb2ZmLWJ5OiBMdWthc3ogTHViYSA8bHVr YXN6Lmx1YmFAYXJtLmNvbT4KPj4+Pj4gLS0tCj4+Pj4+IMKgwqAgZHJpdmVycy90aGVybWFsL2Rl dmZyZXFfY29vbGluZy5jIHwgNTIgCj4+Pj4+ICsrKysrKysrKysrKysrKysrKysrKysrKystLS0t LS0KPj4+Pj4gwqDCoCAxIGZpbGUgY2hhbmdlZCwgNDMgaW5zZXJ0aW9ucygrKSwgOSBkZWxldGlv bnMoLSkKPj4+Pj4KPj4+Pj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvdGhlcm1hbC9kZXZmcmVxX2Nv b2xpbmcuYwo+Pj4+PiBiL2RyaXZlcnMvdGhlcm1hbC9kZXZmcmVxX2Nvb2xpbmcuYwo+Pj4+PiBp bmRleCA2NTljMDE0M2M5ZjAuLjkyNTUyMzY5NDQ2MiAxMDA2NDQKPj4+Pj4gLS0tIGEvZHJpdmVy cy90aGVybWFsL2RldmZyZXFfY29vbGluZy5jCj4+Pj4+ICsrKyBiL2RyaXZlcnMvdGhlcm1hbC9k ZXZmcmVxX2Nvb2xpbmcuYwo+Pj4+PiBAQCAtMjI3LDIwICsyMjcsNDYgQEAgc3RhdGljIGlubGlu ZSB1bnNpZ25lZCBsb25nCj4+Pj4+IGdldF90b3RhbF9wb3dlcihzdHJ1Y3QgZGV2ZnJlcV9jb29s aW5nX2RldmljZSAqZGZjLAo+Pj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB2b2x0YWdlKTsKPj4+Pj4g wqDCoCB9Cj4+Pj4+IMKgwqAgK3N0YXRpYyB2b2lkIF9ub3JtYWxpemVfbG9hZChzdHJ1Y3QgZGV2 ZnJlcV9kZXZfc3RhdHVzICpzdGF0dXMpCj4+Pj4+ICt7Cj4+Pj4+ICvCoMKgwqAgLyogTWFrZSBz b21lIHNwYWNlIGlmIG5lZWRlZCAqLwo+Pj4+PiArwqDCoMKgIGlmIChzdGF0dXMtPmJ1c3lfdGlt ZSA+IDB4ZmZmZikgewo+Pj4+PiArwqDCoMKgwqDCoMKgwqAgc3RhdHVzLT5idXN5X3RpbWUgPj49 IDEwOwo+Pj4+PiArwqDCoMKgwqDCoMKgwqAgc3RhdHVzLT50b3RhbF90aW1lID4+PSAxMDsKPj4+ Pj4gK8KgwqDCoCB9Cj4+Pj4+ICsKPj4+Pj4gK8KgwqDCoCBpZiAoc3RhdHVzLT5idXN5X3RpbWUg PiBzdGF0dXMtPnRvdGFsX3RpbWUpCj4+Pj4+ICvCoMKgwqDCoMKgwqDCoCBzdGF0dXMtPmJ1c3lf dGltZSA9IHN0YXR1cy0+dG90YWxfdGltZTsKPj4+Pgo+Pj4+IEhvdyB0aGUgY29uZGl0aW9uIGFi b3ZlIGlzIHBvc3NpYmxlPwo+Pj4KPj4+IFRoZXkgc2hvdWxkLCBiZSBjaGVja2VkIGJ5IHRoZSBk cml2ZXIsIGJ1dCBJIGNhbm5vdCB0cnVzdAo+Pj4gYW5kIGhhdmUgdG8gY2hlY2sgZm9yIGFsbCBj b3JuZXIgY2FzZXM6IChkaXYgYnkgMCwgb3ZlcmZsb3cKPj4+IG9uZSBvZiB0aGVtLCBldGMpLiBU aGUgYnVzeV90aW1lIGFuZCB0b3RhbF90aW1lIGFyZSB1bnNpZ25lZCBsb25nLAo+Pj4gd2hpY2gg bWVhbnMgNEIgb24gMzJiaXQgbWFjaGluZXMuCj4+PiBJZiB0aGVzZSB2YWx1ZXMgYXJlIGNvbWlu ZyBmcm9tIGRldmljZSBjb3VudGVycywgd2hpY2ggY291bnQgZXZlcnkKPj4+IGJ1c3kgY3ljbGUg YW5kIHRvdGFsIGN5Y2xlcyBvZiBhIGNsb2NrIG9mIGEgZGV2aWNlIHJ1bm5pbmcgYXQgZS5nLgo+ Pj4gMUdIeiB0aGV5IHdvdWxkIG92ZXJmbG93IGV2ZXJ5IH40cy4KPj4KPj4gSSBkb24ndCB0aGlu ayBpdCBpcyB1cCB0byB0aGlzIHJvdXRpbmUgdG8gY2hlY2sgdGhlIGRyaXZlciBpcyBjb3JyZWN0 bHkKPj4gaW1wbGVtZW50ZWQsIGVzcGVjaWFsbHkgYXQgZXZlcnkgY2FsbCB0byBnZXRfcmVxdWVz dGVkX3Bvd2VyLgo+Pgo+PiBJZiB0aGUgbm9ybWFsaXphdGlvbiBlbmRzIHVwIGJ5IGRvaW5nIHRo aXMga2luZCBvZiB0aGluZywgdGhlcmUgaXMKPj4gY2VydGFpbmx5IHNvbWV0aGluZyB3cm9uZyBp biB0aGUgJ3N0YXR1cycgY29tcHV0YXRpb24gdG8gYmUgZml4ZWQgYmVmb3JlCj4+IHN1Ym1pdHRp bmcgdGhpcyBzZXJpZXMuCj4+Cj4+Cj4+PiBOb3JtYWxseSBJUEEgcG9sbGluZyBhcmUgMXMgYW5k IDEwMG1zLCBpdCdzIHBsYXRmb3JtIHNwZWNpZmljLiBCdXQgdGhlcmUKPj4+IGFyZSBhbHNvICdl bXB0eScgcGVyaW9kcyB3aGVuIElQQSBzZWVzIHRlbXBlcmF0dXJlIHZlcnkgbG93IGFuZCBkb2Vz IG5vdAo+Pj4gZXZlbiBjYWxsIHRoZSAuZ2V0X3JlcXVlc3RlZF9wb3dlcigpIGNhbGxiYWNrcyBm b3IgdGhlIGNvb2xpbmcgZGV2aWNlcywKPj4+IGp1c3QgZ3JhbnRzIG1heCBmcmVxIHRvIGFsbC4g VGhpcyBpcyBwcm9ibGVtYXRpYy4gSSBhbSBpbnZlc3RpZ2F0aW5nIGl0Cj4+PiBhbmQgd2lsbCBw cm9wb3NlIGEgc29sdXRpb24gZm9yIElQQSBzb29uLgo+Pj4KPj4+IEkgd291bGQgYXZvaWQgYWxs IG9mIHRoaXMgaWYgZGV2ZnJlcSBjb3JlIHdvdWxkIGhhdmUgZGVmYXVsdCBmb3IgYWxsCj4+PiBk ZXZpY2VzIGEgcmVsaWFibGUgcG9sbGluZyB0aW1lci4uLiBMZXQgbWUgY2hlY2sgc29tZSBwb3Nz aWJpbGl0aWVzIGFsc28KPj4+IGZvciB0aGlzIGNhc2UuCj4+Cj4+IE9rLCBtYXkgYmUgY3JlYXRl IGFuIEFQSSB0byBjb21wdXRlIHRoZSAnaWRsZSxidXN5LHRvdGFsIHRpbWVzJyB0byBiZQo+PiB1 c2VkIGJ5IHRoZSBkaWZmZXJlbnQgdGhlIGRldmZyZXEgZHJpdmVycyBhbmQgdGhlbiBmaXggdGhl IG92ZXJmbG93IGluCj4+IHRoaXMgY29tbW9uIHBsYWNlLgo+IAo+IFllcywgSSBoYXZlIHRoaXMg cGxhbiwgYnV0IEkgaGF2ZSB0byBjbG9zZSB0aGlzIHBhdGNoIHNlcmllcy4gVG8gZ28KPiBmb3J3 YXJkIHdpdGggdGhpcywgSSB3aWxsIGRyb3AgdGhlIG5vcm1hbGl6YXRpb24gZnVuY3Rpb24gYW5k IHdpbGwga2VlcAo+IG9ubHkgdGhlIGNvZGUgb2Ygc2FmZSBjb3B5IG9mIHRoZSAnc3RhdHVzJywg c28gdXNpbmcgYnVzeV90aW1lIGFuZAo+IHRvdGFsX3RpbWUgd2lsbCBiZSBzYWZlLgoKSSBkaWQg ZXhwZXJpbWVudHMgYW5kIGFjdHVhbGx5IEkgY2Fubm90IGRyb3AgdGhpcyBmdW5jdGlvbi4gRHJp dmVycyBjYW4KZmVlZCB0b3RhbF90aW1lIGFuZCBidXN5X3RpbWUgd2hpY2ggYXJlIGluIG5hbm9z ZWNvbmRzLCBlLmcuIFsxXSA1MG1zID0+CjUwLjAwMC4wMDBucyB3aGljaCBpcyB0aGVuIHdoZW4g bXVsdGlwbGllZCBieSAxMDI0ICBhbmQgZXhjZWVkIHRoZSB1MzIuCkkgd2FudCB0byBhdm9pZCA2 NGJpdCB2YXJpYWJsZXMgYW5kIGRpdmlzaW9ucywgc28gc2hpZnRpbmcgdGhlbSBlYXJsaWVyCndv dWxkIGhlbHAuIElNSE8gaXQgZG9lcyBub3QgaGFybSB0aGlzIGRldmZyZXEgY29vbGluZyB0byBt YWtlIHRoYXQKY2hlY2sgYW5kIGhhbmRsZSBucyB2YWx1ZXMuCgpJIGFtIGdvaW5nIHRvIHVzZSB0 aGUgbm9ybWFsaXphdGlvbiBpbnRvIDAuLjEwMjQgYXMgeW91IGFuZCBJb25lbGEKc3VnZ2VzdGVk LgpJIHdpbGwgYWxzbyBkcm9wIHRoZSBkaXJlY3QgZGV2aWNlIHN0YXR1cyBjaGVjay4gVGhhdCB3 b3VsZCBiZSBhCmRpZmZlcmVudCBwYXRjaCBzZXJpZXMuIEluIHRoYXQgcGF0Y2ggc2V0IEkgd2ls bCB0cnkgdG8gY29tZSB3aXRoIGEKZ2VuZXJpYyBzb2x1dGlvbiBhbmQgc29tZSBBUEkuCgpSZWdh cmRzLApMdWthc3oKClsxXSAKaHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5jb20vbGludXgvdjUuMTAt cmM1L3NvdXJjZS9kcml2ZXJzL2dwdS9kcm0vcGFuZnJvc3QvcGFuZnJvc3RfZGV2ZnJlcS5jI0w2 NgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2 ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9s aXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK