From: Charles Keepax <ckeepax@opensource.cirrus.com>
[ Upstream commit 8dd26dff00c0636b1d8621acaeef3f6f3a39dd77 ]
DPCM uses snd_soc_dapm_dai_get_connected_widgets to build a
list of the widgets connected to a specific front end DAI so it
can search through this list for available back end DAIs. The
custom_stop_condition was added to is_connected_ep to facilitate this
list not containing more widgets than is necessary. Doing so both
speeds up the DPCM handling as less widgets need to be searched and
avoids issues with CODEC to CODEC links as these would be confused
with back end DAIs if they appeared in the list of available widgets.
custom_stop_condition was implemented by aborting the graph walk
when the condition is triggered, however there is an issue with this
approach. Whilst walking the graph is_connected_ep should update the
endpoints cache on each widget, if the walk is aborted the number
of attached end points is unknown for that sub-graph. When the stop
condition triggered, the original patch ignored the triggering widget
and returned zero connected end points; a later patch updated this
to set the triggering widget's cache to 1 and return that. Both of
these approaches result in inaccurate values being stored in various
end point caches as the values propagate back through the graph,
which can result in later issues with widgets powering/not powering
unexpectedly.
As the original goal was to reduce the size of the widget list passed
to the DPCM code, the simplest solution is to limit the functionality
of the custom_stop_condition to the widget list. This means the rest
of the graph will still be processed resulting in correct end point
caches, but only widgets up to the stop condition will be added to the
returned widget list.
Fixes: 6742064aef7f ("ASoC: dapm: support user-defined stop condition in dai_get_connected_widgets")
Fixes: 5fdd022c2026 ("ASoC: dpcm: play nice with CODEC<->CODEC links")
Fixes: 09464974eaa8 ("ASoC: dapm: Fix to return correct path list in is_connected_ep.")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20190718084333.15598-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/soc-dapm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index c91df5a9c8406..835ce1ff188d9 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -1156,8 +1156,8 @@ static __always_inline int is_connected_ep(struct snd_soc_dapm_widget *widget,
list_add_tail(&widget->work_list, list);
if (custom_stop_condition && custom_stop_condition(widget, dir)) {
- widget->endpoints[dir] = 1;
- return widget->endpoints[dir];
+ list = NULL;
+ custom_stop_condition = NULL;
}
if ((widget->is_ep & SND_SOC_DAPM_DIR_TO_EP(dir)) && widget->connected) {
@@ -1194,8 +1194,8 @@ static __always_inline int is_connected_ep(struct snd_soc_dapm_widget *widget,
*
* Optionally, can be supplied with a function acting as a stopping condition.
* This function takes the dapm widget currently being examined and the walk
- * direction as an arguments, it should return true if the walk should be
- * stopped and false otherwise.
+ * direction as an arguments, it should return true if widgets from that point
+ * in the graph onwards should not be added to the widget list.
*/
static int is_connected_output_ep(struct snd_soc_dapm_widget *widget,
struct list_head *list,
--
2.20.1

On Wed, Aug 14, 2019 at 10:20:52AM +0100, Mark Brown wrote:
>On Tue, Aug 13, 2019 at 10:09:06PM -0400, Sasha Levin wrote:
>> From: Charles Keepax <ckeepax@opensource.cirrus.com>
>>
>> [ Upstream commit 8dd26dff00c0636b1d8621acaeef3f6f3a39dd77 ]
>>
>> DPCM uses snd_soc_dapm_dai_get_connected_widgets to build a
>> list of the widgets connected to a specific front end DAI so it
>> can search through this list for available back end DAIs. The
>
>The DPCM code and its users are rather fragile, if nobody noticed a
>problem I'd worry about causing some other problem to manifest by
>disturbing things.
Doesn't this patch imply that someone noticed it?
And if not, it'll just break when folks update their kernel...
If it creates other problems we should address them now rather than
later.
--
Thanks,
Sasha

On Wed, Aug 14, 2019 at 10:22:13AM +0100, Mark Brown wrote:
>On Tue, Aug 13, 2019 at 10:09:24PM -0400, Sasha Levin wrote:
>> From: Ricard Wanderlof <ricard.wanderlof@axis.com>
>>
>> [ Upstream commit 40aa5383e393d72f6aa3943a4e7b1aae25a1e43b ]
>>
>> If the DAI format setup fails, there is no valid communication format
>> between CPU and CODEC, so fail card instantiation, rather than continue
>> with a card that will most likely not function properly.
>
>This is another one where if nobody noticed a problem already and things
>just happened to be working this might break things, it's vanishingly
>unlikely to fix anything that was broken.
Same as the other patch: this patch suggests it fixes a real bug, and if
this patch is broken let's fix it.
--
Thanks,
Sasha

On Wed, Aug 14, 2019 at 09:36:08AM +0200, Greg Kroah-Hartman wrote:
>On Tue, Aug 13, 2019 at 10:09:51PM -0400, Sasha Levin wrote:
>This one needs a bit more time to "soak" in the -rc releases before I
>want to apply it to the stable release. So if you could drop it from
>all of your autosel queues, that would be great.
>
>I'll queue it up in a few weeks if all goes well with it.
I've dropped it and will ignore it, thanks.
--
Thanks,
Sasha

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]
On Sun, Aug 25, 2019 at 09:35:15PM -0400, Sasha Levin wrote:
> On Wed, Aug 14, 2019 at 10:22:13AM +0100, Mark Brown wrote:
> > > If the DAI format setup fails, there is no valid communication format
> > > between CPU and CODEC, so fail card instantiation, rather than continue
> > > with a card that will most likely not function properly.
> > This is another one where if nobody noticed a problem already and things
> > just happened to be working this might break things, it's vanishingly
> > unlikely to fix anything that was broken.
> Same as the other patch: this patch suggests it fixes a real bug, and if
> this patch is broken let's fix it.
If anyone ran into this on the older kernel and fixed or worked
around it locally there's a reasonable chance this will then
break what they're doing. The patch itself is perfectly fine but
that doesn't mean the rest of the changes it's being backported
into are also fine.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

On Tue, Aug 27, 2019 at 12:00:14PM +0100, Mark Brown wrote:
>On Sun, Aug 25, 2019 at 09:35:15PM -0400, Sasha Levin wrote:
>> On Wed, Aug 14, 2019 at 10:22:13AM +0100, Mark Brown wrote:
>
>> > > If the DAI format setup fails, there is no valid communication format
>> > > between CPU and CODEC, so fail card instantiation, rather than continue
>> > > with a card that will most likely not function properly.
>
>> > This is another one where if nobody noticed a problem already and things
>> > just happened to be working this might break things, it's vanishingly
>> > unlikely to fix anything that was broken.
>
>> Same as the other patch: this patch suggests it fixes a real bug, and if
>> this patch is broken let's fix it.
>
>If anyone ran into this on the older kernel and fixed or worked
>around it locally there's a reasonable chance this will then
>break what they're doing. The patch itself is perfectly fine but
But there's not much we can do here. We can't hold off on fixing
breakage such as this because existing users have workarounds for this.
Are we breaking kernel ABI with this patch then?
And what about new users? We'll let them get hit by the issue and
develop their own workarounds?
>that doesn't mean the rest of the changes it's being backported
>into are also fine.
This is fair, and we can always hold off on patches if you want more
time for them to be tested/reviewed. Is it the case here?
--
Thanks,
Sasha

On Wed, 28 Aug 2019, Sasha Levin wrote:
> On Tue, Aug 27, 2019 at 12:00:14PM +0100, Mark Brown wrote:
> > On Sun, Aug 25, 2019 at 09:35:15PM -0400, Sasha Levin wrote:
> > > On Wed, Aug 14, 2019 at 10:22:13AM +0100, Mark Brown wrote:
> >
> > > > > If the DAI format setup fails, there is no valid communication format
> > > > > between CPU and CODEC, so fail card instantiation, rather than
> > > continue
> > > > > with a card that will most likely not function properly.
> >
> > > > This is another one where if nobody noticed a problem already and things
> > > > just happened to be working this might break things, it's vanishingly
> > > > unlikely to fix anything that was broken.
> >
> > > Same as the other patch: this patch suggests it fixes a real bug, and if
> > > this patch is broken let's fix it.
> >
> > If anyone ran into this on the older kernel and fixed or worked
> > around it locally there's a reasonable chance this will then
> > break what they're doing. The patch itself is perfectly fine but
>
> But there's not much we can do here. We can't hold off on fixing
> breakage such as this because existing users have workarounds for this.
> Are we breaking kernel ABI with this patch then?
>
> And what about new users? We'll let them get hit by the issue and
> develop their own workarounds?
My $0.02 here: In my specific case, we noticed the problem because there
was an unexpected left shift in the captured audio data, since the codec
and CPU DAIs were using different formats when the DAI format was not
explicitly set. The fix for that was to add
simple-audio-card,format= "i2s";
to the devicetree audio card section which of course should have been
there all the time. The fact that the kernel failed halt the
initialization of the audio card lengthened the debug time, but did not
provoke me to attempt a workaround, since the information (the error
printout from the ALSA framework when an invalid daifmt setting was made)
was actually right there in the kernel log.
Possibly there might be other usecases, but in our case, if the kernel had
stopped the audio initialization it would then have been more obvious
where to start looking.
/Ricard
--
Ricard Wolf Wanderlof ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30

[-- Attachment #1: Type: text/plain, Size: 2807 bytes --]
On Wed, Aug 28, 2019 at 09:07:17AM +0200, Ricard Wanderlof wrote:
> On Wed, 28 Aug 2019, Sasha Levin wrote:
> > On Tue, Aug 27, 2019 at 12:00:14PM +0100, Mark Brown wrote:
> > > If anyone ran into this on the older kernel and fixed or worked
> > > around it locally there's a reasonable chance this will then
> > > break what they're doing. The patch itself is perfectly fine but
I should also have added that there's also the potential that things are
just working as they are and that detecting errors will cause new
failures.
> > But there's not much we can do here. We can't hold off on fixing
> > breakage such as this because existing users have workarounds for this.
If people are running into problems here then they just don't have
working audio; if they're shipping with that presumably they either
don't mind about it or have done something to fix it. Either way this
patch won't by itself give anyone working audio that didn't have it
before.
> > Are we breaking kernel ABI with this patch then?
> > And what about new users? We'll let them get hit by the issue and
> > develop their own workarounds?
Hopefully we don't have too many new users adopting the older stables
you want to backport to... in any case this patch just makes the error
reporting more forceful, it won't actually fix the issue it's reporting.
> My $0.02 here: In my specific case, we noticed the problem because there
> was an unexpected left shift in the captured audio data, since the codec
> and CPU DAIs were using different formats when the DAI format was not
> explicitly set. The fix for that was to add
> simple-audio-card,format= "i2s";
> to the devicetree audio card section which of course should have been
> there all the time. The fact that the kernel failed halt the
> initialization of the audio card lengthened the debug time, but did not
> provoke me to attempt a workaround, since the information (the error
> printout from the ALSA framework when an invalid daifmt setting was made)
> was actually right there in the kernel log.
> Possibly there might be other usecases, but in our case, if the kernel had
> stopped the audio initialization it would then have been more obvious
> where to start looking.
Right, returning the error makes things more obvious for system
integrators so it's a good change to have. On the other hand there's
potential breakage if for example the hardware happens to default to the
correct format or an error is detected after enough configuration has
been done to the hardware to make it function well enough. In that case
we'll start returning an error, failing to initialize the card and the
system will loose audio.
Basically this patch won't make anything work that didn't work before.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

> > On Tue, Aug 27, 2019 at 12:00:14PM +0100, Mark Brown wrote:
> > > On Sun, Aug 25, 2019 at 09:35:15PM -0400, Sasha Levin wrote:
> > > > On Wed, Aug 14, 2019 at 10:22:13AM +0100, Mark Brown wrote:
> > >
> > > > > > If the DAI format setup fails, there is no valid communication format
> > > > > > between CPU and CODEC, so fail card instantiation, rather than
> > > > continue
> > > > > > with a card that will most likely not function properly.
> > >
> > > > > This is another one where if nobody noticed a problem already and things
> > > > > just happened to be working this might break things, it's vanishingly
> > > > > unlikely to fix anything that was broken.
> > >
> > > > Same as the other patch: this patch suggests it fixes a real bug, and if
> > > > this patch is broken let's fix it.
> > >
> > > If anyone ran into this on the older kernel and fixed or worked
> > > around it locally there's a reasonable chance this will then
> > > break what they're doing. The patch itself is perfectly fine but
(Sorry about the mangled subject line, I'd accidentally deleted the
original message from my inbox.)
I'm a bit bewildered here. As the author of the original patch I'm of
course biased, and I can certainly understand the patch being dropped from
existing release branches, since as Mark correctly states, it does not fix
any broken behavior and might even break things that happen to work by
chance.
But is this being dropped from the master branch as well? To me it makes
the kernel behave in an inconsistent way, first reporting a failure to
instantiate a specific sound card in the kernel log, but then seemingly
bringing it up anyway.
/Ricard
--
Ricard Wolf Wanderlof ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
On Fri, Sep 06, 2019 at 10:40:01AM +0200, Ricard Wanderlof wrote:
> But is this being dropped from the master branch as well? To me it makes
> the kernel behave in an inconsistent way, first reporting a failure to
> instantiate a specific sound card in the kernel log, but then seemingly
> bringing it up anyway.
No, this is absolutely a good and positive change to have in
master and I'm not suggesting that we should drop it there -
sorry if I sounded like that. I just want to be conservative for
stable so that we don't have anyone updating their stable kernel
and having their audio blow up on them, we don't want to do
anything that'd discourage people from taking stable updates and
hence missing out on security or critical stability updates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

On Fri, Sep 06, 2019 at 11:58:24AM +0100, Mark Brown wrote:
>On Fri, Sep 06, 2019 at 10:40:01AM +0200, Ricard Wanderlof wrote:
>
>> But is this being dropped from the master branch as well? To me it makes
>> the kernel behave in an inconsistent way, first reporting a failure to
>> instantiate a specific sound card in the kernel log, but then seemingly
>> bringing it up anyway.
>
>No, this is absolutely a good and positive change to have in
>master and I'm not suggesting that we should drop it there -
>sorry if I sounded like that. I just want to be conservative for
>stable so that we don't have anyone updating their stable kernel
>and having their audio blow up on them, we don't want to do
>anything that'd discourage people from taking stable updates and
>hence missing out on security or critical stability updates.
Hi Mark,
I'm sorry for not dropping this to begin with: I saw your nack and the
patch ended up still being released because of my fuck up rather than
me purposefuly ignoring your ack, sorry.
However, I'd like to say that I don't agree with it. I understand your
reasoning about keeping the stable trees conservative, but I feel that
going to the extreme with it will just encourage folks to not upgrade
between major versions.
I'd like to think that upgrading major versions should be the same as
upgrading minor ones (because numbers don't matter here). If that's not
the case, let's fix it!
--
Thanks,
Sasha

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]
On Fri, Sep 06, 2019 at 02:38:24PM -0400, Sasha Levin wrote:
> However, I'd like to say that I don't agree with it. I understand your
> reasoning about keeping the stable trees conservative, but I feel that
> going to the extreme with it will just encourage folks to not upgrade
> between major versions.
This is a case where the change can't possibly make anything work
in itself, it can only break things and help with debugging. If
people are sitting on stable hopefully they're not still
debugging their systems. I don't understand why you are pushing
so hard for this, there is very little upside on stable.
> I'd like to think that upgrading major versions should be the same as
> upgrading minor ones (because numbers don't matter here). If that's not
> the case, let's fix it!
Backporting this won't help achieve that aim.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]