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.
Fixes: 78a24e10cd94 ("ASoC: soc-core: clear platform pointers on error")
Signed-off-by: Jonathan Hunter <[email protected]>
---
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);
--
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 c342febcde452f817cbd3896dc40953ab17c309d Mon Sep 17 00:00:00 2001
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.
Fixes: 78a24e10cd94 ("ASoC: soc-core: clear platform pointers on error")
Signed-off-by: Jonathan Hunter <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
---
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);
--
2.20.1
Hi Mark,
On 04/03/2019 13:31, Jon Hunter wrote:
> 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.
>
> Fixes: 78a24e10cd94 ("ASoC: soc-core: clear platform pointers on error")
>
> Signed-off-by: Jonathan Hunter <[email protected]>
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
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 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
--
nvpublic
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
--
nvpublic
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
--
nvpublic
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.