Re: [PATCH v9 0/4] driver core: add probe error check helper

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jonas Karlman <jonas@kwiboo.se>,
	lkml <linux-kernel@vger.kernel.org>,
	"open list:DRM DRIVERS" <dri-devel@lists.freedesktop.org>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v9 0/4] driver core: add probe error check helper
Date: Thu, 30 Jul 2020 11:45:25 -0700	[thread overview]
Message-ID: <CAKdAkRSaF3q1MJ7mteD-4C4O58LL4FP6xpTovVOdu0v2VD=sAQ@mail.gmail.com> (raw)
In-Reply-To: <20200730181639.GG5055@sirena.org.uk>

On Thu, Jul 30, 2020 at 11:16 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Jul 30, 2020 at 10:46:31AM -0700, Dmitry Torokhov wrote:
> > On Thu, Jul 30, 2020 at 9:49 AM Mark Brown <broonie@kernel.org> wrote:
>
> > > The error messages are frequently in the caller rather than the
> > > frameworks, it's often helpful for the comprehensibility of the error
> > > messages especially in cases where things may be legitimately absent.
>
> > Not for deferral. All you need to know in this case is:
>
> > "device A is attempting to request resource B which is not ready yet"
>
> > There is nothing to handle on the caller part except to float the error up.
>
> You can sometimes do a better job of explaining what the resource you
> were looking for was,

I think it is true for very esoteric cases. I.e. your driver uses 2
interrupt lines, or something like that. For GPIO, regulators, and
clocks we normally have a name/connection ID that provides enough of
context. We need to remember, the error messages really only make
total sense to a person familiar with the driver to begin with, not
for a random person looking at the log.

> and of course you still need diagnostics in the
> non-deferral case.  Whatever happens we'll need a lot of per-driver
> churn, either removing existing diagnostics that get factored into cores
> or updating to use this new API.

The point is if you push it into core you'll get the benefit of
notifying about the deferral (and can "attach" deferral reason to a
device) without changing drivers at all. You can clean them up later
if you want, or decide that additional logging in error paths does not
hurt. This new API does not do you any good unless you convert
drivers, and you need to convert the majority of them to be able to
rely on the deferral diagnostic that is being added.

Thanks.

-- 
Dmitry

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel