Nearly every boot with a Lenovo P14s is showing
acp_pdm_mach acp_pdm_mach.0: snd_soc_register_card(acp) failed: -517
This isn't useful to a user, especially as probing will run again.
Use the dev_err_probe helper to hide the deferrerd probing messages.
CC: [email protected]
Signed-off-by: Mario Limonciello <[email protected]>
---
sound/soc/amd/renoir/acp3x-rn.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
v1->v2:
* Adjust return codes
v2->v3:
* Use deferred probing helper
* Rebase on asoc-next/for-5.15
diff --git a/sound/soc/amd/renoir/acp3x-rn.c b/sound/soc/amd/renoir/acp3x-rn.c
index 306134b89a82..5d979a7b77fb 100644
--- a/sound/soc/amd/renoir/acp3x-rn.c
+++ b/sound/soc/amd/renoir/acp3x-rn.c
@@ -54,10 +54,9 @@ static int acp_probe(struct platform_device *pdev)
snd_soc_card_set_drvdata(card, machine);
ret = devm_snd_soc_register_card(&pdev->dev, card);
if (ret) {
- dev_err(&pdev->dev,
- "snd_soc_register_card(%s) failed: %d\n",
- acp_card.name, ret);
- return ret;
+ return dev_err_probe(&pdev->dev, ret,
+ "snd_soc_register_card(%s) failed\n",
+ card->name);
}
return 0;
}
--
2.25.1
Replace the pattern of check for err to match -EPROBE_DEFER and only
output errors to use the dev_err_probe helper instead.
Signed-off-by: Mario Limonciello <[email protected]>
---
sound/soc/amd/acp-da7219-max98357a.c | 12 +++---------
sound/soc/amd/acp3x-rt5682-max9836.c | 14 ++++----------
2 files changed, 7 insertions(+), 19 deletions(-)
diff --git a/sound/soc/amd/acp-da7219-max98357a.c b/sound/soc/amd/acp-da7219-max98357a.c
index 84e3906abd4f..c130eeb07cdf 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -746,15 +746,9 @@ static int cz_probe(struct platform_device *pdev)
snd_soc_card_set_drvdata(card, machine);
ret = devm_snd_soc_register_card(&pdev->dev, card);
if (ret) {
- if (ret != -EPROBE_DEFER)
- dev_err(&pdev->dev,
- "devm_snd_soc_register_card(%s) failed: %d\n",
- card->name, ret);
- else
- dev_dbg(&pdev->dev,
- "devm_snd_soc_register_card(%s) probe deferred: %d\n",
- card->name, ret);
- return ret;
+ return dev_err_probe(&pdev->dev, ret,
+ "devm_snd_soc_register_card(%s) failed\n",
+ card->name);
}
bt_uart_enable = !device_property_read_bool(&pdev->dev,
"bt-pad-enable");
diff --git a/sound/soc/amd/acp3x-rt5682-max9836.c b/sound/soc/amd/acp3x-rt5682-max9836.c
index d9980aba2910..e561464f7d60 100644
--- a/sound/soc/amd/acp3x-rt5682-max9836.c
+++ b/sound/soc/amd/acp3x-rt5682-max9836.c
@@ -512,17 +512,11 @@ static int acp3x_probe(struct platform_device *pdev)
ret = devm_snd_soc_register_card(&pdev->dev, card);
if (ret) {
- if (ret != -EPROBE_DEFER)
- dev_err(&pdev->dev,
- "devm_snd_soc_register_card(%s) failed: %d\n",
- card->name, ret);
- else
- dev_dbg(&pdev->dev,
- "devm_snd_soc_register_card(%s) probe deferred: %d\n",
- card->name, ret);
+ return dev_err_probe(&pdev->dev, ret,
+ "devm_snd_soc_register_card(%s) failed\n",
+ card->name);
}
-
- return ret;
+ return 0;
}
static const struct acpi_device_id acp3x_audio_acpi_match[] = {
--
2.25.1
On Thu, Jul 22, 2021 at 08:27:27AM -0500, Mario Limonciello wrote:
> This isn't useful to a user, especially as probing will run again.
> Use the dev_err_probe helper to hide the deferrerd probing messages.
The reason we have these error messages is that they are very useful to
users if they ever find that the device isn't instantiating due to some
missing dependency or something that leaves it stuck in probe deferral,
they give some hint as to what might be wrong.
[Public]
>
> On Thu, Jul 22, 2021 at 08:27:27AM -0500, Mario Limonciello wrote:
>
> > This isn't useful to a user, especially as probing will run again.
> > Use the dev_err_probe helper to hide the deferrerd probing messages.
>
> The reason we have these error messages is that they are very useful to
> users if they ever find that the device isn't instantiating due to some
> missing dependency or something that leaves it stuck in probe deferral,
> they give some hint as to what might be wrong.
Right, but they should be at debugging level, if someone has a problem they
turn on dynamic debugging for the module and then can see these messages.
To reinforce my point - that's what the drivers in patch 2/2 do already (but are
being moved to this helper) and furthermore this was in result to some reports
looking at this message in bootup thinking it was a problem but it being a red
herring.
On Fri, Jul 23, 2021 at 01:04:51PM +0000, Limonciello, Mario wrote:
> > On Thu, Jul 22, 2021 at 08:27:27AM -0500, Mario Limonciello wrote:
> > > This isn't useful to a user, especially as probing will run again.
> > > Use the dev_err_probe helper to hide the deferrerd probing messages.
> > The reason we have these error messages is that they are very useful to
> > users if they ever find that the device isn't instantiating due to some
> > missing dependency or something that leaves it stuck in probe deferral,
> > they give some hint as to what might be wrong.
> Right, but they should be at debugging level, if someone has a problem they
> turn on dynamic debugging for the module and then can see these messages.
Your commit message says that reporting the error isn't useful, I am
flagging that it is useful to have the messages be available to people.
On Thu, 22 Jul 2021 08:27:27 -0500, Mario Limonciello wrote:
> Nearly every boot with a Lenovo P14s is showing
> acp_pdm_mach acp_pdm_mach.0: snd_soc_register_card(acp) failed: -517
>
> This isn't useful to a user, especially as probing will run again.
> Use the dev_err_probe helper to hide the deferrerd probing messages.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: amd: Don't show messages about deferred probing by default
commit: af7dc6f194a866cb3e991ef5248ffdeb3ef5c46a
[2/2] ASoC: amd: Use dev_probe_err helper
commit: 718693352d8bcea65276615f4f8c8d531246b644
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark