Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752902AbbFKLYm (ORCPT ); Thu, 11 Jun 2015 07:24:42 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:53599 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751114AbbFKLY2 (ORCPT ); Thu, 11 Jun 2015 07:24:28 -0400 Message-ID: <55796FDE.7080701@ahsoftware.de> Date: Thu, 11 Jun 2015 13:24:14 +0200 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Linus Walleij CC: Tomeu Vizoso , Grant Likely , Mark Rutland , "devicetree@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , linux-samsung-soc , "linux-tegra@vger.kernel.org" , "linux-gpio@vger.kernel.org" , "linux-pm@vger.kernel.org" , Dmitry Torokhov , "linux-kernel@vger.kernel.org" , Rob Herring , "linux-pwm@vger.kernel.org" , open@wandq.ahsoftware, "list@wandq.ahsoftware:DRM PANEL DRIVERS" , dmaengine@vger.kernel.org, Dan Williams , "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> <5577F533.1060007@ahsoftware.de> <5579602F.1070801@ahsoftware.de> In-Reply-To: <5579602F.1070801@ahsoftware.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2390 Lines: 56 Am 11.06.2015 um 12:17 schrieb Alexander Holler: > Am 11.06.2015 um 10:12 schrieb Linus Walleij: >> On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler >> wrote: >>> Am 10.06.2015 um 09:30 schrieb Linus Walleij: >> >>>> i2c host comes out, probes the regulator driver, regulator driver >>>> probes and then the regulator_get() call returns. >>>> >>>> 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. >>> >>> You would end up with the same problem of deadlocks as currently, and >>> you >>> would still need something ugly like the defered probe brutforce to >>> avoid >>> them. >> >> Sorry I don't get that. Care to elaborate on why? > > Because loading/initializing on demand doesn't give you any solved order > of drivers to initialize. And it can't because it has no idea about the > requirements of other drivers. The reason why it might work better in > the case of the tegra is that it might give you another initialization > order than the one which is currently choosen, which, by luck, might be > a better one. > > But maybe I missed something, I haven't looked at the patches at all. > But just loading on demand, can't magically give you a working order of > drivers to initialize. E.g. how do you choose the first driver to > initialize? Other problems you will run into are time constraints and multithreaded drivers. E.g. we all should know how tricky it sometimes is to avoid deadlocks. And with loading on demand, you are extending this problem over the initialization of maybe a whole bunch of other drivers which might be started by calling one function of another driver. And a function call might need a very long time to finish during which an unpredictable amount of things may happen. It would make me wonder if that will end up with a good, usable and as simple as possible solution. Regards, Alexander Holler -- 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/