Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754805AbbFKQk3 (ORCPT ); Thu, 11 Jun 2015 12:40:29 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:41865 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752236AbbFKQkW (ORCPT ); Thu, 11 Jun 2015 12:40:22 -0400 Message-ID: <5579B9E8.9040609@ahsoftware.de> Date: Thu, 11 Jun 2015 18:40:08 +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" , "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: 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: 2307 Lines: 54 Am 11.06.2015 um 14:30 schrieb Linus Walleij: > On Thu, Jun 11, 2015 at 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: > >>>> 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? > > So the current patch set introduces dependencies (just for device tree) > and Tomeu is working on a more generic dependency approach for > any HW description. > > The first driver to initialize will be as usual the first one in the list for > that initlevel, then walking up the initilevels. > > However if any driver runs into a resource roadblock it will postpone > and wait for dependencies to probe first. > > Certainly it is possible to create deadlocks in this scenario, but the > scope is not to create an ubreakable system. IAnd what happens if you run into a deadlock? Do you print "you've lost, try changing your kernel config" in some output hidden by a splash-screen? ;) That sounds like the fun with duck typed languages where you have to test any and every possible screnario (something which is almost impossible) in order to not run into something unexpected. Anyway, have fun, good luck. 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/