From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1ADA41E480; Tue, 2 Apr 2024 15:58:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712073531; cv=none; b=HAVaW9WkdeMwNrvYLH19BPUkxIEuO4L/LxTjx91eu4aUgu/6VNbJmeXx7v9R8ZehfMZS752wMg3FxTRJNaf4hRS/Lre2Z6B5zxPdMdxVVdVmXmjgO3/qBc8s1SEE8TnYHxv9W2/03VzlR+pggTZPSJPBtGxzN/OIzMBAiq3Cur8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712073531; c=relaxed/simple; bh=Gidpon3Z5DPHUkBqcS5U3KP9v3VSp4F1/+bnIqyCBYY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pMyepY4zZ0x5zbMuBk+4Q5/VClr35VOgtPtxSxpBhXUvdyN2CCduI+9G0uCLLvEaAkBPFD0RSgsAPCgfi9S4262F7jMt01T4CrQ0U1UcA6M3me0cwcjVtvDKWzrNKhzWKeE3nMDYSuCKRRlFW6JKY8FADZR5rcEsSNbWJS9snb8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 654971007; Tue, 2 Apr 2024 08:59:19 -0700 (PDT) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CA8863F7F5; Tue, 2 Apr 2024 08:58:44 -0700 (PDT) Date: Tue, 2 Apr 2024 16:58:34 +0100 From: Cristian Marussi To: Andy Shevchenko Cc: Peng Fan , "Peng Fan (OSS)" , Sudeep Holla , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Linus Walleij , Dan Carpenter , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Oleksii Moisieiev Subject: Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Message-ID: References: <20240323-pinctrl-scmi-v6-0-a895243257c0@nxp.com> <20240323-pinctrl-scmi-v6-3-a895243257c0@nxp.com> Precedence: bulk X-Mailing-List: linux-gpio@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Apr 02, 2024 at 04:06:06PM +0300, Andy Shevchenko wrote: > On Tue, Apr 2, 2024 at 10:48 AM Cristian Marussi > wrote: > > On Sun, Mar 31, 2024 at 01:44:28PM +0000, Peng Fan wrote: > > > > Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) kirjoitti: > > ... > > > > > > +#include > > > > > +#include > > > > > +#include > > > > > > > > This is semi-random list of headers. Please, follow IWYU principle (include > > > > what you use). There are a lot of inclusions I see missing (just in the context of > > > > this page I see bits.h, types.h, and asm/byteorder.h). > > > > > > Is there any documentation about this requirement? > > > Some headers are already included by others. > > The documentation here is called "a common sense". > The C language is built like this and we expect that nobody will > invest into the dependency hell that we have already, that's why IWYU > principle, please follow it. > Yes, but given that we have a growing number of SCMI protocols there is a common local protocols.h header to group all includes needed by any protocols: the idea behind this (and the devm_ saga down below) was to ease development of protocols, since there are lots of them and growing, given the SCMI spec is extensible. > > Andy made (mostly) the same remarks on this same patch ~1-year ago on > > this same patch while it was posted by Oleksii. > > > > And I told that time that most of the remarks around devm_ usage were > > wrong due to how the SCMI core handles protocol initialization (using a > > devres group transparently). > > > > This is what I answered that time. > > > > https://lore.kernel.org/linux-arm-kernel/ZJ78hBcjAhiU+ZBO@e120937-lin/#t > > > > I wont repeat myself, but, in a nutshell the memory allocation like it > > is now is fine: a bit happens via devm_ at protocol initialization, the > > other is doe via explicit kmalloc at runtime and freed via kfree at > > remove time (if needed...i.e. checking the present flag of some structs) > > This sounds like a mess. devm_ is expected to be used only for the > ->probe() stage, otherwise you may consider cleanup.h (__free() macro) > to have automatic free at the paths where memory is not needed. > Indeed, this protocol_init code is called by the SCMI core once for all when an SCMI driver tries at first to use this specific protocol by 'getting' its protocol_ops, so it is indeed called inside the probe chain of the driver: at this point you *can* decide to use devres to allocate memory and be assured that if the init fails, or when the driver cease to use this protocol (calling its remove()) and no other driver is using it, all the stuff that have been allocated related to this protocol will be released by the core for you. (using an internal devres group) Without this you should handle manually all the deallocation manually on the init error-paths AND also provide all the cleanup explicitly when the protocol is no more used by any driver (multiple users of the same protocol instance are possible)...for all protocols. This is/was handy since, till now, all the SCMI querying and resources allocation happened anyway all at once at init time... ...the mess, as you kindly called it, derives from the fact that this specific protocol is the first and only one that does NOT allocate all that it needs during the initialization (to minimize needless allocs for a lot of possibly unused resources) and this lazy-initialization phase, done after init at runtime, must be handled manually since it cannot be managed by the devres group that is open/clsoed around init by the SCMI core. I dont like particularly this split allocation but it has a reason and any other solution seems more messy to me at the moment. And I dont feel like changing all the SCMI protocol initialziation core code (that address a lot more under the hood) is a desirable solution to address a non-existent problem really. > And the function naming doesn't suggest that you have a probe-remove > pair. Moreover, if the init-deinit part is called in the probe-remove, > the devm_ must not be mixed with non-devm ones, as it breaks the order > and leads to subtle mistakes. > Initialization order is enforced by SCMI core like this: @driver_probe->get_protocol_ops() @core/get_protocol_ops -> devres_group_open() -> protocol_init->devm_*() -> devres_group_close() -> driver_probing @runtime optional explicit_lazy_kmallocs inside the protocol @driver_remove->put_protocol_ops() @core/put_protocol_ops() -> protocol_denit->optional_explicit_kfree_of_the_above -> devres_group_release() -> driver_removing ... dont think there's an ordering problem. ...note that the ph->dev provided in the protocol_init and used by devm_ is NOT the dev of the SCMI driver probe/remove that uses the get_protocol_ops, it is an internal SCMI device associated with the core SCMI stack probing and allocations, within which a devres group for the specific protocol is created when that specific protocol is initialized...protocols are not fully fledged drivers are just bits of the SCMI stack that are initialized when needed (and possibly also loaded when needed for vendor protocols) and de-initialzed when no more SCMI driver users exist for that protocol. Thanks, Cristian 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 E6EFEC6FD1F for ; Tue, 2 Apr 2024 15:59:08 +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=RqHOyNJVzGw7FtGJwXvbSG3iSkCCHza6TOfZmdroaos=; b=xpVeoHElQsiEML EpMMUvNXKZ9pu98tSM5iBp1b7s9zJ8OEBdG9Hkwgkd/QLkPkczJGcujyltAQAPn83MMSglhSb8YKg HHmgy45OsPZALbGJXDbodrvgGtZLgohFh1Oz4jEhHBcK21jNNuX6e9qiMSIYzlEYG+yb9xhndbW9E dzHbcyf/AbAvBrLBmo53ablEbRNkNh+ohbYM17K2PDfgo4eGFfO1Zq0vt58SEpdb3usU4g4k6jTGv xH3Gc1prMmuLoqx5VzoGeVy7A+I1p/aeEBtRVE4s3WZRndqlD+o+0W9GSDxFgQB5iduzmGATQvEMm r/04MpKpt6F7khhjoDBA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrgXK-0000000BvE0-0ol4; Tue, 02 Apr 2024 15:58:58 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrgXG-0000000BvD1-3F5C for linux-arm-kernel@lists.infradead.org; Tue, 02 Apr 2024 15:58:56 +0000 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 654971007; Tue, 2 Apr 2024 08:59:19 -0700 (PDT) Received: from pluto (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CA8863F7F5; Tue, 2 Apr 2024 08:58:44 -0700 (PDT) Date: Tue, 2 Apr 2024 16:58:34 +0100 From: Cristian Marussi To: Andy Shevchenko Cc: Peng Fan , "Peng Fan (OSS)" , Sudeep Holla , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Linus Walleij , Dan Carpenter , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Oleksii Moisieiev Subject: Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Message-ID: References: <20240323-pinctrl-scmi-v6-0-a895243257c0@nxp.com> <20240323-pinctrl-scmi-v6-3-a895243257c0@nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240402_085854_984519_182F20DD X-CRM114-Status: GOOD ( 40.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 T24gVHVlLCBBcHIgMDIsIDIwMjQgYXQgMDQ6MDY6MDZQTSArMDMwMCwgQW5keSBTaGV2Y2hlbmtv IHdyb3RlOgo+IE9uIFR1ZSwgQXByIDIsIDIwMjQgYXQgMTA6NDjigK9BTSBDcmlzdGlhbiBNYXJ1 c3NpCj4gPGNyaXN0aWFuLm1hcnVzc2lAYXJtLmNvbT4gd3JvdGU6Cj4gPiBPbiBTdW4sIE1hciAz MSwgMjAyNCBhdCAwMTo0NDoyOFBNICswMDAwLCBQZW5nIEZhbiB3cm90ZToKPiA+ID4gPiBTYXQs IE1hciAyMywgMjAyNCBhdCAwODoxNToxNlBNICswODAwLCBQZW5nIEZhbiAoT1NTKSBraXJqb2l0 dGk6Cj4gCj4gLi4uCj4gCj4gPiA+ID4gPiArI2luY2x1ZGUgPGxpbnV4L21vZHVsZS5oPgo+ID4g PiA+ID4gKyNpbmNsdWRlIDxsaW51eC9zY21pX3Byb3RvY29sLmg+Cj4gPiA+ID4gPiArI2luY2x1 ZGUgPGxpbnV4L3NsYWIuaD4KPiA+ID4gPgo+ID4gPiA+IFRoaXMgaXMgc2VtaS1yYW5kb20gbGlz dCBvZiBoZWFkZXJzLiBQbGVhc2UsIGZvbGxvdyBJV1lVIHByaW5jaXBsZSAoaW5jbHVkZQo+ID4g PiA+IHdoYXQgeW91IHVzZSkuIFRoZXJlIGFyZSBhIGxvdCBvZiBpbmNsdXNpb25zIEkgc2VlIG1p c3NpbmcgKGp1c3QgaW4gdGhlIGNvbnRleHQgb2YKPiA+ID4gPiB0aGlzIHBhZ2UgSSBzZWUgYml0 cy5oLCB0eXBlcy5oLCBhbmQgIGFzbS9ieXRlb3JkZXIuaCkuCj4gPiA+Cj4gPiA+IElzIHRoZXJl IGFueSBkb2N1bWVudGF0aW9uIGFib3V0IHRoaXMgcmVxdWlyZW1lbnQ/Cj4gPiA+IFNvbWUgaGVh ZGVycyBhcmUgYWxyZWFkeSBpbmNsdWRlZCBieSBvdGhlcnMuCj4gCj4gVGhlIGRvY3VtZW50YXRp b24gaGVyZSBpcyBjYWxsZWQgImEgY29tbW9uIHNlbnNlIi4KPiBUaGUgQyBsYW5ndWFnZSBpcyBi dWlsdCBsaWtlIHRoaXMgYW5kIHdlIGV4cGVjdCB0aGF0IG5vYm9keSB3aWxsCj4gaW52ZXN0IGlu dG8gdGhlIGRlcGVuZGVuY3kgaGVsbCB0aGF0IHdlIGhhdmUgYWxyZWFkeSwgdGhhdCdzIHdoeSBJ V1lVCj4gcHJpbmNpcGxlLCBwbGVhc2UgZm9sbG93IGl0Lgo+IAoKWWVzLCBidXQgZ2l2ZW4gdGhh dCB3ZSBoYXZlIGEgZ3Jvd2luZyBudW1iZXIgb2YgU0NNSSBwcm90b2NvbHMgdGhlcmUgaXMgYQpj b21tb24gbG9jYWwgcHJvdG9jb2xzLmggaGVhZGVyIHRvIGdyb3VwIGFsbCBpbmNsdWRlcyBuZWVk ZWQgYnkgYW55CnByb3RvY29sczogdGhlIGlkZWEgYmVoaW5kIHRoaXMgKGFuZCB0aGUgZGV2bV8g c2FnYSBkb3duIGJlbG93KSB3YXMgdG8gZWFzZQpkZXZlbG9wbWVudCBvZiBwcm90b2NvbHMsIHNp bmNlIHRoZXJlIGFyZSBsb3RzIG9mIHRoZW0gYW5kIGdyb3dpbmcsIGdpdmVuCnRoZSBTQ01JIHNw ZWMgaXMgZXh0ZW5zaWJsZS4KCj4gPiBBbmR5IG1hZGUgKG1vc3RseSkgdGhlIHNhbWUgcmVtYXJr cyBvbiB0aGlzIHNhbWUgcGF0Y2ggfjEteWVhciBhZ28gb24KPiA+IHRoaXMgc2FtZSBwYXRjaCB3 aGlsZSBpdCB3YXMgcG9zdGVkIGJ5IE9sZWtzaWkuCj4gPgo+ID4gQW5kIEkgdG9sZCB0aGF0IHRp bWUgdGhhdCBtb3N0IG9mIHRoZSByZW1hcmtzIGFyb3VuZCBkZXZtXyB1c2FnZSB3ZXJlCj4gPiB3 cm9uZyBkdWUgdG8gaG93IHRoZSBTQ01JIGNvcmUgaGFuZGxlcyBwcm90b2NvbCBpbml0aWFsaXph dGlvbiAodXNpbmcgYQo+ID4gZGV2cmVzIGdyb3VwIHRyYW5zcGFyZW50bHkpLgo+ID4KPiA+IFRo aXMgaXMgd2hhdCBJIGFuc3dlcmVkIHRoYXQgdGltZS4KPiA+Cj4gPiBodHRwczovL2xvcmUua2Vy bmVsLm9yZy9saW51eC1hcm0ta2VybmVsL1pKNzhoQmNqQWhpVStaQk9AZTEyMDkzNy1saW4vI3QK PiA+Cj4gPiBJIHdvbnQgcmVwZWF0IG15c2VsZiwgYnV0LCBpbiBhIG51dHNoZWxsIHRoZSBtZW1v cnkgYWxsb2NhdGlvbiBsaWtlIGl0Cj4gPiBpcyBub3cgaXMgZmluZTogYSBiaXQgaGFwcGVucyB2 aWEgZGV2bV8gYXQgcHJvdG9jb2wgaW5pdGlhbGl6YXRpb24sIHRoZQo+ID4gb3RoZXIgaXMgZG9l IHZpYSBleHBsaWNpdCBrbWFsbG9jIGF0IHJ1bnRpbWUgYW5kIGZyZWVkIHZpYSBrZnJlZSBhdAo+ ID4gcmVtb3ZlIHRpbWUgKGlmIG5lZWRlZC4uLmkuZS4gY2hlY2tpbmcgdGhlIHByZXNlbnQgZmxh ZyBvZiBzb21lIHN0cnVjdHMpCj4gCj4gVGhpcyBzb3VuZHMgbGlrZSBhIG1lc3MuIGRldm1fIGlz IGV4cGVjdGVkIHRvIGJlIHVzZWQgb25seSBmb3IgdGhlCj4gLT5wcm9iZSgpIHN0YWdlLCBvdGhl cndpc2UgeW91IG1heSBjb25zaWRlciBjbGVhbnVwLmggKF9fZnJlZSgpIG1hY3JvKQo+IHRvIGhh dmUgYXV0b21hdGljIGZyZWUgYXQgdGhlIHBhdGhzIHdoZXJlIG1lbW9yeSBpcyBub3QgbmVlZGVk Lgo+IAoKSW5kZWVkLCB0aGlzIHByb3RvY29sX2luaXQgY29kZSBpcyBjYWxsZWQgYnkgdGhlIFND TUkgY29yZSBvbmNlIGZvciBhbGwgd2hlbgphbiBTQ01JIGRyaXZlciB0cmllcyBhdCBmaXJzdCB0 byB1c2UgdGhpcyBzcGVjaWZpYyBwcm90b2NvbCBieSAnZ2V0dGluZycgaXRzCnByb3RvY29sX29w cywgc28gaXQgaXMgaW5kZWVkIGNhbGxlZCBpbnNpZGUgdGhlIHByb2JlIGNoYWluIG9mIHRoZSBk cml2ZXI6CmF0IHRoaXMgcG9pbnQgeW91ICpjYW4qIGRlY2lkZSB0byB1c2UgZGV2cmVzIHRvIGFs bG9jYXRlIG1lbW9yeSBhbmQgYmUgYXNzdXJlZAp0aGF0IGlmIHRoZSBpbml0IGZhaWxzLCBvciB3 aGVuIHRoZSBkcml2ZXIgY2Vhc2UgdG8gdXNlIHRoaXMgcHJvdG9jb2wgKGNhbGxpbmcKaXRzIHJl bW92ZSgpKSBhbmQgbm8gb3RoZXIgZHJpdmVyIGlzIHVzaW5nIGl0LCBhbGwgdGhlIHN0dWZmIHRo YXQgaGF2ZSBiZWVuCmFsbG9jYXRlZCByZWxhdGVkIHRvIHRoaXMgcHJvdG9jb2wgd2lsbCBiZSBy ZWxlYXNlZCBieSB0aGUgY29yZSBmb3IgeW91LgoodXNpbmcgYW4gaW50ZXJuYWwgZGV2cmVzIGdy b3VwKQoKV2l0aG91dCB0aGlzIHlvdSBzaG91bGQgaGFuZGxlIG1hbnVhbGx5IGFsbCB0aGUgZGVh bGxvY2F0aW9uIG1hbnVhbGx5IG9uCnRoZSBpbml0IGVycm9yLXBhdGhzIEFORCBhbHNvIHByb3Zp ZGUgYWxsIHRoZSBjbGVhbnVwIGV4cGxpY2l0bHkgd2hlbgp0aGUgcHJvdG9jb2wgaXMgbm8gbW9y ZSB1c2VkIGJ5IGFueSBkcml2ZXIgKG11bHRpcGxlIHVzZXJzIG9mIHRoZSBzYW1lCnByb3RvY29s IGluc3RhbmNlIGFyZSBwb3NzaWJsZSkuLi5mb3IgYWxsIHByb3RvY29scy4KClRoaXMgaXMvd2Fz IGhhbmR5IHNpbmNlLCB0aWxsIG5vdywgYWxsIHRoZSBTQ01JIHF1ZXJ5aW5nIGFuZCByZXNvdXJj ZXMKYWxsb2NhdGlvbiBoYXBwZW5lZCBhbnl3YXkgYWxsIGF0IG9uY2UgYXQgaW5pdCB0aW1lLi4u CgouLi50aGUgbWVzcywgYXMgeW91IGtpbmRseSBjYWxsZWQgaXQsIGRlcml2ZXMgZnJvbSB0aGUg ZmFjdCB0aGF0IHRoaXMgc3BlY2lmaWMKcHJvdG9jb2wgaXMgdGhlIGZpcnN0IGFuZCBvbmx5IG9u ZSB0aGF0IGRvZXMgTk9UIGFsbG9jYXRlIGFsbCB0aGF0IGl0IG5lZWRzCmR1cmluZyB0aGUgaW5p dGlhbGl6YXRpb24gKHRvIG1pbmltaXplIG5lZWRsZXNzIGFsbG9jcyBmb3IgYSBsb3Qgb2YgcG9z c2libHkKdW51c2VkIHJlc291cmNlcykgYW5kIHRoaXMgbGF6eS1pbml0aWFsaXphdGlvbiBwaGFz ZSwgZG9uZSBhZnRlciBpbml0IGF0IHJ1bnRpbWUsCm11c3QgYmUgaGFuZGxlZCBtYW51YWxseSBz aW5jZSBpdCBjYW5ub3QgYmUgbWFuYWdlZCBieSB0aGUgZGV2cmVzIGdyb3VwIHRoYXQgaXMKb3Bl bi9jbHNvZWQgYXJvdW5kIGluaXQgYnkgdGhlIFNDTUkgY29yZS4KCkkgZG9udCBsaWtlIHBhcnRp Y3VsYXJseSB0aGlzIHNwbGl0IGFsbG9jYXRpb24gYnV0IGl0IGhhcyBhIHJlYXNvbiBhbmQgYW55 Cm90aGVyIHNvbHV0aW9uIHNlZW1zIG1vcmUgbWVzc3kgdG8gbWUgYXQgdGhlIG1vbWVudC4KCkFu ZCBJIGRvbnQgZmVlbCBsaWtlIGNoYW5naW5nIGFsbCB0aGUgU0NNSSBwcm90b2NvbCBpbml0aWFs emlhdGlvbiBjb3JlIGNvZGUKKHRoYXQgYWRkcmVzcyBhIGxvdCBtb3JlIHVuZGVyIHRoZSBob29k KSBpcyBhIGRlc2lyYWJsZSBzb2x1dGlvbiB0byBhZGRyZXNzIGEKbm9uLWV4aXN0ZW50IHByb2Js ZW0gcmVhbGx5LgoKPiBBbmQgdGhlIGZ1bmN0aW9uIG5hbWluZyBkb2Vzbid0IHN1Z2dlc3QgdGhh dCB5b3UgaGF2ZSBhIHByb2JlLXJlbW92ZQo+IHBhaXIuIE1vcmVvdmVyLCBpZiB0aGUgaW5pdC1k ZWluaXQgcGFydCBpcyBjYWxsZWQgaW4gdGhlIHByb2JlLXJlbW92ZSwKPiB0aGUgZGV2bV8gbXVz dCBub3QgYmUgbWl4ZWQgd2l0aCBub24tZGV2bSBvbmVzLCBhcyBpdCBicmVha3MgdGhlIG9yZGVy Cj4gYW5kIGxlYWRzIHRvIHN1YnRsZSBtaXN0YWtlcy4KPiAKCkluaXRpYWxpemF0aW9uIG9yZGVy IGlzIGVuZm9yY2VkIGJ5IFNDTUkgY29yZSBsaWtlIHRoaXM6CgogQGRyaXZlcl9wcm9iZS0+Z2V0 X3Byb3RvY29sX29wcygpCiAgQGNvcmUvZ2V0X3Byb3RvY29sX29wcwogICAgIC0+IGRldnJlc19n cm91cF9vcGVuKCkKICAgICAtPiBwcm90b2NvbF9pbml0LT5kZXZtXyooKQogICAgIC0+IGRldnJl c19ncm91cF9jbG9zZSgpCiAgICAgLT4gZHJpdmVyX3Byb2JpbmcKCiAgIEBydW50aW1lIG9wdGlv bmFsIGV4cGxpY2l0X2xhenlfa21hbGxvY3MgaW5zaWRlIHRoZSBwcm90b2NvbAogCiBAZHJpdmVy X3JlbW92ZS0+cHV0X3Byb3RvY29sX29wcygpCiAgIEBjb3JlL3B1dF9wcm90b2NvbF9vcHMoKQog ICAgIC0+IHByb3RvY29sX2Rlbml0LT5vcHRpb25hbF9leHBsaWNpdF9rZnJlZV9vZl90aGVfYWJv dmUKICAgICAtPiBkZXZyZXNfZ3JvdXBfcmVsZWFzZSgpCiAgIC0+IGRyaXZlcl9yZW1vdmluZwoK Li4uIGRvbnQgdGhpbmsgdGhlcmUncyBhbiBvcmRlcmluZyBwcm9ibGVtLgoKLi4ubm90ZSB0aGF0 IHRoZSBwaC0+ZGV2IHByb3ZpZGVkIGluIHRoZSBwcm90b2NvbF9pbml0IGFuZCB1c2VkIGJ5IGRl dm1fCmlzIE5PVCB0aGUgZGV2IG9mIHRoZSBTQ01JIGRyaXZlciBwcm9iZS9yZW1vdmUgdGhhdCB1 c2VzIHRoZSBnZXRfcHJvdG9jb2xfb3BzLAppdCBpcyBhbiBpbnRlcm5hbCBTQ01JIGRldmljZSBh c3NvY2lhdGVkIHdpdGggdGhlIGNvcmUgU0NNSSBzdGFjayBwcm9iaW5nIGFuZAphbGxvY2F0aW9u cywgd2l0aGluIHdoaWNoIGEgZGV2cmVzIGdyb3VwIGZvciB0aGUgc3BlY2lmaWMgcHJvdG9jb2wg aXMgY3JlYXRlZAp3aGVuIHRoYXQgc3BlY2lmaWMgcHJvdG9jb2wgaXMgaW5pdGlhbGl6ZWQuLi5w cm90b2NvbHMgYXJlIG5vdCBmdWxseQpmbGVkZ2VkIGRyaXZlcnMgYXJlIGp1c3QgYml0cyBvZiB0 aGUgU0NNSSBzdGFjayB0aGF0IGFyZSBpbml0aWFsaXplZCB3aGVuIG5lZWRlZAooYW5kIHBvc3Np Ymx5IGFsc28gbG9hZGVkIHdoZW4gbmVlZGVkIGZvciB2ZW5kb3IgcHJvdG9jb2xzKSBhbmQKZGUt aW5pdGlhbHplZCB3aGVuIG5vIG1vcmUgU0NNSSBkcml2ZXIgdXNlcnMgZXhpc3QgZm9yIHRoYXQg cHJvdG9jb2wuCgpUaGFua3MsCkNyaXN0aWFuCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgt YXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3Jn L21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=