Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933202AbbFJMXz (ORCPT ); Wed, 10 Jun 2015 08:23:55 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:40608 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753171AbbFJMXn (ORCPT ); Wed, 10 Jun 2015 08:23:43 -0400 X-AuditID: cbfec7f5-f794b6d000001495-e9-55782c4a51bd Message-id: <55782C3D.5000606@samsung.com> Date: Wed, 10 Jun 2015 14:23:25 +0200 From: Andrzej Hajda User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-version: 1.0 Newsgroups: gmane.linux.kernel.gpio,gmane.linux.drivers.devicetree,gmane.linux.kernel.samsung-soc,gmane.linux.power-management.general,gmane.linux.kernel,gmane.linux.pwm,gmane.linux.ports.tegra,gmane.comp.video.dri.devel,gmane.linux.usb.general,gmane.linux.ports.arm.kernel,gmane.linux.drivers.i2c 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 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsVy+t/xy7peOhWhBi3zbCymT73AaDH/yDlW i9VT/7JaHF70gtHiytf3bBYH/uxgtPjXvYvJYsqf5UwWH3vusVqc6PvAarF5/h9Gi8u75rBZ fO49wmhx9+4qRosZ5/cxWXR+mcVmsWhZK7PF0usXmSxa9x5ht+hbe4nNQcRjdmcDm8eaeWsY PXbcXcLosXPWXXaPxXteMnlsWtXJ5nHn2h42j/vdx5k8Pm+SC+CM4rJJSc3JLEst0rdL4Mr4 +OAga8EhjYoPM6ezNTA+Vuhi5OCQEDCRmLyFtYuRE8gUk7hwbz1bFyMXh5DAUkaJ5U3r2SGc 54wSnW+XMIFU8QpoSSw8uIcZpJlFQFVi7WRNkDCbgKbE38032UBsUYEIibeXT0KVC0r8mHyP BWQOn8BqJonXG7cwgyREBCIlerqXMoMkmAV+sElM2nyMHSQhLGAhcWT7Q2aIzc+YJA72/GYB 2cYpECxx/VkiiMksoC4xZUouSDmzgLzE5jVvmScwCs5Csm8WQtUsJFULGJlXMYqmliYXFCel 5xrpFSfmFpfmpesl5+duYoRE6dcdjEuPWR1iFOBgVOLhdcguDxViTSwrrsw9xCjBwawkwssk VREqxJuSWFmVWpQfX1Sak1p8iFGag0VJnHfmrvchQgLpiSWp2ampBalFMFkmDk6pBkZ1X801 p6Sv7uQsnMKzwS+87N7OrJXqBq/3GDNuOZdpc2uB1d5JBVf99jcpX9lasiekJNSJt5RNWsju 3own7A8d9miuiOSumRZYeJWlplsqo+5O8rZ7RufD9n3e+KpGfldDVdwex+3/RRbP+6Dyo2Sp 7bUEk6P7o+f8TNPLZVXT7gzgrZfIXqHEUpyRaKjFXFScCADIHMllzgIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5307 Lines: 129 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/