From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754684AbbFKNKJ (ORCPT ); Thu, 11 Jun 2015 09:10:09 -0400 Received: from bhuna.collabora.co.uk ([93.93.135.160]:52276 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932587AbbFKNJx (ORCPT ); Thu, 11 Jun 2015 09:09:53 -0400 Message-ID: <55798899.10504@collabora.com> Date: Thu, 11 Jun 2015 15:09:45 +0200 From: Tomeu Vizoso User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexander Holler , Linus Walleij CC: 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 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/11/2015 12:17 PM, Alexander Holler wrote: > 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. So, this is only about ordering device probing. All built-in drivers have already registered themselves by when we start probing. > 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. Note that this series was also tested on iMX.6, Exynos and OMAP4. > But maybe I missed something, I haven't looked at the patches at all. It's a really small patchset :) 19 files changed, 130 insertions(+), 45 deletions(-) Thanks, Tomeu > 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? > > Regards, > > Alexander Holler >