From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-id: <55782C3D.5000606@samsung.com> Date: Wed, 10 Jun 2015 14:23:25 +0200 From: Andrzej Hajda MIME-version: 1.0 To: Tomeu Vizoso , Linus Walleij Cc: Mark Rutland , "devicetree@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , linux-samsung-soc , dmaengine@vger.kernel.org, "linux-gpio@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pwm@vger.kernel.org" , linux-clk@vger.kernel.org, "linux-tegra@vger.kernel.org" , Rob Herring , "open list:DRM PANEL DRIVERS" , Grant Likely , Alexander Holler , Dan Williams , Dmitry Torokhov , linux-usb@vger.kernel.org Subject: Re: [PATCH 00/21] On-demand device registration References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> In-reply-to: Content-type: text/plain; charset=utf-8 Sender: linux-pm-owner@vger.kernel.org List-ID: On 06/10/2015 12:19 PM, Tomeu Vizoso wrote: > On 10 June 2015 at 09:30, Linus Walleij wrote: >> On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso >> wrote: >>> On 2 June 2015 at 10:48, Linus Walleij wrote: >> >>>> This is what systemd is doing in userspace for starting services: >>>> ask for your dependencies and wait for them if they are not >>>> there. So drivers ask for resources and wait for them. It also >>>> needs to be abstract, so for example we need to be able to >>>> hang on regulator_get() until the driver is up and providing that >>>> regulator, and as long as everything is in slowpath it should >>>> be OK. (And vice versa mutatis mutandis for clk, gpio, pin >>>> control, interrupts (!) and DMA channels for example.) >>> >>> I understood above that you propose probing devices in order, but now >>> you mention that resource getters would block until the dependency is >>> fulfilled which confuses me because if we are probing in order then >>> all dependencies would be fulfilled before the device in question gets >>> probed. >> >> Sorry, the problem space is a bit convoluted so the answers >> get a bit convoluted. Maybe I'm thinking aloud and altering the course >> of my thoughts as I type... >> >> I guess there can be explicit dependencies for resources like this >> patch does, but another way would be for all resource fetch functions >> to be instrumented, so that you do not block until you try to take >> a resource that is not yet there, e.g.: >> >> regulator_get(...) -> not available, so: >> - identify target regulator provider - this will need instrumentation >> - probe it >> >> It then turns out the regulator driver is on the i2c bus, so we >> need to probe the i2c driver: >> - identify target i2c host for the regulator driver - this will need >> instrumentation >> - probe the i2c host driver >> >> i2c host comes out, probes the regulator driver, regulator driver >> probes and then the regulator_get() call returns. > > Hmm, if I understand correctly what you say, this is exactly what this > particular series does: > > regulator_get -> of_platform_device_ensure -> probe() on the platform > device that encloses the requested device node (i2c host) -> i2c slave > gets probed and the regulator registered -> regulator_get returns the > requested resource The downside of this solution is that it will not work without device tree or even without device dependencies not explicitly specified in device tree. > > The downside I'm currently looking at is that an explicit dependency > graph would be useful to have for other purposes. For example to print > a neat warning when a dependency cannot be fulfilled. Or to refuse to > unbind a device which other devices depend on, As I understand Greg you cannot prevent unbinding by design, see [1]. [1]: http://thread.gmane.org/gmane.linux.kernel/1154308/focus=1154648 > or to automatically > unbind the devices that depend on it, What about devices that have weak dependency? They should not be unbound but they should be somehow noticed about unbinding. In general many kernel frameworks are broken in handling hot-unbinding of drivers, consumers are not noticed about unbinding of their resource providers and usually they stay with broken handles or handles to dummy resources. I suspect the only proper solution for handling resources that can dynamically appear/disappear is to provide notification to their consumers about appearance change of the resource. I have proposed some times ago solution for above problems based on the statement above, cover letter explains it in more detail [2]. In short it solves following issues: - consumer receives resource as soon as it becomes available, - consumer is notified just before resource removal, - it can properly handle provider unbind/re-bind, - it avoids late init due to deferred probing, - it allows to track optional resources. [2]: http://thread.gmane.org/gmane.linux.kernel.gpio/5201 Regards Andrzej > or to print a warning if a > device is hotplugged off and other devices depend on it. > >> This requires instrumentation on anything providing a resource >> to another driver like those I mentioned and a lot of overhead >> infrastructure, but I think it's the right approach. However I don't >> know if I would ever be able to pull that off myself, I know talk >> is cheap and I should show the code instead. > > Yeah, if you can give it a second look and say if it matches what you > wrote above, it would be very much appreciated. > >> Deepest respect for your efforts! > > Thanks! > > Tomeu > >> Yours, >> Linus Walleij >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- > To unsubscribe from this list: send the line "unsubscribe linux-gpio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrzej Hajda Date: Wed, 10 Jun 2015 12:23:25 +0000 Subject: Re: [PATCH 00/21] On-demand device registration Message-Id: <55782C3D.5000606@samsung.com> List-Id: References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tomeu Vizoso , Linus Walleij Cc: Mark Rutland , "devicetree@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , linux-samsung-soc , "linux-tegra@vger.kernel.org" , "linux-pm@vger.kernel.org" , Dmitry Torokhov , "linux-kernel@vger.kernel.org" , "linux-pwm@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Rob Herring , "open list:DRM PANEL DRIVERS" , dmaengine@vger.kernel.org, Alexander Holler , Dan Williams , linux-usb@vger.kernel.org, linux-clk@vger.kernel.org, Grant Likely On 06/10/2015 12:19 PM, Tomeu Vizoso wrote: > On 10 June 2015 at 09:30, Linus Walleij wrote: >> On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso >> wrote: >>> On 2 June 2015 at 10:48, Linus Walleij wrote: >> >>>> This is what systemd is doing in userspace for starting services: >>>> ask for your dependencies and wait for them if they are not >>>> there. So drivers ask for resources and wait for them. It also >>>> needs to be abstract, so for example we need to be able to >>>> hang on regulator_get() until the driver is up and providing that >>>> regulator, and as long as everything is in slowpath it should >>>> be OK. (And vice versa mutatis mutandis for clk, gpio, pin >>>> control, interrupts (!) and DMA channels for example.) >>> >>> I understood above that you propose probing devices in order, but now >>> you mention that resource getters would block until the dependency is >>> fulfilled which confuses me because if we are probing in order then >>> all dependencies would be fulfilled before the device in question gets >>> probed. >> >> Sorry, the problem space is a bit convoluted so the answers >> get a bit convoluted. Maybe I'm thinking aloud and altering the course >> of my thoughts as I type... >> >> I guess there can be explicit dependencies for resources like this >> patch does, but another way would be for all resource fetch functions >> to be instrumented, so that you do not block until you try to take >> a resource that is not yet there, e.g.: >> >> regulator_get(...) -> not available, so: >> - identify target regulator provider - this will need instrumentation >> - probe it >> >> It then turns out the regulator driver is on the i2c bus, so we >> need to probe the i2c driver: >> - identify target i2c host for the regulator driver - this will need >> instrumentation >> - probe the i2c host driver >> >> i2c host comes out, probes the regulator driver, regulator driver >> probes and then the regulator_get() call returns. > > Hmm, if I understand correctly what you say, this is exactly what this > particular series does: > > regulator_get -> of_platform_device_ensure -> probe() on the platform > device that encloses the requested device node (i2c host) -> i2c slave > gets probed and the regulator registered -> regulator_get returns the > requested resource The downside of this solution is that it will not work without device tree or even without device dependencies not explicitly specified in device tree. > > The downside I'm currently looking at is that an explicit dependency > graph would be useful to have for other purposes. For example to print > a neat warning when a dependency cannot be fulfilled. Or to refuse to > unbind a device which other devices depend on, As I understand Greg you cannot prevent unbinding by design, see [1]. [1]: http://thread.gmane.org/gmane.linux.kernel/1154308/focus54648 > or to automatically > unbind the devices that depend on it, What about devices that have weak dependency? They should not be unbound but they should be somehow noticed about unbinding. In general many kernel frameworks are broken in handling hot-unbinding of drivers, consumers are not noticed about unbinding of their resource providers and usually they stay with broken handles or handles to dummy resources. I suspect the only proper solution for handling resources that can dynamically appear/disappear is to provide notification to their consumers about appearance change of the resource. I have proposed some times ago solution for above problems based on the statement above, cover letter explains it in more detail [2]. In short it solves following issues: - consumer receives resource as soon as it becomes available, - consumer is notified just before resource removal, - it can properly handle provider unbind/re-bind, - it avoids late init due to deferred probing, - it allows to track optional resources. [2]: http://thread.gmane.org/gmane.linux.kernel.gpio/5201 Regards Andrzej > or to print a warning if a > device is hotplugged off and other devices depend on it. > >> This requires instrumentation on anything providing a resource >> to another driver like those I mentioned and a lot of overhead >> infrastructure, but I think it's the right approach. However I don't >> know if I would ever be able to pull that off myself, I know talk >> is cheap and I should show the code instead. > > Yeah, if you can give it a second look and say if it matches what you > wrote above, it would be very much appreciated. > >> Deepest respect for your efforts! > > Thanks! > > Tomeu > >> Yours, >> Linus Walleij >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- > To unsubscribe from this list: send the line "unsubscribe linux-gpio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrzej Hajda Subject: Re: [PATCH 00/21] On-demand device registration Date: Wed, 10 Jun 2015 14:23:25 +0200 Message-ID: <55782C3D.5000606@samsung.com> References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-reply-to: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Tomeu Vizoso , Linus Walleij Cc: Mark Rutland , "devicetree@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , linux-samsung-soc , "linux-tegra@vger.kernel.org" , "linux-pm@vger.kernel.org" , Dmitry Torokhov , "linux-kernel@vger.kernel.org" , "linux-pwm@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Rob Herring , "open list:DRM PANEL DRIVERS" , dmaengine@vger.kernel.org, Alexander Holler , Dan Williams , linux-usb@vger.kernel.org, linux-clk@vger.kernel.org, Grant Likely List-Id: linux-gpio@vger.kernel.org T24gMDYvMTAvMjAxNSAxMjoxOSBQTSwgVG9tZXUgVml6b3NvIHdyb3RlOgo+IE9uIDEwIEp1bmUg MjAxNSBhdCAwOTozMCwgTGludXMgV2FsbGVpaiA8bGludXMud2FsbGVpakBsaW5hcm8ub3JnPiB3 cm90ZToKPj4gT24gVHVlLCBKdW4gMiwgMjAxNSBhdCAxMjoxNCBQTSwgVG9tZXUgVml6b3NvCj4+ IDx0b21ldS52aXpvc29AY29sbGFib3JhLmNvbT4gd3JvdGU6Cj4+PiBPbiAyIEp1bmUgMjAxNSBh dCAxMDo0OCwgTGludXMgV2FsbGVpaiA8bGludXMud2FsbGVpakBsaW5hcm8ub3JnPiB3cm90ZToK Pj4KPj4+PiBUaGlzIGlzIHdoYXQgc3lzdGVtZCBpcyBkb2luZyBpbiB1c2Vyc3BhY2UgZm9yIHN0 YXJ0aW5nIHNlcnZpY2VzOgo+Pj4+IGFzayBmb3IgeW91ciBkZXBlbmRlbmNpZXMgYW5kIHdhaXQg Zm9yIHRoZW0gaWYgdGhleSBhcmUgbm90Cj4+Pj4gdGhlcmUuIFNvIGRyaXZlcnMgYXNrIGZvciBy ZXNvdXJjZXMgYW5kIHdhaXQgZm9yIHRoZW0uIEl0IGFsc28KPj4+PiBuZWVkcyB0byBiZSBhYnN0 cmFjdCwgc28gZm9yIGV4YW1wbGUgd2UgbmVlZCB0byBiZSBhYmxlIHRvCj4+Pj4gaGFuZyBvbiBy ZWd1bGF0b3JfZ2V0KCkgdW50aWwgdGhlIGRyaXZlciBpcyB1cCBhbmQgcHJvdmlkaW5nIHRoYXQK Pj4+PiByZWd1bGF0b3IsIGFuZCBhcyBsb25nIGFzIGV2ZXJ5dGhpbmcgaXMgaW4gc2xvd3BhdGgg aXQgc2hvdWxkCj4+Pj4gYmUgT0suIChBbmQgdmljZSB2ZXJzYSBtdXRhdGlzIG11dGFuZGlzIGZv ciBjbGssIGdwaW8sIHBpbgo+Pj4+IGNvbnRyb2wsIGludGVycnVwdHMgKCEpIGFuZCBETUEgY2hh bm5lbHMgZm9yIGV4YW1wbGUuKQo+Pj4KPj4+IEkgdW5kZXJzdG9vZCBhYm92ZSB0aGF0IHlvdSBw cm9wb3NlIHByb2JpbmcgZGV2aWNlcyBpbiBvcmRlciwgYnV0IG5vdwo+Pj4geW91IG1lbnRpb24g dGhhdCByZXNvdXJjZSBnZXR0ZXJzIHdvdWxkIGJsb2NrIHVudGlsIHRoZSBkZXBlbmRlbmN5IGlz Cj4+PiBmdWxmaWxsZWQgd2hpY2ggY29uZnVzZXMgbWUgYmVjYXVzZSBpZiB3ZSBhcmUgcHJvYmlu ZyBpbiBvcmRlciB0aGVuCj4+PiBhbGwgZGVwZW5kZW5jaWVzIHdvdWxkIGJlIGZ1bGZpbGxlZCBi ZWZvcmUgdGhlIGRldmljZSBpbiBxdWVzdGlvbiBnZXRzCj4+PiBwcm9iZWQuCj4+Cj4+IFNvcnJ5 LCB0aGUgcHJvYmxlbSBzcGFjZSBpcyBhIGJpdCBjb252b2x1dGVkIHNvIHRoZSBhbnN3ZXJzCj4+ IGdldCBhIGJpdCBjb252b2x1dGVkLiBNYXliZSBJJ20gdGhpbmtpbmcgYWxvdWQgYW5kIGFsdGVy aW5nIHRoZSBjb3Vyc2UKPj4gb2YgbXkgdGhvdWdodHMgYXMgSSB0eXBlLi4uCj4+Cj4+IEkgZ3Vl c3MgdGhlcmUgY2FuIGJlIGV4cGxpY2l0IGRlcGVuZGVuY2llcyBmb3IgcmVzb3VyY2VzIGxpa2Ug dGhpcwo+PiBwYXRjaCBkb2VzLCBidXQgYW5vdGhlciB3YXkgd291bGQgYmUgZm9yIGFsbCByZXNv dXJjZSBmZXRjaCBmdW5jdGlvbnMKPj4gdG8gYmUgaW5zdHJ1bWVudGVkLCBzbyB0aGF0IHlvdSBk byBub3QgYmxvY2sgdW50aWwgeW91IHRyeSB0byB0YWtlCj4+IGEgcmVzb3VyY2UgdGhhdCBpcyBu b3QgeWV0IHRoZXJlLCBlLmcuOgo+Pgo+PiByZWd1bGF0b3JfZ2V0KC4uLikgLT4gbm90IGF2YWls YWJsZSwgc286Cj4+IC0gaWRlbnRpZnkgdGFyZ2V0IHJlZ3VsYXRvciBwcm92aWRlciAtIHRoaXMg d2lsbCBuZWVkIGluc3RydW1lbnRhdGlvbgo+PiAtIHByb2JlIGl0Cj4+Cj4+IEl0IHRoZW4gdHVy bnMgb3V0IHRoZSByZWd1bGF0b3IgZHJpdmVyIGlzIG9uIHRoZSBpMmMgYnVzLCBzbyB3ZQo+PiBu ZWVkIHRvIHByb2JlIHRoZSBpMmMgZHJpdmVyOgo+PiAtIGlkZW50aWZ5IHRhcmdldCBpMmMgaG9z dCBmb3IgdGhlIHJlZ3VsYXRvciBkcml2ZXIgLSB0aGlzIHdpbGwgbmVlZAo+PiAgIGluc3RydW1l bnRhdGlvbgo+PiAtIHByb2JlIHRoZSBpMmMgaG9zdCBkcml2ZXIKPj4KPj4gaTJjIGhvc3QgY29t ZXMgb3V0LCBwcm9iZXMgdGhlIHJlZ3VsYXRvciBkcml2ZXIsIHJlZ3VsYXRvciBkcml2ZXIKPj4g cHJvYmVzIGFuZCB0aGVuIHRoZSByZWd1bGF0b3JfZ2V0KCkgY2FsbCByZXR1cm5zLgo+IAo+IEht bSwgaWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSB3aGF0IHlvdSBzYXksIHRoaXMgaXMgZXhhY3Rs eSB3aGF0IHRoaXMKPiBwYXJ0aWN1bGFyIHNlcmllcyBkb2VzOgo+IAo+IHJlZ3VsYXRvcl9nZXQg LT4gb2ZfcGxhdGZvcm1fZGV2aWNlX2Vuc3VyZSAtPiBwcm9iZSgpIG9uIHRoZSBwbGF0Zm9ybQo+ IGRldmljZSB0aGF0IGVuY2xvc2VzIHRoZSByZXF1ZXN0ZWQgZGV2aWNlIG5vZGUgKGkyYyBob3N0 KSAtPiBpMmMgc2xhdmUKPiBnZXRzIHByb2JlZCBhbmQgdGhlIHJlZ3VsYXRvciByZWdpc3RlcmVk IC0+IHJlZ3VsYXRvcl9nZXQgcmV0dXJucyB0aGUKPiByZXF1ZXN0ZWQgcmVzb3VyY2UKClRoZSBk b3duc2lkZSBvZiB0aGlzIHNvbHV0aW9uIGlzIHRoYXQgaXQgd2lsbCBub3Qgd29yayB3aXRob3V0 IGRldmljZQp0cmVlIG9yIGV2ZW4gd2l0aG91dCBkZXZpY2UgZGVwZW5kZW5jaWVzIG5vdCBleHBs aWNpdGx5IHNwZWNpZmllZCBpbgpkZXZpY2UgdHJlZS4KCj4gCj4gVGhlIGRvd25zaWRlIEknbSBj dXJyZW50bHkgbG9va2luZyBhdCBpcyB0aGF0IGFuIGV4cGxpY2l0IGRlcGVuZGVuY3kKPiBncmFw aCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBmb3Igb3RoZXIgcHVycG9zZXMuIEZvciBleGFtcGxl IHRvIHByaW50Cj4gYSBuZWF0IHdhcm5pbmcgd2hlbiBhIGRlcGVuZGVuY3kgY2Fubm90IGJlIGZ1 bGZpbGxlZC4gT3IgdG8gcmVmdXNlIHRvCj4gdW5iaW5kIGEgZGV2aWNlIHdoaWNoIG90aGVyIGRl dmljZXMgZGVwZW5kIG9uLAoKQXMgSSB1bmRlcnN0YW5kIEdyZWcgeW91IGNhbm5vdCBwcmV2ZW50 IHVuYmluZGluZyBieSBkZXNpZ24sIHNlZSBbMV0uCgpbMV06IGh0dHA6Ly90aHJlYWQuZ21hbmUu b3JnL2dtYW5lLmxpbnV4Lmtlcm5lbC8xMTU0MzA4L2ZvY3VzPTExNTQ2NDgKCj4gb3IgdG8gYXV0 b21hdGljYWxseQo+IHVuYmluZCB0aGUgZGV2aWNlcyB0aGF0IGRlcGVuZCBvbiBpdCwKCldoYXQg YWJvdXQgZGV2aWNlcyB0aGF0IGhhdmUgd2VhayBkZXBlbmRlbmN5PyBUaGV5IHNob3VsZCBub3Qg YmUgdW5ib3VuZApidXQgdGhleSBzaG91bGQgYmUgc29tZWhvdyBub3RpY2VkIGFib3V0IHVuYmlu ZGluZy4KCkluIGdlbmVyYWwgbWFueSBrZXJuZWwgZnJhbWV3b3JrcyBhcmUgYnJva2VuIGluIGhh bmRsaW5nIGhvdC11bmJpbmRpbmcKb2YgZHJpdmVycywgY29uc3VtZXJzIGFyZSBub3Qgbm90aWNl ZCBhYm91dCB1bmJpbmRpbmcgb2YgdGhlaXIgcmVzb3VyY2UKcHJvdmlkZXJzIGFuZCB1c3VhbGx5 IHRoZXkgc3RheSB3aXRoIGJyb2tlbiBoYW5kbGVzIG9yIGhhbmRsZXMgdG8gZHVtbXkKcmVzb3Vy Y2VzLgoKSSBzdXNwZWN0IHRoZSBvbmx5IHByb3BlciBzb2x1dGlvbiBmb3IgaGFuZGxpbmcgcmVz b3VyY2VzIHRoYXQgY2FuCmR5bmFtaWNhbGx5IGFwcGVhci9kaXNhcHBlYXIgaXMgdG8gcHJvdmlk ZSBub3RpZmljYXRpb24gdG8gdGhlaXIKY29uc3VtZXJzIGFib3V0IGFwcGVhcmFuY2UgY2hhbmdl IG9mIHRoZSByZXNvdXJjZS4KCkkgaGF2ZSBwcm9wb3NlZCBzb21lIHRpbWVzIGFnbyBzb2x1dGlv biBmb3IgYWJvdmUgcHJvYmxlbXMgYmFzZWQgb24gdGhlCnN0YXRlbWVudCBhYm92ZSwgY292ZXIg bGV0dGVyIGV4cGxhaW5zIGl0IGluIG1vcmUgZGV0YWlsIFsyXS4KSW4gc2hvcnQgaXQgc29sdmVz IGZvbGxvd2luZyBpc3N1ZXM6Ci0gY29uc3VtZXIgcmVjZWl2ZXMgcmVzb3VyY2UgYXMgc29vbiBh cyBpdCBiZWNvbWVzIGF2YWlsYWJsZSwKLSBjb25zdW1lciBpcyBub3RpZmllZCBqdXN0IGJlZm9y ZSByZXNvdXJjZSByZW1vdmFsLAotIGl0IGNhbiBwcm9wZXJseSBoYW5kbGUgcHJvdmlkZXIgdW5i aW5kL3JlLWJpbmQsCi0gaXQgYXZvaWRzIGxhdGUgaW5pdCBkdWUgdG8gZGVmZXJyZWQgcHJvYmlu ZywKLSBpdCBhbGxvd3MgdG8gdHJhY2sgb3B0aW9uYWwgcmVzb3VyY2VzLgoKWzJdOiBodHRwOi8v dGhyZWFkLmdtYW5lLm9yZy9nbWFuZS5saW51eC5rZXJuZWwuZ3Bpby81MjAxCgpSZWdhcmRzCkFu ZHJ6ZWoKCj4gb3IgdG8gcHJpbnQgYSB3YXJuaW5nIGlmIGEKPiBkZXZpY2UgaXMgaG90cGx1Z2dl ZCBvZmYgYW5kIG90aGVyIGRldmljZXMgZGVwZW5kIG9uIGl0Lgo+IAo+PiBUaGlzIHJlcXVpcmVz IGluc3RydW1lbnRhdGlvbiBvbiBhbnl0aGluZyBwcm92aWRpbmcgYSByZXNvdXJjZQo+PiB0byBh bm90aGVyIGRyaXZlciBsaWtlIHRob3NlIEkgbWVudGlvbmVkIGFuZCBhIGxvdCBvZiBvdmVyaGVh ZAo+PiBpbmZyYXN0cnVjdHVyZSwgYnV0IEkgdGhpbmsgaXQncyB0aGUgcmlnaHQgYXBwcm9hY2gu IEhvd2V2ZXIgSSBkb24ndAo+PiBrbm93IGlmIEkgd291bGQgZXZlciBiZSBhYmxlIHRvIHB1bGwg dGhhdCBvZmYgbXlzZWxmLCBJIGtub3cgdGFsawo+PiBpcyBjaGVhcCBhbmQgSSBzaG91bGQgc2hv dyB0aGUgY29kZSBpbnN0ZWFkLgo+IAo+IFllYWgsIGlmIHlvdSBjYW4gZ2l2ZSBpdCBhIHNlY29u ZCBsb29rIGFuZCBzYXkgaWYgaXQgbWF0Y2hlcyB3aGF0IHlvdQo+IHdyb3RlIGFib3ZlLCBpdCB3 b3VsZCBiZSB2ZXJ5IG11Y2ggYXBwcmVjaWF0ZWQuCj4gCj4+IERlZXBlc3QgcmVzcGVjdCBmb3Ig eW91ciBlZmZvcnRzIQo+IAo+IFRoYW5rcyEKPiAKPiBUb21ldQo+IAo+PiBZb3VycywKPj4gTGlu dXMgV2FsbGVpago+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwo+PiBkcmktZGV2ZWwgbWFpbGluZyBsaXN0Cj4+IGRyaS1kZXZlbEBsaXN0cy5mcmVlZGVz a3RvcC5vcmcKPj4gaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RyaS1kZXZlbAo+IC0tCj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhl IGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LWdwaW8iIGluCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdl IHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcKPiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBo dHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwKPiAKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxp c3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwOi8vbGlzdHMuZnJlZWRlc2t0 b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==