Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751787AbbEZPJI (ORCPT ); Tue, 26 May 2015 11:09:08 -0400 Received: from mail-qg0-f44.google.com ([209.85.192.44]:34499 "EHLO mail-qg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751572AbbEZPJE (ORCPT ); Tue, 26 May 2015 11:09:04 -0400 MIME-Version: 1.0 In-Reply-To: <20150526093601.GH21577@sirena.org.uk> References: <1432565608-26036-1-git-send-email-tomeu.vizoso@collabora.com> <1432565608-26036-11-git-send-email-tomeu.vizoso@collabora.com> <20150525173244.GE21577@sirena.org.uk> <20150526093601.GH21577@sirena.org.uk> From: Tomeu Vizoso Date: Tue, 26 May 2015 17:08:38 +0200 X-Google-Sender-Auth: _hDuI8XOLLTy9CkisquPWT3JL94 Message-ID: Subject: Re: [PATCH 10/21] regulator: core: Probe regulators on demand To: Mark Brown Cc: Mark Rutland , Dmitry Torokhov , Liam Girdwood , Rob Herring , "linux-kernel@vger.kernel.org" , =?UTF-8?Q?St=C3=A9phane_Marchesin?= , Thierry Reding , Grant Likely , Alexander Holler , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2446 Lines: 54 On 26 May 2015 at 11:36, Mark Brown wrote: > On Tue, May 26, 2015 at 08:17:23AM +0200, Tomeu Vizoso wrote: >> On 25 May 2015 at 19:32, Mark Brown wrote: > >> > The obvious questions here based on the name are why we're doing >> > something specific to platform devices and why this isn't something >> > we're abstracting in the driver core (or at least generic firmware code) >> > - we're going to have the same thing with ACPI. > >> I don't know how useful this is going to be in systems with ACPI. My >> experience is limited to 32bit ARM, where the kernel has to manage >> every regulator, clock, gpio, etc so the dependency tree is so big. Is >> deferred probing a problem with ACPI as well? > > Yes, x86 based embedded systems use ACPI (and we really ought to be > trying to help systems using board files too for that matter). Yes, I see how registering devices on-demand could be implemented for all those, but what I don't see is how they would benefit from it. I can see an hypothetical maintenance benefit in sharing as much code as possible between these different scenarios, but in this case, because this feature is so closely tied to machine description I think complexity would be actually bigger. The problem I'm trying to address only manifests on systems with dozens of devices that are currently registered in an arbitrary order (as they are in the DT). On machines that have ACPI, most of those devices aren't exposed to the kernel and few or no deferred probes happen (though I have only tested on qemu and Minnowboard MAX, both with no deferred probes). On machines with board files, devices are registered in a predetermined order, presumably without any deferred probes. My understanding is that the problem I'm addressing is specific of machines in which the kernel is in charge of pretty much everything and that the information about what devices are present is given in an arbitrary order. Deferred probe gives us reliably a working system at the end for these machines, but in the meantime some devices will have been deferred several times and when they get to probe the user will have noticed the delay. Regards, Tomeu -- 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/