[alsa-devel] [PATCH] ASoC: soc-core: Fix probe deferral following prelink failure
From: Jonathan Hunter jonathanh@nvidia.com
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.
Fixes: 78a24e10cd94 ("ASoC: soc-core: clear platform pointers on error")
Signed-off-by: Jonathan Hunter jonathanh@nvidia.com --- sound/soc/soc-core.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 93d316d5bf8e..5a5764dba147 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -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);
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 c342febcde452f817cbd3896dc40953ab17c309d Mon Sep 17 00:00:00 2001
From: Jonathan Hunter jonathanh@nvidia.com 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.
Fixes: 78a24e10cd94 ("ASoC: soc-core: clear platform pointers on error")
Signed-off-by: Jonathan Hunter jonathanh@nvidia.com Signed-off-by: Mark Brown broonie@kernel.org --- sound/soc/soc-core.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 93d316d5bf8e..5a5764dba147 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -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);
Hi Mark,
On 04/03/2019 13:31, Jon Hunter wrote:
From: Jonathan Hunter jonathanh@nvidia.com
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.
Fixes: 78a24e10cd94 ("ASoC: soc-core: clear platform pointers on error")
Signed-off-by: Jonathan Hunter jonathanh@nvidia.com
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
On Mon, Apr 01, 2019 at 01:22:09PM +0100, Jon Hunter wrote:
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.
I don't have this patch at all AFAICT.
On 02/04/2019 05:35, Mark Brown wrote:
On Mon, Apr 01, 2019 at 01:22:09PM +0100, Jon Hunter wrote:
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.
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
On Tue, Apr 02, 2019 at 09:52:15AM +0100, Jon Hunter wrote:
On 02/04/2019 05:35, Mark Brown wrote:
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?
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?
On 02/04/2019 10:19, Mark Brown wrote:
On Tue, Apr 02, 2019 at 09:52:15AM +0100, Jon Hunter wrote:
On 02/04/2019 05:35, Mark Brown wrote:
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?
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
On Tue, Apr 02, 2019 at 10:30:34AM +0100, Jon Hunter wrote:
On 02/04/2019 10:19, Mark Brown wrote:
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.
You can check to see what's in my tree by looking at it directly or at -next.
On 02/04/2019 10:31, Mark Brown wrote:
On Tue, Apr 02, 2019 at 10:30:34AM +0100, Jon Hunter wrote:
On 02/04/2019 10:19, Mark Brown wrote:
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.
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
On Tue, Apr 02, 2019 at 10:44:34AM +0100, Jon Hunter wrote:
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.
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.
participants (2)
-
Jon Hunter -
Mark Brown