Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755932AbbEZQzW (ORCPT ); Tue, 26 May 2015 12:55:22 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:57483 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755898AbbEZQzS (ORCPT ); Tue, 26 May 2015 12:55:18 -0400 Date: Tue, 26 May 2015 17:54:58 +0100 From: Mark Brown To: Tomeu Vizoso Cc: Mark Rutland , Dmitry Torokhov , Liam Girdwood , Rob Herring , "linux-kernel@vger.kernel.org" , =?iso-8859-1?Q?St=E9phane?= Marchesin , Thierry Reding , Grant Likely , Alexander Holler , "linux-arm-kernel@lists.infradead.org" Message-ID: <20150526165458.GV21577@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="99tYZFKVtXCNe/u4" Content-Disposition: inline In-Reply-To: X-Cookie: Positively no smoking. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 10/21] regulator: core: Probe regulators on demand X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3602 Lines: 81 --99tYZFKVtXCNe/u4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 26, 2015 at 05:08:38PM +0200, Tomeu Vizoso wrote: > On 26 May 2015 at 11:36, Mark Brown wrote: > > 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. You'd need to be clearer about what problem you're trying to solve there, which is something you left us guessing at! > 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. We've now got abstractions for common firmware operations (look at the fwnode stuff) and this isn't exactly deep introspection here. If you're trying to solve the probe order problem you can probably get a long way by just doing something that boils down to "try to instantiate everything referenced from this node" which could probably even be kicked from the driver core prior to probe and cover most cases. Or put this into the node lookup interface so we try to instantiate everything we reference. > 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 the machines that you happen to have looked at; I would rather expect that x86 based phones will be in a similar situation once they move to ACPI which they should be doing this year if they didn't already, and the embedded systems will doubtless run into this once they have any meaningful hardware on them (the base Minnoboard isn't really interesting here, it's once you build a system on top of that). > On machines with board files, devices are registered in a > predetermined order, presumably without any deferred probes. No, not in the least. Quite aside from anything else as soon as you allow things to be built as modules userspace is free to load things in whatever order amuses it. Think about what's going on here - it's not just registration of devices, it's also about the order in which subsystems and drivers register themselves. > 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. I don't think you've fully understood the problem space here. --99tYZFKVtXCNe/u4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVZKVhAAoJECTWi3JdVIfQpgsH/0e2DNVrpOxTvDgQUOUOh3Ti to3Rb6FM8R2naywVyWeaafKoeDCD+Dx1KEYDP4UDKhqKyDNmh6dnb6Rjo7uXre9g /I6zOtSPMsLWWgznOXURZzuJ9g7Zvp8w7Lu3TeZ5JnH8jvkl9EANOZmO+prLWzO3 6K0ZpwUh2kMo+W8UyA9uyCopqo2qqZVw5mU7fl/Odi7tsq0zG3uu1i8BME3irplp F83O5xc+q7Fvi1f2xlB99mSJ4pK0edQmausClPj4N/cUFLTagdNydS15GIfmjGjY gsDO3ODEDWAof447W+ygojM2VuG7EPlCHQcP2tAngWojUqXE3XsBSHKqDMl3fs4= =w49N -----END PGP SIGNATURE----- --99tYZFKVtXCNe/u4-- -- 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/