From mboxrd@z Thu Jan 1 00:00:00 1970 From: mturquette@linaro.org (Michael Turquette) Date: Thu, 30 Jul 2015 15:57:29 -0700 Subject: [PATCH v7 3/5] clk: Supply the critical clock {init, enable, disable} framework In-Reply-To: <20150730092139.GB14642@x1> References: <1437570255-21049-1-git-send-email-lee.jones@linaro.org> <1437570255-21049-4-git-send-email-lee.jones@linaro.org> <20150727072549.GP2564@lukather> <20150727085338.GW3436@x1> <20150730012132.642.59489@quantum> <20150730092139.GB14642@x1> Message-ID: <20150730225729.23791.68604@quantum> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Quoting Lee Jones (2015-07-30 02:21:39) > On Wed, 29 Jul 2015, Michael Turquette wrote: > > Quoting Lee Jones (2015-07-27 01:53:38) > > > On Mon, 27 Jul 2015, Maxime Ripard wrote: > > > > > > > On Wed, Jul 22, 2015 at 02:04:13PM +0100, Lee Jones wrote: > > > > > These new API calls will firstly provide a mechanisms to tag a clock as > > > > > critical and secondly allow any knowledgeable driver to (un)gate clocks, > > > > > even if they are marked as critical. > > > > > > > > > > Suggested-by: Maxime Ripard > > > > > Signed-off-by: Lee Jones > > > > > --- > > > > > drivers/clk/clk.c | 45 ++++++++++++++++++++++++++++++++++++++++++++ > > > > > include/linux/clk-provider.h | 2 ++ > > > > > include/linux/clk.h | 30 +++++++++++++++++++++++++++++ > > > > > 3 files changed, 77 insertions(+) > > > > > > > > > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c > > > > > index 61c3fc5..486b1da 100644 > > > > > --- a/drivers/clk/clk.c > > > > > +++ b/drivers/clk/clk.c > > > > > @@ -46,6 +46,21 @@ static struct clk_core *clk_core_lookup(const char *name); > > > > > > > > > > /*** private data structures ***/ > > > > > > > > > > +/** > > > > > + * struct critical - Provides 'play' over critical clocks. A clock can be > > > > > + * marked as critical, meaning that it should not be > > > > > + * disabled. However, if a driver which is aware of the > > > > > + * critical behaviour wants to control it, it can do so > > > > > + * using clk_enable_critical() and clk_disable_critical(). > > > > > + * > > > > > + * @enabled Is clock critical? Once set, doesn't change > > > > > + * @leave_on Self explanatory. Can be disabled by knowledgeable drivers > > > > > + */ > > > > > +struct critical { > > > > > + bool enabled; > > > > > + bool leave_on; > > > > > +}; > > > > > + > > > > > struct clk_core { > > > > > const char *name; > > > > > const struct clk_ops *ops; > > > > > @@ -75,6 +90,7 @@ struct clk_core { > > > > > struct dentry *dentry; > > > > > #endif > > > > > struct kref ref; > > > > > + struct critical critical; > > > > > }; > > > > > > > > > > struct clk { > > > > > @@ -995,6 +1011,10 @@ static void clk_core_disable(struct clk_core *clk) > > > > > if (WARN_ON(clk->enable_count == 0)) > > > > > return; > > > > > > > > > > + /* Refuse to turn off a critical clock */ > > > > > + if (clk->enable_count == 1 && clk->critical.leave_on) > > > > > + return; > > > > > + > > > > > > > > I think it should be handled by a separate counting. Otherwise, if you > > > > have two users that marked the clock as critical, and then one of them > > > > disable it... > > > > > > > > > if (--clk->enable_count > 0) > > > > > return; > > > > > > > > > > @@ -1037,6 +1057,13 @@ void clk_disable(struct clk *clk) > > > > > } > > > > > EXPORT_SYMBOL_GPL(clk_disable); > > > > > > > > > > +void clk_disable_critical(struct clk *clk) > > > > > +{ > > > > > + clk->core->critical.leave_on = false; > > > > > > > > .. you just lost the fact that it was critical in the first place. > > > > > > I thought about both of these points, which is why I came up with this > > > strategy. > > > > > > Any device which uses the *_critical() API should a) have knowledge of > > > what happens when a particular critical clock is gated and b) have > > > thought about the consequences. > > > > If this statement above is true then I fail to see the need for a new > > api. A driver which has a really great idea of when it is safe or unsafe > > to gate a clock should call clk_prepare_enable at probe and then only > > call clk_disable_unprepare once it is safe to do so. > > > > The existing bookkeeping in the clock framework will do the rest. > > I think you are viewing this particular API back-to-front. The idea > is to mark all of the critical clocks at start-up by taking a > reference. Then, if there are no knowledgable drivers who wish to > turn the clock off, the CCF will leave the clock ungated becuase the > reference count will always be >0. Right. So I'll ask the same question here that I asked in the other patch: is there ever a case where a clock consumer driver would want to call clk_enable_critical? It seems to me that in you usage of it, that call would only ever be made by the core framework code (e.g. clk-conf.c or perhaps somewhere in drivers/clk/clk.c). > > The clk_{disable,enable}_critical() calls are to be used by > knowledgable drivers to say "[disable] I know what I'm doing and it's > okay for this clock to be turned off" and "[enable] right I'm done > with this clock now, let's turn it back on and mark it back as > critical, so no one else can turn it off". OK, so this almost answers my question above. You have a driver that may finish using a clock for a while (ie, rmmod knowledgeable_driver), and you want it (critically) enabled again. Is this a real use case? Who would come along and disable this clock later on? If the driver is to be re-loaded then I would suggest never unloading it in the first place. (Oh and bear in mind when answering my question above that imbalanced clk_enable/clk_disable calls will not succeed thanks to the vaporware patch that I have in my local tree) If you have a second knowledgeable_driver_2 that shares that clock and can be trusted to manage it (critically) then I would need to see that example, as it doesn't feel like a real use to me. > > To put things simply, the knowledgable driver will _not_ be enabling > the clock in the first place. The first interaction it has with it is > to gate it. Then, once it's done, it will enable it again and mark it > back up as critical.a I like the first part. Makes sense and fills a real need. I am fully on-board with a provider-handoff-to-consumer solution. It is all the weird stuff that comes after it that I'm unsure of. Regards, Mike > > Still confused ... let's go on another Q in one of your other emails > for another way of putting it. > > > > I don't think we can use reference > > > counting, because we'd need as many critical clock owners as there are > > > critical clocks. Cast your mind back to the reasons for this critical > > > clock API. One of the most important intentions of this API is the > > > requirement mitigation for each of the critical clocks to have an owner > > > (driver). > > > > > > With regards to your second point, that's what 'critical.enabled' > > > is for. Take a look at clk_enable_critical(). > > > > > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead > Linaro.org ? Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Turquette Subject: Re: [PATCH v7 3/5] clk: Supply the critical clock {init, enable, disable} framework Date: Thu, 30 Jul 2015 15:57:29 -0700 Message-ID: <20150730225729.23791.68604@quantum> References: <1437570255-21049-1-git-send-email-lee.jones@linaro.org> <1437570255-21049-4-git-send-email-lee.jones@linaro.org> <20150727072549.GP2564@lukather> <20150727085338.GW3436@x1> <20150730012132.642.59489@quantum> <20150730092139.GB14642@x1> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20150730092139.GB14642@x1> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Lee Jones Cc: devicetree@vger.kernel.org, kernel@stlinux.com, s.hauer@pengutronix.de, sboyd@codeaurora.org, linux-kernel@vger.kernel.org, geert@linux-m68k.org, Maxime Ripard , linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org UXVvdGluZyBMZWUgSm9uZXMgKDIwMTUtMDctMzAgMDI6MjE6MzkpCj4gT24gV2VkLCAyOSBKdWwg MjAxNSwgTWljaGFlbCBUdXJxdWV0dGUgd3JvdGU6Cj4gPiBRdW90aW5nIExlZSBKb25lcyAoMjAx NS0wNy0yNyAwMTo1MzozOCkKPiA+ID4gT24gTW9uLCAyNyBKdWwgMjAxNSwgTWF4aW1lIFJpcGFy ZCB3cm90ZToKPiA+ID4gCj4gPiA+ID4gT24gV2VkLCBKdWwgMjIsIDIwMTUgYXQgMDI6MDQ6MTNQ TSArMDEwMCwgTGVlIEpvbmVzIHdyb3RlOgo+ID4gPiA+ID4gVGhlc2UgbmV3IEFQSSBjYWxscyB3 aWxsIGZpcnN0bHkgcHJvdmlkZSBhIG1lY2hhbmlzbXMgdG8gdGFnIGEgY2xvY2sgYXMKPiA+ID4g PiA+IGNyaXRpY2FsIGFuZCBzZWNvbmRseSBhbGxvdyBhbnkga25vd2xlZGdlYWJsZSBkcml2ZXIg dG8gKHVuKWdhdGUgY2xvY2tzLAo+ID4gPiA+ID4gZXZlbiBpZiB0aGV5IGFyZSBtYXJrZWQgYXMg Y3JpdGljYWwuCj4gPiA+ID4gPiAKPiA+ID4gPiA+IFN1Z2dlc3RlZC1ieTogTWF4aW1lIFJpcGFy ZCA8bWF4aW1lLnJpcGFyZEBmcmVlLWVsZWN0cm9ucy5jb20+Cj4gPiA+ID4gPiBTaWduZWQtb2Zm LWJ5OiBMZWUgSm9uZXMgPGxlZS5qb25lc0BsaW5hcm8ub3JnPgo+ID4gPiA+ID4gLS0tCj4gPiA+ ID4gPiAgZHJpdmVycy9jbGsvY2xrLmMgICAgICAgICAgICB8IDQ1ICsrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrCj4gPiA+ID4gPiAgaW5jbHVkZS9saW51eC9jbGst cHJvdmlkZXIuaCB8ICAyICsrCj4gPiA+ID4gPiAgaW5jbHVkZS9saW51eC9jbGsuaCAgICAgICAg ICB8IDMwICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrCj4gPiA+ID4gPiAgMyBmaWxlcyBj aGFuZ2VkLCA3NyBpbnNlcnRpb25zKCspCj4gPiA+ID4gPiAKPiA+ID4gPiA+IGRpZmYgLS1naXQg YS9kcml2ZXJzL2Nsay9jbGsuYyBiL2RyaXZlcnMvY2xrL2Nsay5jCj4gPiA+ID4gPiBpbmRleCA2 MWMzZmM1Li40ODZiMWRhIDEwMDY0NAo+ID4gPiA+ID4gLS0tIGEvZHJpdmVycy9jbGsvY2xrLmMK PiA+ID4gPiA+ICsrKyBiL2RyaXZlcnMvY2xrL2Nsay5jCj4gPiA+ID4gPiBAQCAtNDYsNiArNDYs MjEgQEAgc3RhdGljIHN0cnVjdCBjbGtfY29yZSAqY2xrX2NvcmVfbG9va3VwKGNvbnN0IGNoYXIg Km5hbWUpOwo+ID4gPiA+ID4gIAo+ID4gPiA+ID4gIC8qKiogICAgcHJpdmF0ZSBkYXRhIHN0cnVj dHVyZXMgICAgKioqLwo+ID4gPiA+ID4gIAo+ID4gPiA+ID4gKy8qKgo+ID4gPiA+ID4gKyAqIHN0 cnVjdCBjcml0aWNhbCAtICAgICAgIFByb3ZpZGVzICdwbGF5JyBvdmVyIGNyaXRpY2FsIGNsb2Nr cy4gIEEgY2xvY2sgY2FuIGJlCj4gPiA+ID4gPiArICogICAgICAgICAgICAgICAgIG1hcmtlZCBh cyBjcml0aWNhbCwgbWVhbmluZyB0aGF0IGl0IHNob3VsZCBub3QgYmUKPiA+ID4gPiA+ICsgKiAg ICAgICAgICAgICAgICAgZGlzYWJsZWQuICBIb3dldmVyLCBpZiBhIGRyaXZlciB3aGljaCBpcyBh d2FyZSBvZiB0aGUKPiA+ID4gPiA+ICsgKiAgICAgICAgICAgICAgICAgY3JpdGljYWwgYmVoYXZp b3VyIHdhbnRzIHRvIGNvbnRyb2wgaXQsIGl0IGNhbiBkbyBzbwo+ID4gPiA+ID4gKyAqICAgICAg ICAgICAgICAgICB1c2luZyBjbGtfZW5hYmxlX2NyaXRpY2FsKCkgYW5kIGNsa19kaXNhYmxlX2Ny aXRpY2FsKCkuCj4gPiA+ID4gPiArICoKPiA+ID4gPiA+ICsgKiBAZW5hYmxlZCAgICAgICAgSXMg Y2xvY2sgY3JpdGljYWw/ICBPbmNlIHNldCwgZG9lc24ndCBjaGFuZ2UKPiA+ID4gPiA+ICsgKiBA bGVhdmVfb24gICAgICAgU2VsZiBleHBsYW5hdG9yeS4gIENhbiBiZSBkaXNhYmxlZCBieSBrbm93 bGVkZ2VhYmxlIGRyaXZlcnMKPiA+ID4gPiA+ICsgKi8KPiA+ID4gPiA+ICtzdHJ1Y3QgY3JpdGlj YWwgewo+ID4gPiA+ID4gKyAgIGJvb2wgZW5hYmxlZDsKPiA+ID4gPiA+ICsgICBib29sIGxlYXZl X29uOwo+ID4gPiA+ID4gK307Cj4gPiA+ID4gPiArCj4gPiA+ID4gPiAgc3RydWN0IGNsa19jb3Jl IHsKPiA+ID4gPiA+ICAgICBjb25zdCBjaGFyICAgICAgICAgICAgICAqbmFtZTsKPiA+ID4gPiA+ ICAgICBjb25zdCBzdHJ1Y3QgY2xrX29wcyAgICAqb3BzOwo+ID4gPiA+ID4gQEAgLTc1LDYgKzkw LDcgQEAgc3RydWN0IGNsa19jb3JlIHsKPiA+ID4gPiA+ICAgICBzdHJ1Y3QgZGVudHJ5ICAgICAg ICAgICAqZGVudHJ5Owo+ID4gPiA+ID4gICNlbmRpZgo+ID4gPiA+ID4gICAgIHN0cnVjdCBrcmVm ICAgICAgICAgICAgIHJlZjsKPiA+ID4gPiA+ICsgICBzdHJ1Y3QgY3JpdGljYWwgICAgICAgICBj cml0aWNhbDsKPiA+ID4gPiA+ICB9Owo+ID4gPiA+ID4gIAo+ID4gPiA+ID4gIHN0cnVjdCBjbGsg ewo+ID4gPiA+ID4gQEAgLTk5NSw2ICsxMDExLDEwIEBAIHN0YXRpYyB2b2lkIGNsa19jb3JlX2Rp c2FibGUoc3RydWN0IGNsa19jb3JlICpjbGspCj4gPiA+ID4gPiAgICAgaWYgKFdBUk5fT04oY2xr LT5lbmFibGVfY291bnQgPT0gMCkpCj4gPiA+ID4gPiAgICAgICAgICAgICByZXR1cm47Cj4gPiA+ ID4gPiAgCj4gPiA+ID4gPiArICAgLyogUmVmdXNlIHRvIHR1cm4gb2ZmIGEgY3JpdGljYWwgY2xv Y2sgKi8KPiA+ID4gPiA+ICsgICBpZiAoY2xrLT5lbmFibGVfY291bnQgPT0gMSAmJiBjbGstPmNy aXRpY2FsLmxlYXZlX29uKQo+ID4gPiA+ID4gKyAgICAgICAgICAgcmV0dXJuOwo+ID4gPiA+ID4g Kwo+ID4gPiA+IAo+ID4gPiA+IEkgdGhpbmsgaXQgc2hvdWxkIGJlIGhhbmRsZWQgYnkgYSBzZXBh cmF0ZSBjb3VudGluZy4gT3RoZXJ3aXNlLCBpZiB5b3UKPiA+ID4gPiBoYXZlIHR3byB1c2VycyB0 aGF0IG1hcmtlZCB0aGUgY2xvY2sgYXMgY3JpdGljYWwsIGFuZCB0aGVuIG9uZSBvZiB0aGVtCj4g PiA+ID4gZGlzYWJsZSBpdC4uLgo+ID4gPiA+IAo+ID4gPiA+ID4gICAgIGlmICgtLWNsay0+ZW5h YmxlX2NvdW50ID4gMCkKPiA+ID4gPiA+ICAgICAgICAgICAgIHJldHVybjsKPiA+ID4gPiA+ICAK PiA+ID4gPiA+IEBAIC0xMDM3LDYgKzEwNTcsMTMgQEAgdm9pZCBjbGtfZGlzYWJsZShzdHJ1Y3Qg Y2xrICpjbGspCj4gPiA+ID4gPiAgfQo+ID4gPiA+ID4gIEVYUE9SVF9TWU1CT0xfR1BMKGNsa19k aXNhYmxlKTsKPiA+ID4gPiA+ICAKPiA+ID4gPiA+ICt2b2lkIGNsa19kaXNhYmxlX2NyaXRpY2Fs KHN0cnVjdCBjbGsgKmNsaykKPiA+ID4gPiA+ICt7Cj4gPiA+ID4gPiArICAgY2xrLT5jb3JlLT5j cml0aWNhbC5sZWF2ZV9vbiA9IGZhbHNlOwo+ID4gPiA+IAo+ID4gPiA+IC4uIHlvdSBqdXN0IGxv c3QgdGhlIGZhY3QgdGhhdCBpdCB3YXMgY3JpdGljYWwgaW4gdGhlIGZpcnN0IHBsYWNlLgo+ID4g PiAKPiA+ID4gSSB0aG91Z2h0IGFib3V0IGJvdGggb2YgdGhlc2UgcG9pbnRzLCB3aGljaCBpcyB3 aHkgSSBjYW1lIHVwIHdpdGggdGhpcwo+ID4gPiBzdHJhdGVneS4KPiA+ID4gCj4gPiA+IEFueSBk ZXZpY2Ugd2hpY2ggdXNlcyB0aGUgKl9jcml0aWNhbCgpIEFQSSBzaG91bGQgYSkgaGF2ZSBrbm93 bGVkZ2Ugb2YKPiA+ID4gd2hhdCBoYXBwZW5zIHdoZW4gYSBwYXJ0aWN1bGFyIGNyaXRpY2FsIGNs b2NrIGlzIGdhdGVkIGFuZCBiKSBoYXZlCj4gPiA+IHRob3VnaHQgYWJvdXQgdGhlIGNvbnNlcXVl bmNlcy4KPiA+IAo+ID4gSWYgdGhpcyBzdGF0ZW1lbnQgYWJvdmUgaXMgdHJ1ZSB0aGVuIEkgZmFp bCB0byBzZWUgdGhlIG5lZWQgZm9yIGEgbmV3Cj4gPiBhcGkuIEEgZHJpdmVyIHdoaWNoIGhhcyBh IHJlYWxseSBncmVhdCBpZGVhIG9mIHdoZW4gaXQgaXMgc2FmZSBvciB1bnNhZmUKPiA+IHRvIGdh dGUgYSBjbG9jayBzaG91bGQgY2FsbCBjbGtfcHJlcGFyZV9lbmFibGUgYXQgcHJvYmUgYW5kIHRo ZW4gb25seQo+ID4gY2FsbCBjbGtfZGlzYWJsZV91bnByZXBhcmUgb25jZSBpdCBpcyBzYWZlIHRv IGRvIHNvLgo+ID4gCj4gPiBUaGUgZXhpc3RpbmcgYm9va2tlZXBpbmcgaW4gdGhlIGNsb2NrIGZy YW1ld29yayB3aWxsIGRvIHRoZSByZXN0Lgo+IAo+IEkgdGhpbmsgeW91IGFyZSB2aWV3aW5nIHRo aXMgcGFydGljdWxhciBBUEkgYmFjay10by1mcm9udC4gIFRoZSBpZGVhCj4gaXMgdG8gbWFyayBh bGwgb2YgdGhlIGNyaXRpY2FsIGNsb2NrcyBhdCBzdGFydC11cCBieSB0YWtpbmcgYQo+IHJlZmVy ZW5jZS4gIFRoZW4sIGlmIHRoZXJlIGFyZSBubyBrbm93bGVkZ2FibGUgZHJpdmVycyB3aG8gd2lz aCB0bwo+IHR1cm4gdGhlIGNsb2NrIG9mZiwgdGhlIENDRiB3aWxsIGxlYXZlIHRoZSBjbG9jayB1 bmdhdGVkIGJlY3Vhc2UgdGhlCj4gcmVmZXJlbmNlIGNvdW50IHdpbGwgYWx3YXlzIGJlID4wLgoK UmlnaHQuIFNvIEknbGwgYXNrIHRoZSBzYW1lIHF1ZXN0aW9uIGhlcmUgdGhhdCBJIGFza2VkIGlu IHRoZSBvdGhlcgpwYXRjaDogaXMgdGhlcmUgZXZlciBhIGNhc2Ugd2hlcmUgYSBjbG9jayBjb25z dW1lciBkcml2ZXIgd291bGQgd2FudCB0bwpjYWxsIGNsa19lbmFibGVfY3JpdGljYWw/IEl0IHNl ZW1zIHRvIG1lIHRoYXQgaW4geW91IHVzYWdlIG9mIGl0LCB0aGF0CmNhbGwgd291bGQgb25seSBl dmVyIGJlIG1hZGUgYnkgdGhlIGNvcmUgZnJhbWV3b3JrIGNvZGUgKGUuZy4gY2xrLWNvbmYuYwpv ciBwZXJoYXBzIHNvbWV3aGVyZSBpbiBkcml2ZXJzL2Nsay9jbGsuYykuCgo+IAo+IFRoZSBjbGtf e2Rpc2FibGUsZW5hYmxlfV9jcml0aWNhbCgpIGNhbGxzIGFyZSB0byBiZSB1c2VkIGJ5Cj4ga25v d2xlZGdhYmxlIGRyaXZlcnMgdG8gc2F5ICJbZGlzYWJsZV0gSSBrbm93IHdoYXQgSSdtIGRvaW5n IGFuZCBpdCdzCj4gb2theSBmb3IgdGhpcyBjbG9jayB0byBiZSB0dXJuZWQgb2ZmIiBhbmQgIltl bmFibGVdIHJpZ2h0IEknbSBkb25lCj4gd2l0aCB0aGlzIGNsb2NrIG5vdywgbGV0J3MgdHVybiBp dCBiYWNrIG9uIGFuZCBtYXJrIGl0IGJhY2sgYXMKPiBjcml0aWNhbCwgc28gbm8gb25lIGVsc2Ug Y2FuIHR1cm4gaXQgb2ZmIi4KCk9LLCBzbyB0aGlzIGFsbW9zdCBhbnN3ZXJzIG15IHF1ZXN0aW9u IGFib3ZlLiBZb3UgaGF2ZSBhIGRyaXZlciB0aGF0IG1heQpmaW5pc2ggdXNpbmcgYSBjbG9jayBm b3IgYSB3aGlsZSAoaWUsIHJtbW9kIGtub3dsZWRnZWFibGVfZHJpdmVyKSwgYW5kCnlvdSB3YW50 IGl0IChjcml0aWNhbGx5KSBlbmFibGVkIGFnYWluLiBJcyB0aGlzIGEgcmVhbCB1c2UgY2FzZT8g V2hvCndvdWxkIGNvbWUgYWxvbmcgYW5kIGRpc2FibGUgdGhpcyBjbG9jayBsYXRlciBvbj8gSWYg dGhlIGRyaXZlciBpcyB0byBiZQpyZS1sb2FkZWQgdGhlbiBJIHdvdWxkIHN1Z2dlc3QgbmV2ZXIg dW5sb2FkaW5nIGl0IGluIHRoZSBmaXJzdCBwbGFjZS4KCihPaCBhbmQgYmVhciBpbiBtaW5kIHdo ZW4gYW5zd2VyaW5nIG15IHF1ZXN0aW9uIGFib3ZlIHRoYXQgaW1iYWxhbmNlZApjbGtfZW5hYmxl L2Nsa19kaXNhYmxlIGNhbGxzIHdpbGwgbm90IHN1Y2NlZWQgdGhhbmtzIHRvIHRoZSB2YXBvcndh cmUKcGF0Y2ggdGhhdCBJIGhhdmUgaW4gbXkgbG9jYWwgdHJlZSkKCklmIHlvdSBoYXZlIGEgc2Vj b25kIGtub3dsZWRnZWFibGVfZHJpdmVyXzIgdGhhdCBzaGFyZXMgdGhhdCBjbG9jayBhbmQKY2Fu IGJlIHRydXN0ZWQgdG8gbWFuYWdlIGl0IChjcml0aWNhbGx5KSB0aGVuIEkgd291bGQgbmVlZCB0 byBzZWUgdGhhdApleGFtcGxlLCBhcyBpdCBkb2Vzbid0IGZlZWwgbGlrZSBhIHJlYWwgdXNlIHRv IG1lLgoKPiAKPiBUbyBwdXQgdGhpbmdzIHNpbXBseSwgdGhlIGtub3dsZWRnYWJsZSBkcml2ZXIg d2lsbCBfbm90XyBiZSBlbmFibGluZwo+IHRoZSBjbG9jayBpbiB0aGUgZmlyc3QgcGxhY2UuICBU aGUgZmlyc3QgaW50ZXJhY3Rpb24gaXQgaGFzIHdpdGggaXQgaXMKPiB0byBnYXRlIGl0LiAgVGhl biwgb25jZSBpdCdzIGRvbmUsIGl0IHdpbGwgZW5hYmxlIGl0IGFnYWluIGFuZCBtYXJrIGl0Cj4g YmFjayB1cCBhcyBjcml0aWNhbC5hCgpJIGxpa2UgdGhlIGZpcnN0IHBhcnQuIE1ha2VzIHNlbnNl IGFuZCBmaWxscyBhIHJlYWwgbmVlZC4gSSBhbSBmdWxseQpvbi1ib2FyZCB3aXRoIGEgcHJvdmlk ZXItaGFuZG9mZi10by1jb25zdW1lciBzb2x1dGlvbi4gSXQgaXMgYWxsIHRoZQp3ZWlyZCBzdHVm ZiB0aGF0IGNvbWVzIGFmdGVyIGl0IHRoYXQgSSdtIHVuc3VyZSBvZi4KClJlZ2FyZHMsCk1pa2UK Cj4gCj4gU3RpbGwgY29uZnVzZWQgLi4uIGxldCdzIGdvIG9uIGFub3RoZXIgUSBpbiBvbmUgb2Yg eW91ciBvdGhlciBlbWFpbHMKPiBmb3IgYW5vdGhlciB3YXkgb2YgcHV0dGluZyBpdC4KPiAKPiA+ ID4gSSBkb24ndCB0aGluayB3ZSBjYW4gdXNlIHJlZmVyZW5jZQo+ID4gPiBjb3VudGluZywgYmVj YXVzZSB3ZSdkIG5lZWQgYXMgbWFueSBjcml0aWNhbCBjbG9jayBvd25lcnMgYXMgdGhlcmUgYXJl Cj4gPiA+IGNyaXRpY2FsIGNsb2Nrcy4gIENhc3QgeW91ciBtaW5kIGJhY2sgdG8gdGhlIHJlYXNv bnMgZm9yIHRoaXMgY3JpdGljYWwKPiA+ID4gY2xvY2sgQVBJLiAgT25lIG9mIHRoZSBtb3N0IGlt cG9ydGFudCBpbnRlbnRpb25zIG9mIHRoaXMgQVBJIGlzIHRoZQo+ID4gPiByZXF1aXJlbWVudCBt aXRpZ2F0aW9uIGZvciBlYWNoIG9mIHRoZSBjcml0aWNhbCBjbG9ja3MgdG8gaGF2ZSBhbiBvd25l cgo+ID4gPiAoZHJpdmVyKS4KPiA+ID4gCj4gPiA+IFdpdGggcmVnYXJkcyB0byB5b3VyIHNlY29u ZCBwb2ludCwgdGhhdCdzIHdoYXQgJ2NyaXRpY2FsLmVuYWJsZWQnCj4gPiA+IGlzIGZvci4gIFRh a2UgYSBsb29rIGF0IGNsa19lbmFibGVfY3JpdGljYWwoKS4KPiA+ID4gCj4gCj4gLS0gCj4gTGVl IEpvbmVzCj4gTGluYXJvIFNUTWljcm9lbGVjdHJvbmljcyBMYW5kaW5nIFRlYW0gTGVhZAo+IExp bmFyby5vcmcg4pSCIE9wZW4gc291cmNlIHNvZnR3YXJlIGZvciBBUk0gU29Dcwo+IEZvbGxvdyBM aW5hcm86IEZhY2Vib29rIHwgVHdpdHRlciB8IEJsb2cKCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0Cmxp bnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK