ASoC: soc-core: Fix probe deferral following prelink failure

From: Jonathan Hunter <[email protected]>

Commit 78a24e10cd94 ("ASoC: soc-core: clear platform pointers on error") re-worked the clean-up of any platform pointers that may have been initialised by the function snd_soc_init_platform(). This commit missed one error path where if any of the prelinks for a soundcard failed to initialise, then these platform pointers would not be cleaned-up. This then prevents the soundcard from being initialised following a probe deferral when any of the soundcard prelinks cannot be found.

Fix this by ensuring that soc_cleanup_platform() is called when initialising the soundcard prelinks fails.

---
 sound/soc/soc-core.c | 1 +
 1 file changed, 1 insertion(+)

index 93d316d5bf8e..5a5764dba147 100644
@@ -2797,6 +2797,7 @@ int snd_soc_register_card(struct snd_soc_card *card)
 
 		ret = soc_init_dai_link(card, link);
 		if (ret) {
+			soc_cleanup_platform(card);
 			dev_err(card->dev, "ASoC: failed to init link %s\n",
 				link->name);
 			mutex_unlock(&client_mutex);

1.9.1

The patch

ASoC: soc-core: Fix probe deferral following prelink failure

has been applied to the asoc tree at

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git

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

From: Jonathan Hunter <[email protected]>
Date: Mon, 4 Mar 2019 13:31:14 +0000
Subject: [PATCH] ASoC: soc-core: Fix probe deferral following prelink failure

Commit 78a24e10cd94 ("ASoC: soc-core: clear platform pointers on error") re-worked the clean-up of any platform pointers that may have been initialised by the function snd_soc_init_platform(). This commit missed one error path where if any of the prelinks for a soundcard failed to initialise, then these platform pointers would not be cleaned-up. This then prevents the soundcard from being initialised following a probe deferral when any of the soundcard prelinks cannot be found.

Fix this by ensuring that soc_cleanup_platform() is called when initialising the soundcard prelinks fails.

---
 sound/soc/soc-core.c | 1 +
 1 file changed, 1 insertion(+)

index 93d316d5bf8e..5a5764dba147 100644
@@ -2797,6 +2797,7 @@ int snd_soc_register_card(struct snd_soc_card *card)
 
 		ret = soc_init_dai_link(card, link);
 		if (ret) {
+			soc_cleanup_platform(card);
 			dev_err(card->dev, "ASoC: failed to init link %s\n",
 				link->name);
 			mutex_unlock(&client_mutex);

2.20.1

Hi Mark,

FYI, I am seeing that the deferral of soundcards failing with v5.1-rc3 because the above has not been merged yet. Just wanted to let you know in case this one was not marked for v5.1.

Cheers
Jon

nvpublic

I don't have this patch at all AFAICT.

That's odd. It is definitely in -next and I did receive an 'applied' email from you [0]. So looks like something went wrong here. Can we get this into v5.1?

Cheers
Jon

[0] https://lkml.org/lkml/2019/3/4/637

nvpublic

Oh, if I've applied that's why I don't have it any more. Indeed it's applied in my 5.1 branch so I don't know what you're expecting here?

Well I still don't see it in the mainline branch and some boards are still failing to register soundcards with v5.1-rc3 because this is missing. So I am wondering what has happened to the change. It seems it has been dropped.

Cheers
Jon

nvpublic

You can check to see what's in my tree by looking at it directly or at -next.

Right I see it in -next. Sorry but what I am asking is if you are planning to send as a fix for v5.1? Maybe you have not sent out the fixes yet for v5.1 and so wanted to check.

Cheers
Jon

nvpublic

It is in my for-5.1 branch so I am intending to send it for v5.1. Like many maintainers I have separate branches in my tree and in -next for things that are intended for the next merge window and things that are intended to be sent sooner, in my case I have both for-linus and for-next branches, plus both topic and numberd for-x.y branches which feed into those.