From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752725AbbCJMIU (ORCPT ); Tue, 10 Mar 2015 08:08:20 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:33770 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752526AbbCJMIS (ORCPT ); Tue, 10 Mar 2015 08:08:18 -0400 Date: Tue, 10 Mar 2015 12:07:50 +0000 From: Mark Brown To: Heiko Stuebner Cc: Philipp Zabel , David Airlie , djkurtz@chromium.org, Yakir Yang , Fabio Estevam , dianders@chromium.org, Andy Yan , Mark Yao , linux-rockchip@lists.infradead.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , linux-arm-kernel@lists.infradead.org Message-ID: <20150310120750.GE28806@sirena.org.uk> References: <1429128.MSqYm0qZ9p@phil> <9261130.uPvufuEFrr@phil> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Wr26kid6E8rFCMyi" Content-Disposition: inline In-Reply-To: <9261130.uPvufuEFrr@phil> X-Cookie: Editing is a rewording activity. 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 1/3] regulator: don't emit errors in {devm_}regulator_bulk_get when defering 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 --Wr26kid6E8rFCMyi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 10, 2015 at 12:22:06AM +0100, Heiko Stuebner wrote: > When {devm_}regulator_get returns -EPROBE_DEFER the driver in question will > try probing again at a later time. So don't spam the log with failure messages > as this is an expected result of probe ordering. > - dev_err(dev, "Failed to get supply '%s': %d\n", > - consumers[i].supply, ret); > + if (ret != -EPROBE_DEFER) > + dev_err(dev, "Failed to get supply '%s': %d\n", > + consumers[i].supply, ret); No, this is not good - you get a nice quiet boot even if the regulator does not appear which means people have no idea why the driver isn't loading. That's not a good user experience, silent error handling is the main problem I see people running into trying to get their systems up and running these days. Really deferred probe is just fundamentally noisy since it's intentionally tolerating errors like this and of course a lot of the noise comes from the deferral messages the core prints. This is also not really connected to the series you're posting it in... --Wr26kid6E8rFCMyi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU/t6WAAoJECTWi3JdVIfQ7eEH/2J2gcg/F7qtu2lU8XD1JRJQ 5LPE2bjm96nmyrH3cge41SicMsemkAakgJN5K18SXigYCW+FPYtBTibwkncSXgJr 3ljSe6Qiuv9LToz5cIKCjxXZMbA06YGlScpbDl7y0BCBqISZCENklZZrKfM2f4+8 B9evGBZGqWN2xFsMZz+ZGIMXx47uL2pVH0b0bzJttAlnk+xdpLLdhHfAjl8Y8sdm npzyJJ6lHV1ipXLjcoPmfy6UXIdftQ5ztc/QU1q5DeSJL8MwVr1/lS4K6MfFcB5B 2QgN+Z/0TH/80KUDIZb5E+XTQ6lrjRiSWlA96BogLdWf5v6esD+O27POMtm7wB0= =4ehk -----END PGP SIGNATURE----- --Wr26kid6E8rFCMyi--