| Message ID | 20161109140036.GB20859@localhost.localdomain (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Nov 09, 2016 at 02:36:42PM +0000, Mark Brown wrote: > On Wed, Nov 09, 2016 at 03:00:36PM +0100, Ladislav Michl wrote: > > There is no point having these complaints to be dev_err as > > they are just adding noise to bootlog. > > No, errors are errors and not displaying them just makes it harder for > people to debug things. If you don't want to see errors just change > your system configuratiion to hide them. For sure I want to see all errors, but this is not hardware error nor kernel misconfiguration, so showing it to the user is a bit pointless. I'm using quiet boot on production systems and technicians are told to report all errors they see... This one pops up and has nothing to do with errorneous behaviour. > If you don't like deferred probing please contribute to the efforts > to order probing. I just tried to make it consistend to other subsystems where patches to silence deferred probing warnings are accepted... > Please use subject lines matching the style for the subsystem. This > makes it easier for people to identify relevant patches. I wasn't aware of it, sorry. Will fix it next time. Best regards, ladis
On Wed, Nov 09, 2016 at 03:22:09PM +0000, Mark Brown wrote: > On Wed, Nov 09, 2016 at 04:14:26PM +0100, Ladislav Michl wrote: > > On Wed, Nov 09, 2016 at 02:36:42PM +0000, Mark Brown wrote: > > > > No, errors are errors and not displaying them just makes it harder for > > > people to debug things. If you don't want to see errors just change > > > your system configuratiion to hide them. > > > For sure I want to see all errors, but this is not hardware error nor > > kernel misconfiguration, so showing it to the user is a bit pointless. > > How do we know that it's not a kernel misconfiguration? It's common for > people to not build some of the component drivers they need. Is what you described really a misconfiguration? Enabling debug when something does not work seems obvious thing to do, but okay, perhaps anything bellow error level would make me happy enough. > > > If you don't like deferred probing please contribute to the efforts > > > to order probing. As a side note, which efforts are you reffering to here? > > I just tried to make it consistend to other subsystems where patches to > > silence deferred probing warnings are accepted... > > Which subsystems are these? We should look at fixing them... tty and usb for example. I do not consider wise to looking at them until this very subsystem gets fixed first to not distract ourselves ;-) (Also I have admit, that accepted patches hide error message on deferred probe only, but above occurs _also_ on deferred probe and yes, it would be nice to have that fixed) Best regards, ladis
On Wed, Nov 09, 2016 at 05:36:58PM +0100, Ladislav Michl wrote: > On Wed, Nov 09, 2016 at 03:22:09PM +0000, Mark Brown wrote: > > How do we know that it's not a kernel misconfiguration? It's common for > > people to not build some of the component drivers they need. > Is what you described really a misconfiguration? Enabling debug when > something does not work seems obvious thing to do, but okay, perhaps > anything bellow error level would make me happy enough. Yes, it's something that's really common when people configure their own kernels. > > > > If you don't like deferred probing please contribute to the efforts > > > > to order probing. > As a side note, which efforts are you reffering to here? Things like Raphael's device dependencies work. > > > I just tried to make it consistend to other subsystems where patches to > > > silence deferred probing warnings are accepted... > > Which subsystems are these? We should look at fixing them... > tty and usb for example. I do not consider wise to looking at them until > this very subsystem gets fixed first to not distract ourselves ;-) > (Also I have admit, that accepted patches hide error message on deferred > probe only, but above occurs _also_ on deferred probe and yes, it would be > nice to have that fixed) This really does make it harder to figure out what's going on when the dependency is actually missing - it transforms things into a silent failure.
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index c0bbcd9..8a6ec52 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1013,7 +1013,7 @@ static int soc_bind_dai_link(struct snd_soc_card *card, cpu_dai_component.dai_name = dai_link->cpu_dai_name; rtd->cpu_dai = snd_soc_find_dai(&cpu_dai_component); if (!rtd->cpu_dai) { - dev_err(card->dev, "ASoC: CPU DAI %s not registered\n", + dev_dbg(card->dev, "ASoC: CPU DAI %s not registered\n", dai_link->cpu_dai_name); goto _err_defer; } @@ -1025,7 +1025,7 @@ static int soc_bind_dai_link(struct snd_soc_card *card, for (i = 0; i < rtd->num_codecs; i++) { codec_dais[i] = snd_soc_find_dai(&codecs[i]); if (!codec_dais[i]) { - dev_err(card->dev, "ASoC: CODEC DAI %s not registered\n", + dev_dbg(card->dev, "ASoC: CODEC DAI %s not registered\n", codecs[i].dai_name); goto _err_defer; } @@ -1054,7 +1054,7 @@ static int soc_bind_dai_link(struct snd_soc_card *card, rtd->platform = platform; } if (!rtd->platform) { - dev_err(card->dev, "ASoC: platform %s not registered\n", + dev_dbg(card->dev, "ASoC: platform %s not registered\n", dai_link->platform_name); goto _err_defer; }
There is no point having these complaints to be dev_err as they are just adding noise to bootlog. Signed-off-by: Ladislav Michl <ladis@linux-mips.org> --- sound/soc/soc-core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)