From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <55795B4A.6030008@collabora.com> Date: Thu, 11 Jun 2015 11:56:26 +0200 From: Tomeu Vizoso MIME-Version: 1.0 To: Linus Walleij Subject: Re: [PATCH 00/21] On-demand device registration References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> In-Reply-To: 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-i2c@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Rob Herring , DRM PANEL DRIVERS , dmaengine@vger.kernel.org, Alexander Holler , Dan Williams , "linux-usb@vger.kernel.org" , linux-clk@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , Grant Likely List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+mturquette=linaro.org@lists.infradead.org List-ID: On 06/11/2015 10:15 AM, Linus Walleij wrote: > On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso > wrote: >> On 10 June 2015 at 09:30, Linus Walleij wrote: > >>> 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 > > Yes. But only for 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, or to automatically >> unbind the devices that depend on it, or to print a warning if a >> device is hotplugged off and other devices depend on it. > > Unbind/remove() calls are the inverse usually yes. > > But also the [runtime] power up/down sequences for the > devices tend to depend on a similar ordering or mostly > the same. (Mentioned this before I think.) > >>> 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. > > Yes you are right. But what about ACPI, board files, > Simple Firmware and future hardware description languages... Ah ok, got it now. With fwnode and by moving a bit of code around that shouldn't be a problem. I'm actually now implementing the alternative approach in which dependencies are discovered before the device is probed, then probed in turn until all are available. So functionally is very similar but I expect to find big differences in how the codebase is impacted. Regards, Tomeu > Yours, > Linus Walleij > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomeu Vizoso Subject: Re: [PATCH 00/21] On-demand device registration Date: Thu, 11 Jun 2015 11:56:26 +0200 Message-ID: <55795B4A.6030008@collabora.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: 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-i2c@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Rob Herring , DRM PANEL DRIVERS , dmaengine@vger.kernel.org, Alexander Holler , Dan Williams , "linux-usb@vger.kernel.org" , linux-clk@vger.ker List-Id: linux-gpio@vger.kernel.org T24gMDYvMTEvMjAxNSAxMDoxNSBBTSwgTGludXMgV2FsbGVpaiB3cm90ZToKPiBPbiBXZWQsIEp1 biAxMCwgMjAxNSBhdCAxMjoxOSBQTSwgVG9tZXUgVml6b3NvCj4gPHRvbWV1LnZpem9zb0Bjb2xs YWJvcmEuY29tPiB3cm90ZToKPj4gT24gMTAgSnVuZSAyMDE1IGF0IDA5OjMwLCBMaW51cyBXYWxs ZWlqIDxsaW51cy53YWxsZWlqQGxpbmFyby5vcmc+IHdyb3RlOgo+IAo+Pj4gcmVndWxhdG9yX2dl dCguLi4pIC0+IG5vdCBhdmFpbGFibGUsIHNvOgo+Pj4gLSBpZGVudGlmeSB0YXJnZXQgcmVndWxh dG9yIHByb3ZpZGVyIC0gdGhpcyB3aWxsIG5lZWQgaW5zdHJ1bWVudGF0aW9uCj4+PiAtIHByb2Jl IGl0Cj4+Pgo+Pj4gSXQgdGhlbiB0dXJucyBvdXQgdGhlIHJlZ3VsYXRvciBkcml2ZXIgaXMgb24g dGhlIGkyYyBidXMsIHNvIHdlCj4+PiBuZWVkIHRvIHByb2JlIHRoZSBpMmMgZHJpdmVyOgo+Pj4g LSBpZGVudGlmeSB0YXJnZXQgaTJjIGhvc3QgZm9yIHRoZSByZWd1bGF0b3IgZHJpdmVyIC0gdGhp cyB3aWxsIG5lZWQKPj4+ICAgaW5zdHJ1bWVudGF0aW9uCj4+PiAtIHByb2JlIHRoZSBpMmMgaG9z dCBkcml2ZXIKPj4+Cj4+PiBpMmMgaG9zdCBjb21lcyBvdXQsIHByb2JlcyB0aGUgcmVndWxhdG9y IGRyaXZlciwgcmVndWxhdG9yIGRyaXZlcgo+Pj4gcHJvYmVzIGFuZCB0aGVuIHRoZSByZWd1bGF0 b3JfZ2V0KCkgY2FsbCByZXR1cm5zLgo+Pgo+PiBIbW0sIGlmIEkgdW5kZXJzdGFuZCBjb3JyZWN0 bHkgd2hhdCB5b3Ugc2F5LCB0aGlzIGlzIGV4YWN0bHkgd2hhdCB0aGlzCj4+IHBhcnRpY3VsYXIg c2VyaWVzIGRvZXM6Cj4+Cj4+IHJlZ3VsYXRvcl9nZXQgLT4gb2ZfcGxhdGZvcm1fZGV2aWNlX2Vu c3VyZSAtPiBwcm9iZSgpIG9uIHRoZSBwbGF0Zm9ybQo+PiBkZXZpY2UgdGhhdCBlbmNsb3NlcyB0 aGUgcmVxdWVzdGVkIGRldmljZSBub2RlIChpMmMgaG9zdCkgLT4gaTJjIHNsYXZlCj4+IGdldHMg cHJvYmVkIGFuZCB0aGUgcmVndWxhdG9yIHJlZ2lzdGVyZWQgLT4gcmVndWxhdG9yX2dldCByZXR1 cm5zIHRoZQo+PiByZXF1ZXN0ZWQgcmVzb3VyY2UKPiAKPiBZZXMuIEJ1dCBvbmx5IGZvciBkZXZp Y2UgdHJlZS4KPiAKPj4gVGhlIGRvd25zaWRlIEknbSBjdXJyZW50bHkgbG9va2luZyBhdCBpcyB0 aGF0IGFuIGV4cGxpY2l0IGRlcGVuZGVuY3kKPj4gZ3JhcGggd291bGQgYmUgdXNlZnVsIHRvIGhh dmUgZm9yIG90aGVyIHB1cnBvc2VzLiBGb3IgZXhhbXBsZSB0byBwcmludAo+PiBhIG5lYXQgd2Fy bmluZyB3aGVuIGEgZGVwZW5kZW5jeSBjYW5ub3QgYmUgZnVsZmlsbGVkLiBPciB0byByZWZ1c2Ug dG8KPj4gdW5iaW5kIGEgZGV2aWNlIHdoaWNoIG90aGVyIGRldmljZXMgZGVwZW5kIG9uLCBvciB0 byBhdXRvbWF0aWNhbGx5Cj4+IHVuYmluZCB0aGUgZGV2aWNlcyB0aGF0IGRlcGVuZCBvbiBpdCwg b3IgdG8gcHJpbnQgYSB3YXJuaW5nIGlmIGEKPj4gZGV2aWNlIGlzIGhvdHBsdWdnZWQgb2ZmIGFu ZCBvdGhlciBkZXZpY2VzIGRlcGVuZCBvbiBpdC4KPiAKPiBVbmJpbmQvcmVtb3ZlKCkgY2FsbHMg YXJlIHRoZSBpbnZlcnNlIHVzdWFsbHkgeWVzLgo+IAo+IEJ1dCBhbHNvIHRoZSBbcnVudGltZV0g cG93ZXIgdXAvZG93biBzZXF1ZW5jZXMgZm9yIHRoZQo+IGRldmljZXMgdGVuZCB0byBkZXBlbmQg b24gYSBzaW1pbGFyIG9yZGVyaW5nIG9yIG1vc3RseQo+IHRoZSBzYW1lLiAoTWVudGlvbmVkIHRo aXMgYmVmb3JlIEkgdGhpbmsuKQo+IAo+Pj4gVGhpcyByZXF1aXJlcyBpbnN0cnVtZW50YXRpb24g b24gYW55dGhpbmcgcHJvdmlkaW5nIGEgcmVzb3VyY2UKPj4+IHRvIGFub3RoZXIgZHJpdmVyIGxp a2UgdGhvc2UgSSBtZW50aW9uZWQgYW5kIGEgbG90IG9mIG92ZXJoZWFkCj4+PiBpbmZyYXN0cnVj dHVyZSwgYnV0IEkgdGhpbmsgaXQncyB0aGUgcmlnaHQgYXBwcm9hY2guIEhvd2V2ZXIgSSBkb24n dAo+Pj4ga25vdyBpZiBJIHdvdWxkIGV2ZXIgYmUgYWJsZSB0byBwdWxsIHRoYXQgb2ZmIG15c2Vs ZiwgSSBrbm93IHRhbGsKPj4+IGlzIGNoZWFwIGFuZCBJIHNob3VsZCBzaG93IHRoZSBjb2RlIGlu c3RlYWQuCj4+Cj4+IFllYWgsIGlmIHlvdSBjYW4gZ2l2ZSBpdCBhIHNlY29uZCBsb29rIGFuZCBz YXkgaWYgaXQgbWF0Y2hlcyB3aGF0IHlvdQo+PiB3cm90ZSBhYm92ZSwgaXQgd291bGQgYmUgdmVy eSBtdWNoIGFwcHJlY2lhdGVkLgo+IAo+IFllcyB5b3UgYXJlIHJpZ2h0LiBCdXQgd2hhdCBhYm91 dCBBQ1BJLCBib2FyZCBmaWxlcywKPiBTaW1wbGUgRmlybXdhcmUgYW5kIGZ1dHVyZSBoYXJkd2Fy ZSBkZXNjcmlwdGlvbiBsYW5ndWFnZXMuLi4KCkFoIG9rLCBnb3QgaXQgbm93LiBXaXRoIGZ3bm9k ZSBhbmQgYnkgbW92aW5nIGEgYml0IG9mIGNvZGUgYXJvdW5kIHRoYXQKc2hvdWxkbid0IGJlIGEg cHJvYmxlbS4KCkknbSBhY3R1YWxseSBub3cgaW1wbGVtZW50aW5nIHRoZSBhbHRlcm5hdGl2ZSBh cHByb2FjaCBpbiB3aGljaApkZXBlbmRlbmNpZXMgYXJlIGRpc2NvdmVyZWQgYmVmb3JlIHRoZSBk ZXZpY2UgaXMgcHJvYmVkLCB0aGVuIHByb2JlZCBpbgp0dXJuIHVudGlsIGFsbCBhcmUgYXZhaWxh YmxlLiBTbyBmdW5jdGlvbmFsbHkgaXMgdmVyeSBzaW1pbGFyIGJ1dCBJCmV4cGVjdCB0byBmaW5k IGJpZyBkaWZmZXJlbmNlcyBpbiBob3cgdGhlIGNvZGViYXNlIGlzIGltcGFjdGVkLgoKUmVnYXJk cywKClRvbWV1Cgo+IFlvdXJzLAo+IExpbnVzIFdhbGxlaWoKPiAKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJp LWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3Jn L21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: tomeu.vizoso@collabora.com (Tomeu Vizoso) Date: Thu, 11 Jun 2015 11:56:26 +0200 Subject: [PATCH 00/21] On-demand device registration In-Reply-To: References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> Message-ID: <55795B4A.6030008@collabora.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 06/11/2015 10:15 AM, Linus Walleij wrote: > On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso > wrote: >> On 10 June 2015 at 09:30, Linus Walleij wrote: > >>> 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 > > Yes. But only for 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, or to automatically >> unbind the devices that depend on it, or to print a warning if a >> device is hotplugged off and other devices depend on it. > > Unbind/remove() calls are the inverse usually yes. > > But also the [runtime] power up/down sequences for the > devices tend to depend on a similar ordering or mostly > the same. (Mentioned this before I think.) > >>> 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. > > Yes you are right. But what about ACPI, board files, > Simple Firmware and future hardware description languages... Ah ok, got it now. With fwnode and by moving a bit of code around that shouldn't be a problem. I'm actually now implementing the alternative approach in which dependencies are discovered before the device is probed, then probed in turn until all are available. So functionally is very similar but I expect to find big differences in how the codebase is impacted. Regards, Tomeu > Yours, > Linus Walleij >