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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4BFCDC433EF for ; Tue, 1 Mar 2022 09:47:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234002AbiCAJsA (ORCPT ); Tue, 1 Mar 2022 04:48:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234119AbiCAJry (ORCPT ); Tue, 1 Mar 2022 04:47:54 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5357B8BF47; Tue, 1 Mar 2022 01:47:13 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id DF486B817CF; Tue, 1 Mar 2022 09:47:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32853C340EE; Tue, 1 Mar 2022 09:47:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646128030; bh=bIEyEZCYsYHYD4lz+YBrbdVvQiVr4Nv4bmNiO9AhL4I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hQMMlXanjwsY0GvyqcfaeYDkD7UPWfXKsRh3SU34twWSptfTIm7Tv48s3LKORwKSE aGw9cpI51eIW1iNYFG1IASAGOiT3V0vGDk1g3GHtp5t9gGTyv7g0T+C4a+KHz4imaq Bua7vWOfr8KfPCfeobB0ionRCQR/lCLjiCzxxETMrGd8I0nTkOE4cugEimddghBWLF HWibgvIVSMOOI/hhhcYULMAD6QNwwVd22+U4bi5csnO1KywIiGbSWAkfsULI7VpMdS Ra6mHuQywp1ZrukDEZ9gYyhgITOLeYStx1VewEQX5AuTSI1J+HhoN8J/hTgv6wCkwS tvIewl+GCmuwQ== Received: by pali.im (Postfix) id 67CEAC77; Tue, 1 Mar 2022 10:47:07 +0100 (CET) Date: Tue, 1 Mar 2022 10:47:07 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Bjorn Helgaas Cc: Lorenzo Pieralisi , Bjorn Helgaas , Rob Herring , Andrew Lunn , Thomas Petazzoni , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Marek =?utf-8?B?QmVow7pu?= , Russell King , Gregory Clement , linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/6] PCI: mvebu: Add support for sending Set_Slot_Power_Limit message Message-ID: <20220301094707.64jbqpoxhmana7ua@pali> References: <20220225125407.wglplhyisgges3zk@pali> <20220225165731.GA359939@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220225165731.GA359939@bhelgaas> User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 25 February 2022 10:57:31 Bjorn Helgaas wrote: > On Fri, Feb 25, 2022 at 01:54:07PM +0100, Pali Rohár wrote: > > On Thursday 24 February 2022 15:28:11 Bjorn Helgaas wrote: > > > On Tue, Feb 22, 2022 at 05:31:57PM +0100, Pali Rohár wrote: > > > > This PCIe message is sent automatically by mvebu HW when link changes > > > > status from down to up. > > > > > + * Program Root Complex to automatically sends Set Slot Power Limit > > > > + * PCIe Message when changing status from Dl-Down to Dl-Up and valid > > > > + * slot power limit was specified. > > > > > > s/Root Complex/Root Port/, right? AFAIK the message would be sent by > > > a Downstream Port, i.e., a Root Port in this case. > > > > Yes! > > > > I see that on more places that names "Root Port", "Root Bridge" and > > "Root Complex" used as the one thing. > > > > It is probably because HW has only one Root Port and is integrated into > > same silicon as Root Complex and shares HW registers. And Root Port has > > PCI class code "PCI Bridge", hence Root Bridge. > > > > But I agree that correct name is "Root Port". > > > > Moreover in Armada 38x Functional Specification is this register named > > "Root Complex Set Slot Power Limit" and not Root "Port". > > Haha, yes, sounds like this stems from the knowledge that "of course > this Root Complex only has one Root Port, so there's no real > difference between them." > > So I think it makes sense for #defines for device-specific registers > like PCIE_SSPL_OFF to match the Armada spec, but I think it would be > better if the comments and code structure did not have the assumption > that there's only one Root Port baked into them. For one thing, this > can help make the driver structure more uniform across all the > drivers. Ok! > > > s/sends/send/ > > > s/Set Slot Power Limit/Set_Slot_Power_Limit/ to match spec usage (also > > > below) > > > s/Dl-Down/DL_Down/ to match spec usage > > > s/Dl-Up/DL_Up/ ditto > > > > In Armada 38x Functional Specification spec it is called like I wrote > > and some people told me to use "naming" as written in SoC/HW > > specification to not confuse other people who are writing / developing > > drivers according to official SoC/HW specification. > > > > I see that both has pro and cons. Usage of terminology from PCIe spec is > > what PCIe people expect and terminology from vendor SoC HW spec is what > > people who develop that SoC expect. > > > > I can update and change comments without issue to any variant which you > > prefer. No problem with it. Just I wanted to write why I chose those > > names. > > All these concepts are purely PCIe. There is no Armada-specific > meaning because they have to behave as specified by the PCIe spec so > they work across the Link with non-Armada devices on the other end. > If the Armada spec spells them differently, I claim that's an editing > mistake in that spec. > > My preference is to use the PCIe spec naming except for > Armada-specific things. The Armada spellings don't appear in the PCIe > spec, so it's just an unnecessary irritant when trying to look them > up. Ok! > > > > + case PCI_EXP_SLTCTL: > > > > + if ((mask & PCI_EXP_SLTCTL_ASPL_DISABLE) && > > > > + port->slot_power_limit_value && > > > > + port->slot_power_limit_scale) { > > > > + u32 sspl = mvebu_readl(port, PCIE_SSPL_OFF); > > > > + if (new & PCI_EXP_SLTCTL_ASPL_DISABLE) > > > > + sspl &= ~PCIE_SSPL_ENABLE; > > > > + else > > > > + sspl |= PCIE_SSPL_ENABLE; > > > > + mvebu_writel(port, sspl, PCIE_SSPL_OFF); > > > > > > IIUC, the behavior of PCI_EXP_SLTCTL_ASPL_DISABLE as observed by > > > software that sets it and reads it back will depend on whether the DT > > > contains "slot-power-limit-milliwatt". > > > > > > If there is no DT property, port->slot_power_limit_value will be zero > > > and PCIE_SSPL_ENABLE will never be set. So if I clear > > > PCI_EXP_SLTCTL_ASPL_DISABLE, then read it back, it looks like it will > > > read as being set. > > > > Yes. > > > > > That's not what I would expect from the spec (PCIe r6.0, sec 7.5.3.10). > > > > Ok. What you would expect here? That PCI_EXP_SLTCTL_ASPL_DISABLE is not > > set even when Set_Slot_Power_Limit was never sent and would be never > > sent (as it was not programmed by firmware = in DT)? > > Per spec, I would expect PCI_EXP_SLTCTL_ASPL_DISABLE to be either: > > - Hardwired to 0, so writes have no effect and reads always return > 0, or > > - Writable, so a read always returns what was previously written. > > Here's the relevant text from r6.0, sec 7.5.3.10: > > Auto Slot Power Limit Disable - When Set, this disables the > automatic sending of a Set_Slot_Power_Limit Message when a Link > transitions from a non-DL_Up status to a DL_Up status. > > Downstream ports that don’t support DPC are permitted to hardwire > this bit to 0. > > Default value of this bit is implementation specific. > > AFAICT, the Slot Power Control mechanism is required for all devices, > but without "slot-power-limit-milliwatt", we don't know what limit to > use. Apparently the CEM specs specify minimum values, but they depend > on the form factor. > > From r6.0, sec 6.9: > > For Adapters: > > - Until and unless a Set_Slot_Power_Limit Message is received > indicating a Slot Power Limit value greater than the lowest > value specified in the form factor specification for the > adapter's form factor, the adapter must not consume more than > the lowest value specified. > > - An adapter must never consume more power than what was specified > in the most recently received Set_Slot_Power_Limit Message or > the minimum value specified in the corresponding form factor > specification, whichever is higher. > > If PCIE_SSPL_ENABLE is never set, Set_Slot_Power_Limit will never be > sent, and the device is not allowed to consume more than the minimum > power specified by its form factor spec. > > I'd say reading PCI_EXP_SLTCTL should return whatever > PCI_EXP_SLTCTL_ASPL_DISABLE value was most recently written, but we > should set PCIE_SSPL_ENABLE only when we have a > "slot-power-limit-milliwatt" property AND > PCI_EXP_SLTCTL_ASPL_DISABLE == 0. > > Does that make sense? Yes! 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8B2A9C433EF for ; Tue, 1 Mar 2022 09:48:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+6O4rnZ4gTMMjiS/pLOPpCjUM3sV/R59BQbk3UWxvR8=; b=hACA6oOFZ0FdG+ nb6ryi/iHv3P27q6MyvYsBNheYRtHLvYev+n5dBg7BwvJFeAOcY/xmoBkvlqUsT0V0l+7f2sW5ONh N1WtacsFEePTDgE4L6R41YQ806QBxCx6grGAZwF0ancMj9SZ91qHphSmUrHlU2tuRxKpJjiT5C5kC 01Xuz66Kngax3PV2JyaIPy3XpIEGQliHy0b1tEUXJhjg5YTH2gLHVId5GBw7hTdzsjfutoOPiLiZg WNjUsvKUoBoRx1NNPbmgnbDfXC0CxoVrswsysjVZ2JhggQlHndMzSr8pSzCTg6qX0IAiqcTZ4aPGC L67M9bhMUruAgRZ6BAjQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOz6F-00FuID-6B; Tue, 01 Mar 2022 09:47:19 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nOz6B-00FuHN-6i for linux-arm-kernel@lists.infradead.org; Tue, 01 Mar 2022 09:47:17 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D640AB81654; Tue, 1 Mar 2022 09:47:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32853C340EE; Tue, 1 Mar 2022 09:47:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646128030; bh=bIEyEZCYsYHYD4lz+YBrbdVvQiVr4Nv4bmNiO9AhL4I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hQMMlXanjwsY0GvyqcfaeYDkD7UPWfXKsRh3SU34twWSptfTIm7Tv48s3LKORwKSE aGw9cpI51eIW1iNYFG1IASAGOiT3V0vGDk1g3GHtp5t9gGTyv7g0T+C4a+KHz4imaq Bua7vWOfr8KfPCfeobB0ionRCQR/lCLjiCzxxETMrGd8I0nTkOE4cugEimddghBWLF HWibgvIVSMOOI/hhhcYULMAD6QNwwVd22+U4bi5csnO1KywIiGbSWAkfsULI7VpMdS Ra6mHuQywp1ZrukDEZ9gYyhgITOLeYStx1VewEQX5AuTSI1J+HhoN8J/hTgv6wCkwS tvIewl+GCmuwQ== Received: by pali.im (Postfix) id 67CEAC77; Tue, 1 Mar 2022 10:47:07 +0100 (CET) Date: Tue, 1 Mar 2022 10:47:07 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Bjorn Helgaas Cc: Lorenzo Pieralisi , Bjorn Helgaas , Rob Herring , Andrew Lunn , Thomas Petazzoni , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Marek =?utf-8?B?QmVow7pu?= , Russell King , Gregory Clement , linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/6] PCI: mvebu: Add support for sending Set_Slot_Power_Limit message Message-ID: <20220301094707.64jbqpoxhmana7ua@pali> References: <20220225125407.wglplhyisgges3zk@pali> <20220225165731.GA359939@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220225165731.GA359939@bhelgaas> User-Agent: NeoMutt/20180716 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220301_014715_586898_1C756998 X-CRM114-Status: GOOD ( 53.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gRnJpZGF5IDI1IEZlYnJ1YXJ5IDIwMjIgMTA6NTc6MzEgQmpvcm4gSGVsZ2FhcyB3cm90ZToK PiBPbiBGcmksIEZlYiAyNSwgMjAyMiBhdCAwMTo1NDowN1BNICswMTAwLCBQYWxpIFJvaMOhciB3 cm90ZToKPiA+IE9uIFRodXJzZGF5IDI0IEZlYnJ1YXJ5IDIwMjIgMTU6Mjg6MTEgQmpvcm4gSGVs Z2FhcyB3cm90ZToKPiA+ID4gT24gVHVlLCBGZWIgMjIsIDIwMjIgYXQgMDU6MzE6NTdQTSArMDEw MCwgUGFsaSBSb2jDoXIgd3JvdGU6Cj4gPiA+ID4gVGhpcyBQQ0llIG1lc3NhZ2UgaXMgc2VudCBh dXRvbWF0aWNhbGx5IGJ5IG12ZWJ1IEhXIHdoZW4gbGluayBjaGFuZ2VzCj4gPiA+ID4gc3RhdHVz IGZyb20gZG93biB0byB1cC4KPiAKPiA+ID4gPiArCSAqIFByb2dyYW0gUm9vdCBDb21wbGV4IHRv IGF1dG9tYXRpY2FsbHkgc2VuZHMgU2V0IFNsb3QgUG93ZXIgTGltaXQKPiA+ID4gPiArCSAqIFBD SWUgTWVzc2FnZSB3aGVuIGNoYW5naW5nIHN0YXR1cyBmcm9tIERsLURvd24gdG8gRGwtVXAgYW5k IHZhbGlkCj4gPiA+ID4gKwkgKiBzbG90IHBvd2VyIGxpbWl0IHdhcyBzcGVjaWZpZWQuCj4gPiA+ IAo+ID4gPiBzL1Jvb3QgQ29tcGxleC9Sb290IFBvcnQvLCByaWdodD8gIEFGQUlLIHRoZSBtZXNz YWdlIHdvdWxkIGJlIHNlbnQgYnkKPiA+ID4gYSBEb3duc3RyZWFtIFBvcnQsIGkuZS4sIGEgUm9v dCBQb3J0IGluIHRoaXMgY2FzZS4KPiA+IAo+ID4gWWVzIQo+ID4gCj4gPiBJIHNlZSB0aGF0IG9u IG1vcmUgcGxhY2VzIHRoYXQgbmFtZXMgIlJvb3QgUG9ydCIsICJSb290IEJyaWRnZSIgYW5kCj4g PiAiUm9vdCBDb21wbGV4IiB1c2VkIGFzIHRoZSBvbmUgdGhpbmcuCj4gPiAKPiA+IEl0IGlzIHBy b2JhYmx5IGJlY2F1c2UgSFcgaGFzIG9ubHkgb25lIFJvb3QgUG9ydCBhbmQgaXMgaW50ZWdyYXRl ZCBpbnRvCj4gPiBzYW1lIHNpbGljb24gYXMgUm9vdCBDb21wbGV4IGFuZCBzaGFyZXMgSFcgcmVn aXN0ZXJzLiBBbmQgUm9vdCBQb3J0IGhhcwo+ID4gUENJIGNsYXNzIGNvZGUgIlBDSSBCcmlkZ2Ui LCBoZW5jZSBSb290IEJyaWRnZS4KPiA+IAo+ID4gQnV0IEkgYWdyZWUgdGhhdCBjb3JyZWN0IG5h bWUgaXMgIlJvb3QgUG9ydCIuCj4gPiAKPiA+IE1vcmVvdmVyIGluIEFybWFkYSAzOHggRnVuY3Rp b25hbCBTcGVjaWZpY2F0aW9uIGlzIHRoaXMgcmVnaXN0ZXIgbmFtZWQKPiA+ICJSb290IENvbXBs ZXggU2V0IFNsb3QgUG93ZXIgTGltaXQiIGFuZCBub3QgUm9vdCAiUG9ydCIuCj4gCj4gSGFoYSwg eWVzLCBzb3VuZHMgbGlrZSB0aGlzIHN0ZW1zIGZyb20gdGhlIGtub3dsZWRnZSB0aGF0ICJvZiBj b3Vyc2UKPiB0aGlzIFJvb3QgQ29tcGxleCBvbmx5IGhhcyBvbmUgUm9vdCBQb3J0LCBzbyB0aGVy ZSdzIG5vIHJlYWwKPiBkaWZmZXJlbmNlIGJldHdlZW4gdGhlbS4iCj4gCj4gU28gSSB0aGluayBp dCBtYWtlcyBzZW5zZSBmb3IgI2RlZmluZXMgZm9yIGRldmljZS1zcGVjaWZpYyByZWdpc3RlcnMK PiBsaWtlIFBDSUVfU1NQTF9PRkYgdG8gbWF0Y2ggdGhlIEFybWFkYSBzcGVjLCBidXQgSSB0aGlu ayBpdCB3b3VsZCBiZQo+IGJldHRlciBpZiB0aGUgY29tbWVudHMgYW5kIGNvZGUgc3RydWN0dXJl IGRpZCBub3QgaGF2ZSB0aGUgYXNzdW1wdGlvbgo+IHRoYXQgdGhlcmUncyBvbmx5IG9uZSBSb290 IFBvcnQgYmFrZWQgaW50byB0aGVtLiAgRm9yIG9uZSB0aGluZywgdGhpcwo+IGNhbiBoZWxwIG1h a2UgdGhlIGRyaXZlciBzdHJ1Y3R1cmUgbW9yZSB1bmlmb3JtIGFjcm9zcyBhbGwgdGhlCj4gZHJp dmVycy4KCk9rIQoKPiA+ID4gcy9zZW5kcy9zZW5kLwo+ID4gPiBzL1NldCBTbG90IFBvd2VyIExp bWl0L1NldF9TbG90X1Bvd2VyX0xpbWl0LyB0byBtYXRjaCBzcGVjIHVzYWdlIChhbHNvCj4gPiA+ IGJlbG93KQo+ID4gPiBzL0RsLURvd24vRExfRG93bi8gdG8gbWF0Y2ggc3BlYyB1c2FnZQo+ID4g PiBzL0RsLVVwL0RMX1VwLyBkaXR0bwo+ID4gCj4gPiBJbiBBcm1hZGEgMzh4IEZ1bmN0aW9uYWwg U3BlY2lmaWNhdGlvbiBzcGVjIGl0IGlzIGNhbGxlZCBsaWtlIEkgd3JvdGUKPiA+IGFuZCBzb21l IHBlb3BsZSB0b2xkIG1lIHRvIHVzZSAibmFtaW5nIiBhcyB3cml0dGVuIGluIFNvQy9IVwo+ID4g c3BlY2lmaWNhdGlvbiB0byBub3QgY29uZnVzZSBvdGhlciBwZW9wbGUgd2hvIGFyZSB3cml0aW5n IC8gZGV2ZWxvcGluZwo+ID4gZHJpdmVycyBhY2NvcmRpbmcgdG8gb2ZmaWNpYWwgU29DL0hXIHNw ZWNpZmljYXRpb24uCj4gPiAKPiA+IEkgc2VlIHRoYXQgYm90aCBoYXMgcHJvIGFuZCBjb25zLiBV c2FnZSBvZiB0ZXJtaW5vbG9neSBmcm9tIFBDSWUgc3BlYyBpcwo+ID4gd2hhdCBQQ0llIHBlb3Bs ZSBleHBlY3QgYW5kIHRlcm1pbm9sb2d5IGZyb20gdmVuZG9yIFNvQyBIVyBzcGVjIGlzIHdoYXQK PiA+IHBlb3BsZSB3aG8gZGV2ZWxvcCB0aGF0IFNvQyBleHBlY3QuCj4gPiAKPiA+IEkgY2FuIHVw ZGF0ZSBhbmQgY2hhbmdlIGNvbW1lbnRzIHdpdGhvdXQgaXNzdWUgdG8gYW55IHZhcmlhbnQgd2hp Y2ggeW91Cj4gPiBwcmVmZXIuIE5vIHByb2JsZW0gd2l0aCBpdC4gSnVzdCBJIHdhbnRlZCB0byB3 cml0ZSB3aHkgSSBjaG9zZSB0aG9zZQo+ID4gbmFtZXMuCj4gCj4gQWxsIHRoZXNlIGNvbmNlcHRz IGFyZSBwdXJlbHkgUENJZS4gIFRoZXJlIGlzIG5vIEFybWFkYS1zcGVjaWZpYwo+IG1lYW5pbmcg YmVjYXVzZSB0aGV5IGhhdmUgdG8gYmVoYXZlIGFzIHNwZWNpZmllZCBieSB0aGUgUENJZSBzcGVj IHNvCj4gdGhleSB3b3JrIGFjcm9zcyB0aGUgTGluayB3aXRoIG5vbi1Bcm1hZGEgZGV2aWNlcyBv biB0aGUgb3RoZXIgZW5kLgo+IElmIHRoZSBBcm1hZGEgc3BlYyBzcGVsbHMgdGhlbSBkaWZmZXJl bnRseSwgSSBjbGFpbSB0aGF0J3MgYW4gZWRpdGluZwo+IG1pc3Rha2UgaW4gdGhhdCBzcGVjLgo+ IAo+IE15IHByZWZlcmVuY2UgaXMgdG8gdXNlIHRoZSBQQ0llIHNwZWMgbmFtaW5nIGV4Y2VwdCBm b3IKPiBBcm1hZGEtc3BlY2lmaWMgdGhpbmdzLiAgVGhlIEFybWFkYSBzcGVsbGluZ3MgZG9uJ3Qg YXBwZWFyIGluIHRoZSBQQ0llCj4gc3BlYywgc28gaXQncyBqdXN0IGFuIHVubmVjZXNzYXJ5IGly cml0YW50IHdoZW4gdHJ5aW5nIHRvIGxvb2sgdGhlbQo+IHVwLgoKT2shCgo+ID4gPiA+ICsJY2Fz ZSBQQ0lfRVhQX1NMVENUTDoKPiA+ID4gPiArCQlpZiAoKG1hc2sgJiBQQ0lfRVhQX1NMVENUTF9B U1BMX0RJU0FCTEUpICYmCj4gPiA+ID4gKwkJICAgIHBvcnQtPnNsb3RfcG93ZXJfbGltaXRfdmFs dWUgJiYKPiA+ID4gPiArCQkgICAgcG9ydC0+c2xvdF9wb3dlcl9saW1pdF9zY2FsZSkgewo+ID4g PiA+ICsJCQl1MzIgc3NwbCA9IG12ZWJ1X3JlYWRsKHBvcnQsIFBDSUVfU1NQTF9PRkYpOwo+ID4g PiA+ICsJCQlpZiAobmV3ICYgUENJX0VYUF9TTFRDVExfQVNQTF9ESVNBQkxFKQo+ID4gPiA+ICsJ CQkJc3NwbCAmPSB+UENJRV9TU1BMX0VOQUJMRTsKPiA+ID4gPiArCQkJZWxzZQo+ID4gPiA+ICsJ CQkJc3NwbCB8PSBQQ0lFX1NTUExfRU5BQkxFOwo+ID4gPiA+ICsJCQltdmVidV93cml0ZWwocG9y dCwgc3NwbCwgUENJRV9TU1BMX09GRik7Cj4gPiA+IAo+ID4gPiBJSVVDLCB0aGUgYmVoYXZpb3Ig b2YgUENJX0VYUF9TTFRDVExfQVNQTF9ESVNBQkxFIGFzIG9ic2VydmVkIGJ5Cj4gPiA+IHNvZnR3 YXJlIHRoYXQgc2V0cyBpdCBhbmQgcmVhZHMgaXQgYmFjayB3aWxsIGRlcGVuZCBvbiB3aGV0aGVy IHRoZSBEVAo+ID4gPiBjb250YWlucyAic2xvdC1wb3dlci1saW1pdC1taWxsaXdhdHQiLgo+ID4g PiAKPiA+ID4gSWYgdGhlcmUgaXMgbm8gRFQgcHJvcGVydHksIHBvcnQtPnNsb3RfcG93ZXJfbGlt aXRfdmFsdWUgd2lsbCBiZSB6ZXJvCj4gPiA+IGFuZCBQQ0lFX1NTUExfRU5BQkxFIHdpbGwgbmV2 ZXIgYmUgc2V0LiAgU28gaWYgSSBjbGVhcgo+ID4gPiBQQ0lfRVhQX1NMVENUTF9BU1BMX0RJU0FC TEUsIHRoZW4gcmVhZCBpdCBiYWNrLCBpdCBsb29rcyBsaWtlIGl0IHdpbGwKPiA+ID4gcmVhZCBh cyBiZWluZyBzZXQuCj4gPiAKPiA+IFllcy4KPiA+IAo+ID4gPiBUaGF0J3Mgbm90IHdoYXQgSSB3 b3VsZCBleHBlY3QgZnJvbSB0aGUgc3BlYyAoUENJZSByNi4wLCBzZWMgNy41LjMuMTApLgo+ID4g Cj4gPiBPay4gV2hhdCB5b3Ugd291bGQgZXhwZWN0IGhlcmU/IFRoYXQgUENJX0VYUF9TTFRDVExf QVNQTF9ESVNBQkxFIGlzIG5vdAo+ID4gc2V0IGV2ZW4gd2hlbiBTZXRfU2xvdF9Qb3dlcl9MaW1p dCB3YXMgbmV2ZXIgc2VudCBhbmQgd291bGQgYmUgbmV2ZXIKPiA+IHNlbnQgKGFzIGl0IHdhcyBu b3QgcHJvZ3JhbW1lZCBieSBmaXJtd2FyZSA9IGluIERUKT8KPiAKPiBQZXIgc3BlYywgSSB3b3Vs ZCBleHBlY3QgUENJX0VYUF9TTFRDVExfQVNQTF9ESVNBQkxFIHRvIGJlIGVpdGhlcjoKPiAKPiAg IC0gSGFyZHdpcmVkIHRvIDAsIHNvIHdyaXRlcyBoYXZlIG5vIGVmZmVjdCBhbmQgcmVhZHMgYWx3 YXlzIHJldHVybgo+ICAgICAwLCBvcgo+IAo+ICAgLSBXcml0YWJsZSwgc28gYSByZWFkIGFsd2F5 cyByZXR1cm5zIHdoYXQgd2FzIHByZXZpb3VzbHkgd3JpdHRlbi4KPiAKPiBIZXJlJ3MgdGhlIHJl bGV2YW50IHRleHQgZnJvbSByNi4wLCBzZWMgNy41LjMuMTA6Cj4gCj4gICBBdXRvIFNsb3QgUG93 ZXIgTGltaXQgRGlzYWJsZSAtIFdoZW4gU2V0LCB0aGlzIGRpc2FibGVzIHRoZQo+ICAgYXV0b21h dGljIHNlbmRpbmcgb2YgYSBTZXRfU2xvdF9Qb3dlcl9MaW1pdCBNZXNzYWdlIHdoZW4gYSBMaW5r Cj4gICB0cmFuc2l0aW9ucyBmcm9tIGEgbm9uLURMX1VwIHN0YXR1cyB0byBhIERMX1VwIHN0YXR1 cy4KPiAKPiAgIERvd25zdHJlYW0gcG9ydHMgdGhhdCBkb27igJl0IHN1cHBvcnQgRFBDIGFyZSBw ZXJtaXR0ZWQgdG8gaGFyZHdpcmUKPiAgIHRoaXMgYml0IHRvIDAuCj4gCj4gICBEZWZhdWx0IHZh bHVlIG9mIHRoaXMgYml0IGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLgo+IAo+IEFGQUlDVCwg dGhlIFNsb3QgUG93ZXIgQ29udHJvbCBtZWNoYW5pc20gaXMgcmVxdWlyZWQgZm9yIGFsbCBkZXZp Y2VzLAo+IGJ1dCB3aXRob3V0ICJzbG90LXBvd2VyLWxpbWl0LW1pbGxpd2F0dCIsIHdlIGRvbid0 IGtub3cgd2hhdCBsaW1pdCB0bwo+IHVzZS4gIEFwcGFyZW50bHkgdGhlIENFTSBzcGVjcyBzcGVj aWZ5IG1pbmltdW0gdmFsdWVzLCBidXQgdGhleSBkZXBlbmQKPiBvbiB0aGUgZm9ybSBmYWN0b3Iu Cj4gCj4gRnJvbSByNi4wLCBzZWMgNi45Ogo+IAo+ICAgRm9yIEFkYXB0ZXJzOgo+IAo+ICAgICAt IFVudGlsIGFuZCB1bmxlc3MgYSBTZXRfU2xvdF9Qb3dlcl9MaW1pdCBNZXNzYWdlIGlzIHJlY2Vp dmVkCj4gICAgICAgaW5kaWNhdGluZyBhIFNsb3QgUG93ZXIgTGltaXQgdmFsdWUgZ3JlYXRlciB0 aGFuIHRoZSBsb3dlc3QKPiAgICAgICB2YWx1ZSBzcGVjaWZpZWQgaW4gdGhlIGZvcm0gZmFjdG9y IHNwZWNpZmljYXRpb24gZm9yIHRoZQo+ICAgICAgIGFkYXB0ZXIncyBmb3JtIGZhY3RvciwgdGhl IGFkYXB0ZXIgbXVzdCBub3QgY29uc3VtZSBtb3JlIHRoYW4KPiAgICAgICB0aGUgbG93ZXN0IHZh bHVlIHNwZWNpZmllZC4KPiAKPiAgICAgLSBBbiBhZGFwdGVyIG11c3QgbmV2ZXIgY29uc3VtZSBt b3JlIHBvd2VyIHRoYW4gd2hhdCB3YXMgc3BlY2lmaWVkCj4gICAgICAgaW4gdGhlIG1vc3QgcmVj ZW50bHkgcmVjZWl2ZWQgU2V0X1Nsb3RfUG93ZXJfTGltaXQgTWVzc2FnZSBvcgo+ICAgICAgIHRo ZSBtaW5pbXVtIHZhbHVlIHNwZWNpZmllZCBpbiB0aGUgY29ycmVzcG9uZGluZyBmb3JtIGZhY3Rv cgo+ICAgICAgIHNwZWNpZmljYXRpb24sIHdoaWNoZXZlciBpcyBoaWdoZXIuCj4gCj4gSWYgUENJ RV9TU1BMX0VOQUJMRSBpcyBuZXZlciBzZXQsIFNldF9TbG90X1Bvd2VyX0xpbWl0IHdpbGwgbmV2 ZXIgYmUKPiBzZW50LCBhbmQgdGhlIGRldmljZSBpcyBub3QgYWxsb3dlZCB0byBjb25zdW1lIG1v cmUgdGhhbiB0aGUgbWluaW11bQo+IHBvd2VyIHNwZWNpZmllZCBieSBpdHMgZm9ybSBmYWN0b3Ig c3BlYy4KPiAKPiBJJ2Qgc2F5IHJlYWRpbmcgUENJX0VYUF9TTFRDVEwgc2hvdWxkIHJldHVybiB3 aGF0ZXZlcgo+IFBDSV9FWFBfU0xUQ1RMX0FTUExfRElTQUJMRSB2YWx1ZSB3YXMgbW9zdCByZWNl bnRseSB3cml0dGVuLCBidXQgd2UKPiBzaG91bGQgc2V0IFBDSUVfU1NQTF9FTkFCTEUgb25seSB3 aGVuIHdlIGhhdmUgYQo+ICJzbG90LXBvd2VyLWxpbWl0LW1pbGxpd2F0dCIgcHJvcGVydHkgQU5E Cj4gUENJX0VYUF9TTFRDVExfQVNQTF9ESVNBQkxFID09IDAuCj4gCj4gRG9lcyB0aGF0IG1ha2Ug c2Vuc2U/CgpZZXMhCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3Rz LmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5m by9saW51eC1hcm0ta2VybmVsCg==