From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934697AbcCPLh1 (ORCPT ); Wed, 16 Mar 2016 07:37:27 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:36288 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753596AbcCPLhY (ORCPT ); Wed, 16 Mar 2016 07:37:24 -0400 Date: Wed, 16 Mar 2016 11:37:15 +0000 From: Mark Brown To: Javier Martinez Canillas Cc: linux-kernel@vger.kernel.org, Liam Girdwood Message-ID: <20160316113715.GV2566@sirena.org.uk> References: <1458074114-8088-1-git-send-email-javier@osg.samsung.com> <20160316095946.GR2566@sirena.org.uk> <56E9414E.3030609@osg.samsung.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JNs4m2JFMNhdiK2v" Content-Disposition: inline In-Reply-To: <56E9414E.3030609@osg.samsung.com> X-Cookie: Walk softly and carry a megawatt laser. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH] regulator: Don't print error in devm_regulator_bulk_get() on -EPROBE_DEFER 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 --JNs4m2JFMNhdiK2v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Mar 16, 2016 at 08:19:42AM -0300, Javier Martinez Canillas wrote: > On 03/16/2016 06:59 AM, Mark Brown wrote: > > On Tue, Mar 15, 2016 at 05:35:14PM -0300, Javier Martinez Canillas wrote: > > We've been through this repeatedly - this is the case for all probe > > deferrals and if we just don't print the errors at all then people won't > > be able to tell if they've got a missing dependency. We need people to > I wonder if we can use a dev_dbg() then so it will be printed at debug level. > That way users can have that info if they want but not pollute the boot log. No, that has exactly the same problems. > Basically I want to get rid of things like this: > [ 1.438422] exynos-hdmi 14530000.hdmi: Failed to get supply 'vdd': -517 > [ 1.443638] [drm:hdmi_probe] *ERROR* failed to get regulators > [ 1.449326] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed > The HDMI driver probed correctly but looking at the log it seems that things > failed so can mislead users not familiar with the probe deferral mechanism. So fix probe deferral. Don't go through the entire kernel hacking in bodges everywhere, if we have to hack the error handling for almost all resource acquisition errors during probe that's obviously not sensible. > > work on things like allowing the kernel to make use of the dependency > > information it has to order probes more sensibly. > Agreed, I've seen Tomeu's patches and the following discussions. Raphael was proposing something a bit different there. > > Raphael had some ideas he was talking about at Kernel Summit for this, > > Russell King also proposed just suppressing the errors until we're at > > the last deferred probe run at the end of init. > Suppressing errors is a nice idea but will again lead to false positives > when the drivers are built as a module AFAICT. It's not a fix, it's just a 90% masking of the problem that does everything in one place rather than being lots of individual changes. Modules are always going to be problematic for this and in any case the thing there is that we need similar enhancements in the userspace utilities. --JNs4m2JFMNhdiK2v Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW6UVqAAoJECTWi3JdVIfQdAEH/1zZxs2IYSET+ki/crA5Bv5h yJ/WyZx3vEwfSpncuJ74FPfCREwBxqM2l6dT5DZrlYyIGK1G9bSF4u5uwDFFYIJp H7JOoMEDlo4pjoPz6Yu5d+OcG9NSvBz5McvRU5jZDwyMn1t4evozZWmr41NMw2DN 5BZz6iSanSh64nmpIWwi3WRoUTjmiLo5bEZ685n4I8hafXjGV2zOeR5bLjbKUwdi 1uUDI3CLCCyP7L7Vbk7GfPVE6df8FqSW+xzUFtfKcQB9cG89YRj99bmSjfp5u/Df s/Dg0QFmgJiKMHaX/XE//0e9dPhLZgJAgIZVjBBpgzcIsU0O104UJIx48VGf6ig= =3RLS -----END PGP SIGNATURE----- --JNs4m2JFMNhdiK2v--