From: Mark Brown <broonie@kernel.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrzej Hajda <a.hajda@samsung.com>,
Jernej Skrabec <jernej.skrabec@siol.net>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
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>,
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 20:06:35 +0100 [thread overview]
Message-ID: <20200730190634.GI5055@sirena.org.uk> (raw)
In-Reply-To: <CAKdAkRSaF3q1MJ7mteD-4C4O58LL4FP6xpTovVOdu0v2VD=sAQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]
On Thu, Jul 30, 2020 at 11:45:25AM -0700, Dmitry Torokhov wrote:
> On Thu, Jul 30, 2020 at 11:16 AM Mark Brown <broonie@kernel.org> wrote:
> > 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
*Normally* but not always - some of the older bindings do love their
arrays of phandles (or mixes of numbers and phandles!) unfortunately.
> 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.
Not really, one of the big targets is people doing system integration
who are writing a DT or possibly producing a highly tuned kernel config.
They needn't have a strong familiarity with the driver, they're often
just picking it up off the shelf.
> > 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.
The push for this is that there's already people going around modifying
drivers whatever happens but at present they're mainly trying to delete
diagnostics which isn't wonderful. Besides, even if we push things into
the subsystems they'd want to use this interface or something quite like
it anyway - it's more a question of if we go quickly add some users to
subsystems isn't it? I'm not against that.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2020-07-30 19:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200713144331eucas1p25911c4ffa9315f632d8f6dd833588981@eucas1p2.samsung.com>
2020-07-13 14:43 ` [PATCH v9 0/4] driver core: add probe error check helper Andrzej Hajda
2020-07-13 14:43 ` [PATCH v9 1/4] driver core: add device probe log helper Andrzej Hajda
2020-07-13 14:58 ` Andy Shevchenko
2020-07-13 14:43 ` [PATCH v9 2/4] driver core: add deferring probe reason to devices_deferred property Andrzej Hajda
2020-07-13 14:43 ` [PATCH v9 3/4] drm/bridge/sii8620: fix resource acquisition error handling Andrzej Hajda
2020-07-13 14:43 ` [PATCH v9 4/4] drm/bridge: lvds-codec: simplify " Andrzej Hajda
2020-07-28 15:05 ` [PATCH v9 0/4] driver core: add probe error check helper Andrzej Hajda
2020-07-30 7:08 ` Greg Kroah-Hartman
2020-07-30 16:18 ` Dmitry Torokhov
2020-07-30 16:48 ` Mark Brown
2020-07-30 17:46 ` Dmitry Torokhov
2020-07-30 18:16 ` Mark Brown
2020-07-30 18:45 ` Dmitry Torokhov
2020-07-30 19:06 ` Mark Brown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200730190634.GI5055@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=andy.shevchenko@gmail.com \
--cc=b.zolnierkie@samsung.com \
--cc=dmitry.torokhov@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=jernej.skrabec@siol.net \
--cc=jonas@kwiboo.se \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=narmstrong@baylibre.com \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox