From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932262AbbJSPge (ORCPT ); Mon, 19 Oct 2015 11:36:34 -0400 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:48100 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932072AbbJSPgZ (ORCPT ); Mon, 19 Oct 2015 11:36:25 -0400 Date: Mon, 19 Oct 2015 16:35:49 +0100 From: Russell King - ARM Linux To: Tomeu Vizoso Cc: Mark Brown , Greg Kroah-Hartman , Rob Herring , Michael Turquette , Stephen Boyd , Vinod Koul , Dan Williams , Linus Walleij , Alexandre Courbot , Thierry Reding , David Airlie , Terje =?iso-8859-1?Q?Bergstr=F6m?= , Stephen Warren , Wolfram Sang , Frank Rowand , Grant Likely , Kishon Vijay Abraham I , Sebastian Reichel , Dmitry Eremin-Solenikov , David Woodhouse , Liam Girdwood , Felipe Balbi , Jingoo Han , Lee Jones , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , "linux-kernel@vger.kernel.org" , linux-clk@vger.kernel.org, dmaengine@vger.kernel.org, linux-gpio@vger.kernel.org, "dri-devel@lists.freedesktop.org" , "linux-tegra@vger.kernel.org" , linux-i2c@vger.kernel.org, "devicetree@vger.kernel.org" , "linux-pm@vger.kernel.org" , Linux PWM List , "linux-usb@vger.kernel.org" , linux-fbdev@vger.kernel.org Subject: Re: [GIT PULL] On-demand device probing Message-ID: <20151019153548.GM32532@n2100.arm.linux.org.uk> References: <561E1378.6000906@collabora.com> <20151017065750.GA18607@kroah.com> <20151018192931.GY14956@sirena.org.uk> <20151018193757.GA9147@kroah.com> <20151018195330.GB14956@sirena.org.uk> <20151019131821.GA32532@n2100.arm.linux.org.uk> <20151019143045.GE32532@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 19, 2015 at 05:00:54PM +0200, Tomeu Vizoso wrote: > On 19 October 2015 at 16:30, Russell King - ARM Linux > wrote: > > I typically see one or two, maybe five maximum on the platforms I have > > here, but normally zero. > > Hmm, I have given a look at our lava farm and have seen 2 dozens as > common (with multi_v7). No, because the lava farms tend not to be public. > > What you can do is print those devices which have failed to probe at > > late_initcall() time - possibly augmenting that with reports from > > subsystems showing what resources are not available, but that's only > > a guide, because of the "it might or might not be in a kernel module" > > problem. > > Well, adding those reports would give you a changelog similar to the > one in this series... I'm not sure about that, because what I was thinking of is adding a flag which would be set at late_initcall() time prior to running a final round of deferred device probing. This flag would then be used in a deferred_warn() printk function which would normally be silent, but when this flag is set, it would print the reason for the deferral - and this would replace (or be added) to the subsystems and drivers which return -EPROBE_DEFER. That has the effect of hiding all the deferrals up until just before launching into userspace, which should then acomplish two things - firstly, getting rid of the rather useless deferred messages up to that point, and secondly printing the reason why the remaining deferrals are happening. That should be a small number of new lines plus a one-line change in subsystems and drivers. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.