All of lore.kernel.org
 help / color / mirror / Atom feed
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: The curse of EPROBE_DEFER
Date: Thu, 9 Aug 2012 18:36:28 +0100	[thread overview]
Message-ID: <20120809173628.GY24328@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20120809163105.GU18957@n2100.arm.linux.org.uk>

On Thu, Aug 09, 2012 at 05:31:05PM +0100, Russell King - ARM Linux wrote:

> Okay, so we have this wonderful new feature called EPROBE_DEFER.  I
> had in the back of my mind while at the meetup in Prague where this
> was discussed that it would cause problems... of the type I'm now
> having, which is:

Well, it's not really an issue in probe deferral per se - it's an issue
in ASoC and something we have to watch out for in other users.

> soc-audio soc-audio: Failed to register card

This is bitrot, should be killed.  It was a bit more useful with our
custom deferred probe but since we routinely fail it's completely
useless now, as you say we need more specific logging.

> repeated many times in the kernel messages, but there's _zero_ clue
> as to why, and unless I enable debugging in sound/soc through a kernel
> rebuild, there's little chance of finding out.

There's also the option of doing a contrast and compare between the card
definition and the lists of registered things in debugfs but that's
obviously not something we should expect the general audience to work
with.

> This is idiotic, and fragile, and completely mad.  If we're going to
> have EPROBE_DEFER at least have the curtesy to your users to say *why*
> you're failing the probe, and *not* at the (by default) invisible debug
> level.  I mean, saying that the probe failed but not saying *why* is
> utterly stupid.

The reason that the log messages are debug level is that back when
nobody though probe deferral would ever be useful people complained
about the log spam from probe deferral and didn't want to know that
anyone might need it.  Obviously this no longer applies - not only do we
now have probe deferral in the core but it's chatty anyway so we may as
well add some diagnostic information on top of it.

Anyway, thanks for noticing this.  I've just upgraded the severity of
all the logs from probe deferral to dev_err(), a patch should show up on
the list and in -next tomorrow or the day after.

      reply	other threads:[~2012-08-09 17:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-09 16:31 The curse of EPROBE_DEFER Russell King - ARM Linux
2012-08-09 17:36 ` 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=20120809173628.GY24328@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.