On Wednesday 18 May 2016 21:33:01, Takashi Iwai wrote: > On Wed, 18 May 2016 19:20:19 +0200, > > Mark Brown wrote: > > On Wed, May 18, 2016 at 06:57:50PM +0200, Takashi Iwai wrote: > > > Mark Brown wrote: > > > > It's just shifting the problem around... it sounds like for your use > > > > case suppressing the messages until we finish kernel boot would deal > > > > with most of the issue in a far more general fashion. > > > > > > It comes to the question whether this message must be shown verbosely > > > as an error at all. EPROBE_DEFER is usually a mechanism for the > > > delayed probe, and it doesn't indicate an error per se. dev_err() is, > > > OTOH, for real errors that have to be notified to user inevitably. > > > That's why "quiet" boot option still shows it. > > > > We can't tell the difference between something that's delayed and will > > come up later and something that's just never going to work - missing > > or misidentified components has always been a common source of errors > > in ASoC device bringup. > > Yes, but it still means that most of cases are false-positive to show > as "error" message. I think the same way. Of course it is an error if probing never finishes due to some missing configuration/dt entry, but that needs to be checked in dmesg anyway. dev_notice still allows that. > > There's also just the fact that the noise from > > deferred probe is not an ASoC specific thing, we need to tackle this at > > a system level rather than hacking individual cases. > > Such other noises are usually now shown as errors with dev_err() but > with dev_*() with a lower level. > > I guess the patch subject and description are misleading. This > doesn't suppress the messages to be printed. In usual boots without > quiet boot option, there will be no visible change with this patch, > the messages are still shown. It's not shown, however, when booted > with quiet boot option. That's the whole point. > > dev_notice() lowers the log level to somewhat between info and > warning, and it looks like a sensible choice to me. You want me to change the subject to be more clear? Regards, Alexander _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
