The curse of EPROBE_DEFER
From: Russell King - ARM Linux <hidden>
Date: 2012-08-09 16:31:05
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.