From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752260AbbCJM5y (ORCPT ); Tue, 10 Mar 2015 08:57:54 -0400 Received: from seldrel01.sonyericsson.com ([212.209.106.2]:3498 "EHLO seldrel01.sonyericsson.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751016AbbCJM5w (ORCPT ); Tue, 10 Mar 2015 08:57:52 -0400 Date: Tue, 10 Mar 2015 05:57:41 -0700 From: Bjorn Andersson To: Mark Brown CC: Greg Kroah-Hartman , Heiko Stuebner , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] driver core: Make probe deferral more quiet Message-ID: <20150310125741.GS26334@sonymobile.com> References: <1425988549-12310-1-git-send-email-broonie@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1425988549-12310-1-git-send-email-broonie@kernel.org> User-Agent: Mutt/1.5.22 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 10 Mar 04:55 PDT 2015, Mark Brown wrote: > Currently probe deferral prints a message every time a device requests > deferral at info severity (which is displayed by default). This can have > an impact on system boot times with serial consoles and is generally quite > noisy. > > Since subsystems and drivers should already be logging the specific reason > for probe deferral in order to aid users in understanding problems the > messages from the driver core should be redundant lower the severity of > the messages printed, cutting down on the volume of output on the console. > > This does mean that if the drivers and subsystems aren't doing a good job > we get no output on the console by default. Ideally we'd be able to arrange > to print if nothing else printed, though that's a little fun. Even better > would be to come up with a mechanism that explicitly does dependencies so > we don't have to keep polling and erroring. > > Signed-off-by: Mark Brown I like it, much better than the suggestion I made to drop the more informative print out in the regulator framework. Reviewed-by: Bjorn Andersson Regards, Bjorn