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 25C05C433EF for ; Tue, 25 Jan 2022 20:40:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232255AbiAYUkJ (ORCPT ); Tue, 25 Jan 2022 15:40:09 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:37472 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232253AbiAYUkJ (ORCPT ); Tue, 25 Jan 2022 15:40:09 -0500 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 31E03B81A29; Tue, 25 Jan 2022 20:40:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6D09C340E0; Tue, 25 Jan 2022 20:40:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643143206; bh=RUJ918iEX3MuMXSIBIgjXfg8HKd6kX+Z35rkfk4Qzu4=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=Q7vG8ygrYGGJegIsF9SmIe9kkWW5NLPEhrvS3NPHY/kS2AeEU3CxqMtsYCTUK0WAb vluUuVzaaiJmZEc6BMhswBhF8P+HD95ViXZs4HEv9+4MSJWTjxS0WTidG2iXKGHRDd LtKz+0YVPc+QD5MI1n4PML4NPA8NaAb/tWyeBSPiJoUtCzXeEdXuNGbFOoOlTar3ca Jz2FajMn+Aw6sbGo8iGxqQVfCZFGKT4rAkYLiCsWrFCti4Z3hdKPvNEqLzfyHAhZz6 FpzNgiv5ipkOXz85BL/3hVRnYLJyEfiYIBK9D4D/DWe8WP6wqxtV2Jco1aa+YioEh8 Fauz5GV/pixOA== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20220120092641.o4ffzeyakhuuf3c7@pali> References: <20211015093701.pfvkighxsndj4ujg@pali> <20211016064210.7ahqfqcvf66wtt66@pali> <20220115080213.0CCAFC36AE3@smtp.kernel.org> <20220115115018.he4hnnhlvrb6kann@pali> <20220115130509.4a240730@thinkpad> <20220115122618.plhiqnjh2755bv5h@pali> <20220119231655.EFFF3C004E1@smtp.kernel.org> <20220120000651.in7s6nazif5qjkme@pali> <20220120060149.0FF24C340E0@smtp.kernel.org> <20220120092641.o4ffzeyakhuuf3c7@pali> Subject: Re: [PATCH v7 3/6] dt-bindings: mvebu-uart: document DT bindings for marvell,armada-3700-uart-clock From: Stephen Boyd Cc: Marek =?utf-8?q?Beh=C3=BAn?= , Greg Kroah-Hartman , Michael Turquette , Rob Herring , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Vladimir Vid , linux-clk@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org To: Pali =?utf-8?q?Roh=C3=A1r?= Date: Tue, 25 Jan 2022 12:40:04 -0800 User-Agent: alot/0.10 Message-Id: <20220125204006.A6D09C340E0@smtp.kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org Quoting Pali Roh=C3=A1r (2022-01-20 01:26:41) > On Wednesday 19 January 2022 22:01:47 Stephen Boyd wrote: > > >=20 > > > Ok, now I see what you mean. > > >=20 > > > But problem is that this is not backward compatible change. And would > > > not work per existing DT bindings definitions, which defines how > > > bootloader should set configured clocks. > > >=20 > > > As I wrote in emails 3 months ago, this new "proposed" DTS definition= is > > > something which I would have chosen if I had designed this driver and > > > bindings in past. But that did not happen and different approach is > > > already widely in used. > > >=20 > > > To support existing DTS definitions and bootloaders, it is really > > > required to have current structure backward compatible like it is > > > defined in current DT bindings document. And my changes in this patch > > > series are backward compatible. > >=20 > > I'm lost. Is the bootloader the one that's expecting some particular > > serial node format and updating something? What is the bootloader doing? >=20 > If bootloader uses or configures UART to different clock it needs to > update "clocks" property in DT. Otherwise UART would be unusable and > there would be no dmesg output. Got it! I didn't see that part mentioned anywhere in the commit text though. To the uninformed reviewer like me it is hard to know about this bootloader design unless the commit text explains that there's no other way to do this. >=20 > A3720 heavily depends that bootloader patches at boot time DTB file to > the layout of the current hardware. >=20 > > >=20 > > > To change DTS structure, it would be needed to provide uart nodes in = DTS > > > files two times: once in old style (the current one) and second time = in > > > this new style. > >=20 > > That's not a good idea. Why do we need to support both at the same time? >=20 > Because old bootloaders do not and will never support this new style. It > is not only linux kernel project who provides DTB files. Also bootloader > itself has own DTB files and use it for booting (e.g kernel). For some > boards is in-kernel-tree DTS file only as a reference. So it is > important that kernel can use and support DTS files from old version and > also from the new patched version. Gregory (A3720 DTS files maintainer) > always ask me what happens if I try to boot new patched kernel drivers > with old unmodified DTS files and wants to know if nothing is broken by > introduced changed. >=20 > > >=20 > > > But such thing would even more complicate updating driver and it needs > > > to be implemented. > > >=20 > > > Plus this would open a question how to define default stdout-path if > > > there would be 4 serial nodes, where one pair would describe old style > > > and second pair new style; meaning that 2 cross nodes would describe > > > same define. > >=20 > > Huh? We shouldn't have both bindings present in the DTB. >=20 > Ideally yes, I would like to see to prevent it. But for backward > compatibility we really need old bindings still present (as explained > above). >=20 > So really I see two options here: Make changes in patches backward > compatible (old nodes stay in DT and also kernel would be able to use > old DT). Or let old bindings untouched in DT and new backward > incompatible definitions would have to be in separate nodes. Ok I understand now. We have to keep both the serial nodes because the bootloader is patching them. To make matters worse, one or the other node may be disabled so we can't even add the new bits to the uart1 node. Can you update the commit text to record this sad state of affairs and indicate that the only way to support this is to make a new node in DT that the bootloader doesn't know about? 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 753B1C433F5 for ; Tue, 25 Jan 2022 20:41:26 +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:Message-Id:Date:To:Cc:From:Subject: References:In-Reply-To:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XsDVGMVdBiEeos2Q/XljmZVE5iOncCuv45iMDx4/WGQ=; b=Zvam0CWagxzzl9 7RtQDWA3YkMTXsIEUv1mpPPhXDEw0JtS3EGES9ZW2Wg3RheczVCjmfcUL7E+kfKZluKQJtrlhHUm/ RjLebgMvAssNltsCY8IXR90WSO7t5QtdghG0ZM6qPdIt6nFJQGGfGz3vucqarXV+yeboQMRP4f6y1 +sEY0VI25OTWCwMJ0FJ7Y2KLsHsfFQ9ZuWJcKdyqhjapy5dV2VOqU2cRY+ZKFwLi78qlwhdv+tv9s DJHgX0hLGL16nJIZ5uxlmlWwkiwxntll3/V5NK8a2PRsk6OqFb52GnGUj3y5aD5ivvrzUZeG8I2HF worjoYw083a1alk9LA2A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCSbr-009WRP-4L; Tue, 25 Jan 2022 20:40:11 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCSbn-009WR5-Ov for linux-arm-kernel@lists.infradead.org; Tue, 25 Jan 2022 20:40:09 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 59B176177A; Tue, 25 Jan 2022 20:40:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6D09C340E0; Tue, 25 Jan 2022 20:40:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1643143206; bh=RUJ918iEX3MuMXSIBIgjXfg8HKd6kX+Z35rkfk4Qzu4=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=Q7vG8ygrYGGJegIsF9SmIe9kkWW5NLPEhrvS3NPHY/kS2AeEU3CxqMtsYCTUK0WAb vluUuVzaaiJmZEc6BMhswBhF8P+HD95ViXZs4HEv9+4MSJWTjxS0WTidG2iXKGHRDd LtKz+0YVPc+QD5MI1n4PML4NPA8NaAb/tWyeBSPiJoUtCzXeEdXuNGbFOoOlTar3ca Jz2FajMn+Aw6sbGo8iGxqQVfCZFGKT4rAkYLiCsWrFCti4Z3hdKPvNEqLzfyHAhZz6 FpzNgiv5ipkOXz85BL/3hVRnYLJyEfiYIBK9D4D/DWe8WP6wqxtV2Jco1aa+YioEh8 Fauz5GV/pixOA== MIME-Version: 1.0 In-Reply-To: <20220120092641.o4ffzeyakhuuf3c7@pali> References: <20211015093701.pfvkighxsndj4ujg@pali> <20211016064210.7ahqfqcvf66wtt66@pali> <20220115080213.0CCAFC36AE3@smtp.kernel.org> <20220115115018.he4hnnhlvrb6kann@pali> <20220115130509.4a240730@thinkpad> <20220115122618.plhiqnjh2755bv5h@pali> <20220119231655.EFFF3C004E1@smtp.kernel.org> <20220120000651.in7s6nazif5qjkme@pali> <20220120060149.0FF24C340E0@smtp.kernel.org> <20220120092641.o4ffzeyakhuuf3c7@pali> Subject: Re: [PATCH v7 3/6] dt-bindings: mvebu-uart: document DT bindings for marvell, armada-3700-uart-clock From: Stephen Boyd Cc: Marek =?utf-8?q?Beh=C3=BAn?= , Greg Kroah-Hartman , Michael Turquette , Rob Herring , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Vladimir Vid , linux-clk@vger.kernel.org, linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org To: Pali =?utf-8?q?Roh=C3=A1r?= Date: Tue, 25 Jan 2022 12:40:04 -0800 User-Agent: alot/0.10 Message-Id: <20220125204006.A6D09C340E0@smtp.kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220125_124007_919045_C0D3C5A2 X-CRM114-Status: GOOD ( 38.77 ) 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 UXVvdGluZyBQYWxpIFJvaMOhciAoMjAyMi0wMS0yMCAwMToyNjo0MSkKPiBPbiBXZWRuZXNkYXkg MTkgSmFudWFyeSAyMDIyIDIyOjAxOjQ3IFN0ZXBoZW4gQm95ZCB3cm90ZToKPiA+ID4gCj4gPiA+ IE9rLCBub3cgSSBzZWUgd2hhdCB5b3UgbWVhbi4KPiA+ID4gCj4gPiA+IEJ1dCBwcm9ibGVtIGlz IHRoYXQgdGhpcyBpcyBub3QgYmFja3dhcmQgY29tcGF0aWJsZSBjaGFuZ2UuIEFuZCB3b3VsZAo+ ID4gPiBub3Qgd29yayBwZXIgZXhpc3RpbmcgRFQgYmluZGluZ3MgZGVmaW5pdGlvbnMsIHdoaWNo IGRlZmluZXMgaG93Cj4gPiA+IGJvb3Rsb2FkZXIgc2hvdWxkIHNldCBjb25maWd1cmVkIGNsb2Nr cy4KPiA+ID4gCj4gPiA+IEFzIEkgd3JvdGUgaW4gZW1haWxzIDMgbW9udGhzIGFnbywgdGhpcyBu ZXcgInByb3Bvc2VkIiBEVFMgZGVmaW5pdGlvbiBpcwo+ID4gPiBzb21ldGhpbmcgd2hpY2ggSSB3 b3VsZCBoYXZlIGNob3NlbiBpZiBJIGhhZCBkZXNpZ25lZCB0aGlzIGRyaXZlciBhbmQKPiA+ID4g YmluZGluZ3MgaW4gcGFzdC4gQnV0IHRoYXQgZGlkIG5vdCBoYXBwZW4gYW5kIGRpZmZlcmVudCBh cHByb2FjaCBpcwo+ID4gPiBhbHJlYWR5IHdpZGVseSBpbiB1c2VkLgo+ID4gPiAKPiA+ID4gVG8g c3VwcG9ydCBleGlzdGluZyBEVFMgZGVmaW5pdGlvbnMgYW5kIGJvb3Rsb2FkZXJzLCBpdCBpcyBy ZWFsbHkKPiA+ID4gcmVxdWlyZWQgdG8gaGF2ZSBjdXJyZW50IHN0cnVjdHVyZSBiYWNrd2FyZCBj b21wYXRpYmxlIGxpa2UgaXQgaXMKPiA+ID4gZGVmaW5lZCBpbiBjdXJyZW50IERUIGJpbmRpbmdz IGRvY3VtZW50LiBBbmQgbXkgY2hhbmdlcyBpbiB0aGlzIHBhdGNoCj4gPiA+IHNlcmllcyBhcmUg YmFja3dhcmQgY29tcGF0aWJsZS4KPiA+IAo+ID4gSSdtIGxvc3QuIElzIHRoZSBib290bG9hZGVy IHRoZSBvbmUgdGhhdCdzIGV4cGVjdGluZyBzb21lIHBhcnRpY3VsYXIKPiA+IHNlcmlhbCBub2Rl IGZvcm1hdCBhbmQgdXBkYXRpbmcgc29tZXRoaW5nPyBXaGF0IGlzIHRoZSBib290bG9hZGVyIGRv aW5nPwo+IAo+IElmIGJvb3Rsb2FkZXIgdXNlcyBvciBjb25maWd1cmVzIFVBUlQgdG8gZGlmZmVy ZW50IGNsb2NrIGl0IG5lZWRzIHRvCj4gdXBkYXRlICJjbG9ja3MiIHByb3BlcnR5IGluIERULiBP dGhlcndpc2UgVUFSVCB3b3VsZCBiZSB1bnVzYWJsZSBhbmQKPiB0aGVyZSB3b3VsZCBiZSBubyBk bWVzZyBvdXRwdXQuCgpHb3QgaXQhIEkgZGlkbid0IHNlZSB0aGF0IHBhcnQgbWVudGlvbmVkIGFu eXdoZXJlIGluIHRoZSBjb21taXQgdGV4dAp0aG91Z2guIFRvIHRoZSB1bmluZm9ybWVkIHJldmll d2VyIGxpa2UgbWUgaXQgaXMgaGFyZCB0byBrbm93IGFib3V0IHRoaXMKYm9vdGxvYWRlciBkZXNp Z24gdW5sZXNzIHRoZSBjb21taXQgdGV4dCBleHBsYWlucyB0aGF0IHRoZXJlJ3Mgbm8gb3RoZXIK d2F5IHRvIGRvIHRoaXMuCgo+IAo+IEEzNzIwIGhlYXZpbHkgZGVwZW5kcyB0aGF0IGJvb3Rsb2Fk ZXIgcGF0Y2hlcyBhdCBib290IHRpbWUgRFRCIGZpbGUgdG8KPiB0aGUgbGF5b3V0IG9mIHRoZSBj dXJyZW50IGhhcmR3YXJlLgo+IAo+ID4gPiAKPiA+ID4gVG8gY2hhbmdlIERUUyBzdHJ1Y3R1cmUs IGl0IHdvdWxkIGJlIG5lZWRlZCB0byBwcm92aWRlIHVhcnQgbm9kZXMgaW4gRFRTCj4gPiA+IGZp bGVzIHR3byB0aW1lczogb25jZSBpbiBvbGQgc3R5bGUgKHRoZSBjdXJyZW50IG9uZSkgYW5kIHNl Y29uZCB0aW1lIGluCj4gPiA+IHRoaXMgbmV3IHN0eWxlLgo+ID4gCj4gPiBUaGF0J3Mgbm90IGEg Z29vZCBpZGVhLiBXaHkgZG8gd2UgbmVlZCB0byBzdXBwb3J0IGJvdGggYXQgdGhlIHNhbWUgdGlt ZT8KPiAKPiBCZWNhdXNlIG9sZCBib290bG9hZGVycyBkbyBub3QgYW5kIHdpbGwgbmV2ZXIgc3Vw cG9ydCB0aGlzIG5ldyBzdHlsZS4gSXQKPiBpcyBub3Qgb25seSBsaW51eCBrZXJuZWwgcHJvamVj dCB3aG8gcHJvdmlkZXMgRFRCIGZpbGVzLiBBbHNvIGJvb3Rsb2FkZXIKPiBpdHNlbGYgaGFzIG93 biBEVEIgZmlsZXMgYW5kIHVzZSBpdCBmb3IgYm9vdGluZyAoZS5nIGtlcm5lbCkuIEZvciBzb21l Cj4gYm9hcmRzIGlzIGluLWtlcm5lbC10cmVlIERUUyBmaWxlIG9ubHkgYXMgYSByZWZlcmVuY2Uu IFNvIGl0IGlzCj4gaW1wb3J0YW50IHRoYXQga2VybmVsIGNhbiB1c2UgYW5kIHN1cHBvcnQgRFRT IGZpbGVzIGZyb20gb2xkIHZlcnNpb24gYW5kCj4gYWxzbyBmcm9tIHRoZSBuZXcgcGF0Y2hlZCB2 ZXJzaW9uLiBHcmVnb3J5IChBMzcyMCBEVFMgZmlsZXMgbWFpbnRhaW5lcikKPiBhbHdheXMgYXNr IG1lIHdoYXQgaGFwcGVucyBpZiBJIHRyeSB0byBib290IG5ldyBwYXRjaGVkIGtlcm5lbCBkcml2 ZXJzCj4gd2l0aCBvbGQgdW5tb2RpZmllZCBEVFMgZmlsZXMgYW5kIHdhbnRzIHRvIGtub3cgaWYg bm90aGluZyBpcyBicm9rZW4gYnkKPiBpbnRyb2R1Y2VkIGNoYW5nZWQuCj4gCj4gPiA+IAo+ID4g PiBCdXQgc3VjaCB0aGluZyB3b3VsZCBldmVuIG1vcmUgY29tcGxpY2F0ZSB1cGRhdGluZyBkcml2 ZXIgYW5kIGl0IG5lZWRzCj4gPiA+IHRvIGJlIGltcGxlbWVudGVkLgo+ID4gPiAKPiA+ID4gUGx1 cyB0aGlzIHdvdWxkIG9wZW4gYSBxdWVzdGlvbiBob3cgdG8gZGVmaW5lIGRlZmF1bHQgc3Rkb3V0 LXBhdGggaWYKPiA+ID4gdGhlcmUgd291bGQgYmUgNCBzZXJpYWwgbm9kZXMsIHdoZXJlIG9uZSBw YWlyIHdvdWxkIGRlc2NyaWJlIG9sZCBzdHlsZQo+ID4gPiBhbmQgc2Vjb25kIHBhaXIgbmV3IHN0 eWxlOyBtZWFuaW5nIHRoYXQgMiBjcm9zcyBub2RlcyB3b3VsZCBkZXNjcmliZQo+ID4gPiBzYW1l IGRlZmluZS4KPiA+IAo+ID4gSHVoPyBXZSBzaG91bGRuJ3QgaGF2ZSBib3RoIGJpbmRpbmdzIHBy ZXNlbnQgaW4gdGhlIERUQi4KPiAKPiBJZGVhbGx5IHllcywgSSB3b3VsZCBsaWtlIHRvIHNlZSB0 byBwcmV2ZW50IGl0LiBCdXQgZm9yIGJhY2t3YXJkCj4gY29tcGF0aWJpbGl0eSB3ZSByZWFsbHkg bmVlZCBvbGQgYmluZGluZ3Mgc3RpbGwgcHJlc2VudCAoYXMgZXhwbGFpbmVkCj4gYWJvdmUpLgo+ IAo+IFNvIHJlYWxseSBJIHNlZSB0d28gb3B0aW9ucyBoZXJlOiBNYWtlIGNoYW5nZXMgaW4gcGF0 Y2hlcyBiYWNrd2FyZAo+IGNvbXBhdGlibGUgKG9sZCBub2RlcyBzdGF5IGluIERUIGFuZCBhbHNv IGtlcm5lbCB3b3VsZCBiZSBhYmxlIHRvIHVzZQo+IG9sZCBEVCkuIE9yIGxldCBvbGQgYmluZGlu Z3MgdW50b3VjaGVkIGluIERUIGFuZCBuZXcgYmFja3dhcmQKPiBpbmNvbXBhdGlibGUgZGVmaW5p dGlvbnMgd291bGQgaGF2ZSB0byBiZSBpbiBzZXBhcmF0ZSBub2Rlcy4KCk9rIEkgdW5kZXJzdGFu ZCBub3cuIFdlIGhhdmUgdG8ga2VlcCBib3RoIHRoZSBzZXJpYWwgbm9kZXMgYmVjYXVzZSB0aGUK Ym9vdGxvYWRlciBpcyBwYXRjaGluZyB0aGVtLiBUbyBtYWtlIG1hdHRlcnMgd29yc2UsIG9uZSBv ciB0aGUgb3RoZXIKbm9kZSBtYXkgYmUgZGlzYWJsZWQgc28gd2UgY2FuJ3QgZXZlbiBhZGQgdGhl IG5ldyBiaXRzIHRvIHRoZSB1YXJ0MQpub2RlLiBDYW4geW91IHVwZGF0ZSB0aGUgY29tbWl0IHRl eHQgdG8gcmVjb3JkIHRoaXMgc2FkIHN0YXRlIG9mIGFmZmFpcnMKYW5kIGluZGljYXRlIHRoYXQg dGhlIG9ubHkgd2F5IHRvIHN1cHBvcnQgdGhpcyBpcyB0byBtYWtlIGEgbmV3IG5vZGUgaW4KRFQg dGhhdCB0aGUgYm9vdGxvYWRlciBkb2Vzbid0IGtub3cgYWJvdXQ/CgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcg bGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmlu ZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==