From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752010AbbJRTiE (ORCPT ); Sun, 18 Oct 2015 15:38:04 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:50868 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750699AbbJRTh7 (ORCPT ); Sun, 18 Oct 2015 15:37:59 -0400 Date: Sun, 18 Oct 2015 12:37:57 -0700 From: Greg Kroah-Hartman To: Mark Brown Cc: Tomeu Vizoso , Rob Herring , Russell King , 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@vger.kernel.org, linux-usb@vger.kernel.org, linux-fbdev@vger.kernel.org Subject: Re: [GIT PULL] On-demand device probing Message-ID: <20151018193757.GA9147@kroah.com> References: <561E1378.6000906@collabora.com> <20151017065750.GA18607@kroah.com> <20151018192931.GY14956@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151018192931.GY14956@sirena.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote: > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote: > > > I can't see adding calls like this all over the tree just to solve a > > bus-specific problem, you are adding of_* calls where they aren't > > needed, or wanted, at all. > > This isn't bus specific, I'm not sure what makes you say that? You are making it bus-specific by putting these calls all over the tree in different bus subsystems semi-randomly for all I can determine. > > What is the root-problem of your delay in device probing? I read your > > last patch series and I can't seem to figure out what the issue is that > > this is solving in any "better" way from the existing deferred probing. > > So, I don't actually have any platforms that are especially bothered by > this (at least not for my use cases) so there's a bit of educated > guessing going on here but there's two broad things I'm aware of. > > One is that regardless of the actual performance of the system when > deferred probe goes off it splats errors all over the console which > makes it look like something is going wrong even if everything is fine > in the end. If lots of deferred probing happens then the volume gets > big too. People find this distracting, noisy and ugly - it obscures > actual issues and trains people to ignore errors. I do think this is a > reasonable concern and that it's worth trying to mitigate against > deferral for this reason alone. We don't want to just ignore the errors > and not print anything either since if the resource doesn't appear the > user needs to know what is preventing the driver from instantiating so > they can try to fix it. This has come up many times, I have no objection to just turning that message into a debug message that can be dynamically enabled for those people wanting to debug their systems for boot time issues. Please send a patch to do so. thanks, greg k-h