The curse of EPROBE_DEFER

The curse of EPROBE_DEFER

[Russell King - ARM Linux]

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:

soc-audio soc-audio: ASoC machine CuBox-spdif should use snd_soc_register_card()
soc-audio soc-audio: Failed to register card
platform soc-audio: Driver soc-audio requests probe deferral

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.

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 curse of EPROBE_DEFER

[Mark Brown]

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.