Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031688AbbD2JrB (ORCPT ); Wed, 29 Apr 2015 05:47:01 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:33591 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966091AbbD2Jq4 (ORCPT ); Wed, 29 Apr 2015 05:46:56 -0400 Message-ID: <5540A883.8060708@ahsoftware.de> Date: Wed, 29 Apr 2015 11:46:43 +0200 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Tomeu Vizoso CC: "linux-kernel@vger.kernel.org" , Thierry Reding , =?UTF-8?B?U3TDqXBoYW5lIE1hcmNoZXNpbg==?= , Olof Johansson , Grant Likely , Rob Herring , "devicetree@vger.kernel.org" , Mark Rutland Subject: Re: [RFC 00/12] On-demand device registration References: <1429886848-5843-1-git-send-email-tomeu.vizoso@collabora.com> <553ACE96.2040804@ahsoftware.de> <553FCECB.7040005@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: 2897 Lines: 67 Am 29.04.2015 um 08:58 schrieb Tomeu Vizoso: > On 28 April 2015 at 20:17, Alexander Holler wrote: >> Am 28.04.2015 um 14:49 schrieb Tomeu Vizoso: >>> >>> On 25 April 2015 at 01:15, Alexander Holler wrote: >>>> >>>> Am 24.04.2015 um 16:47 schrieb Tomeu Vizoso: >>>>> >>>>> Hi, >>>>> >>>>> while reading the thread [0] that Alexander Holler started with his >>>>> series to make probing order deterministic, it occurred to me that it should >>>>> be possible to achieve the same by probing devices as they are referenced by >>>>> other devices. >>>>> >>>>> This basically reuses the information that is already embedded in the >>>>> probe() implementations, saving us from refactoring existing drivers or >>>>> adding information to DTBs. >>>>> >>>>> The main issue I see is that the registration code path in some >>>>> subsystems may not be reentrant, so some refactoring of the locking will be >>>>> needed. In my testing I have found this problem with regulators, as the >>>>> supply of a regulator might end up being registered during the registration >>>>> of the first one. >>>>> >>>>> Something I'm not completely happy with is that I have had to move the >>>>> population of the device tree after all platform drivers have been >>>>> registered. Otherwise I don't see how I could register drivers on demand as >>>>> we don't have yet each driver's compatible strings. >>>>> >>>>> I have done my testing on a Tegra124-based Chromebook, and these patches >>>>> were enough to eliminate all the deferred probes. >>>> >>>> >>>> First you have to solve a problem which is totally unrelated to DT or >>>> ACPI or x86 or ARM: >>>> >>>> I think as long as drivers don't register themself whithout any side >>>> effect, this problem isn't solvable. In order to make an ordered list of >>>> drivers to start, you need to know which drivers are actually available. >>> >>> >>> Yeah, I kind of side-stepped that issue by waiting until all drivers >>> have been registered before registering devices. I think someone >>> suggested doing so in your thread (maybe Grant?). >> >> >> That doesn't work. As said above, several drivers doing a lot more than just >> registering in their initcall. They might even crash if some prerequisits >> aren't given. And several of these prerequisits (init orders) are hardcoded >> by various means. > > But aren't those dependencies being taken care currently by the > initcall level the driver is placed in? That remains the same in this > approach. In short, no. There are various very ugly things done in several drivers to enforce some order. 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/