[alsa-devel] [PATCH v2 1/1] ASoC: core: Do not print an actual error when deferring probe
In case there is no DAI (yet), do not print an error, this might happen a lot of times. Print a notice instead.
Signed-off-by: Alexander Stein alexander.stein@systec-electronic.com --- Changes in v2: * Add addional change in soc_bind_aux_dev()
sound/soc/soc-core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index d2e62b15..ce5f835 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1001,7 +1001,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_notice(card->dev, "ASoC: CPU DAI %s not registered\n", dai_link->cpu_dai_name); goto _err_defer; } @@ -1013,7 +1013,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_notice(card->dev, "ASoC: CODEC DAI %s not registered\n", codecs[i].dai_name); goto _err_defer; } @@ -1042,7 +1042,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_notice(card->dev, "ASoC: platform %s not registered\n", dai_link->platform_name); return -EPROBE_DEFER; } @@ -1698,7 +1698,7 @@ static int soc_bind_aux_dev(struct snd_soc_card *card, int num) return 0;
err_defer: - dev_err(card->dev, "ASoC: %s not registered\n", name); + dev_notice(card->dev, "ASoC: %s not registered\n", name); return -EPROBE_DEFER; }
On Wed, 18 May 2016, Alexander Stein wrote:
In case there is no DAI (yet), do not print an error, this might happen a lot of times. Print a notice instead.
Signed-off-by: Alexander Stein alexander.stein@systec-electronic.com
Changes in v2:
- Add addional change in soc_bind_aux_dev()
Acked-by: Ricard Wanderlof ricardw@axis.com
/Ricard
sound/soc/soc-core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index d2e62b15..ce5f835 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1001,7 +1001,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_notice(card->dev, "ASoC: CPU DAI %s not registered\n", dai_link->cpu_dai_name);@@ -1013,7 +1013,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_notice(card->dev, "ASoC: CODEC DAI %s not registered\n", codecs[i].dai_name); goto _err_defer;@@ -1042,7 +1042,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_notice(card->dev, "ASoC: platform %s not registered\n", dai_link->platform_name);@@ -1698,7 +1698,7 @@ static int soc_bind_aux_dev(struct snd_soc_card *card, int num) return 0;
err_defer:
- dev_err(card->dev, "ASoC: %s not registered\n", name);
- dev_notice(card->dev, "ASoC: %s not registered\n", name); return -EPROBE_DEFER;
}
-- 2.7.3
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Wed, May 18, 2016 at 05:07:00PM +0200, Alexander Stein wrote:
In case there is no DAI (yet), do not print an error, this might happen a lot of times. Print a notice instead.
Oh, and the other thing about this which I should have mentioned is that it applies to every single resource acquisition in the kernel - this needs addressing at a global error rather than piecemeal. Raphael was intending to work on avoiding probe deferral in the first place by sorting probe and there were also some proposals to have a helper for printing error messages which would suppress the display of probe deferral errors before the final run at late initcall. Obviously the second mechanism is substantially simpler to implement.
On Wednesday 18 May 2016 16:20:28, Mark Brown wrote:
On Wed, May 18, 2016 at 05:07:00PM +0200, Alexander Stein wrote:
In case there is no DAI (yet), do not print an error, this might happen a lot of times. Print a notice instead.
Oh, and the other thing about this which I should have mentioned is that it applies to every single resource acquisition in the kernel - this needs addressing at a global error rather than piecemeal. Raphael was intending to work on avoiding probe deferral in the first place by sorting probe and there were also some proposals to have a helper for printing error messages which would suppress the display of probe deferral errors before the final run at late initcall. Obviously the second mechanism is substantially simpler to implement.
I remember those patches a bit. But working with late initcall sound to me this has no effect on probe deferral in drivers loaded by modules, no?
Regards, Alexander
On Wed, May 18, 2016 at 05:53:49PM +0200, Alexander Stein wrote:
On Wednesday 18 May 2016 16:20:28, Mark Brown wrote:
Oh, and the other thing about this which I should have mentioned is that it applies to every single resource acquisition in the kernel - this needs addressing at a global error rather than piecemeal. Raphael was intending to work on avoiding probe deferral in the first place by sorting probe and there were also some proposals to have a helper for printing error messages which would suppress the display of probe deferral errors before the final run at late initcall. Obviously the second mechanism is substantially simpler to implement.
I remember those patches a bit. But working with late initcall sound to me this has no effect on probe deferral in drivers loaded by modules, no?
Correct, once you're using modules you're pretty much relying on userspace sorting out the init ordering.
participants (3)
-
Alexander Stein -
Mark Brown -
Ricard Wanderlof