Skip to contentSkip to conversation

ASoC: dapm: Do not traverse widget hooks to snd-soc-dummy

PATCH In review Harry Pan 4 participants 8 messages Mar 16, 2016 – Mar 18, 2016

Subsystems (2)
Sound ASoC
lore
Share & tools
lore

Harry Pan

author
#0 lore raw

PATCH 1/1 ASoC: dapm: Do not traverse widget hooks to snd-soc-dummy

All components are initially given an empty card when registering platform, and since the commit 6e78108bda78
("ASoC: core: Don't probe the component which is dummy")', snd-soc-dummy will not be probed so that it remains an empty card assigned.

This patch ignores to iterate widget hooks to the 'snd-soc-dummy' component, else it will trigger memory fault because of invalid dereference address of card->widgets.

Test by grep -rsI "hello" /sys/devices/platform/skl_nau88l25_ssm4567_i2s/

Conflicts:
sound/soc/soc-dapm.c

Signed-off-by Harry Pan <[email protected]>
---
 sound/soc/soc-dapm.c | 3 +++
 1 file changed, 3 insertions(+)
sound/soc/soc-dapm.c +3 -0
index 581175a..0bc15c9 100644
@@ -2188,6 +2188,9 @@ static ssize_t dapm_widget_show_component(struct snd_soc_component *cmpnt,
 	int count = 0;
 	char *state = "not set";
 
+	if (!strcmp(cmpnt->name, "snd-soc-dummy"))
+		return 0;
+
 	list_for_each_entry(w, &cmpnt->card->widgets, list) {
 		if (w->dapm != dapm)
 			continue;
Signature · 1 line
2.1.2
maintainer
#1 lore raw
Quoted 2 lines · Harry Pan

Conflicts:
sound/soc/soc-dapm.c

Don't include noise like this in upstream submissions.

sound/soc/soc-dapm.c static ssize_t dapm_widget_show_component(struct snd_soc_component *cmpnt, · line 2193

Quoted 3 lines
sound/soc/soc-dapm.c +3 -0
+	if (!strcmp(cmpnt->name, "snd-soc-dummy"))
+		return 0;
+

This doesn't make much sense and is going to be very fragile. We should either make the dummy component look like other components or make the code cope with them as they stand, that way we don't have random undocumented special cases scattered through the code. Probably it's better to make the dummy component look like others.

author
#2 lore raw
Quoted 7 lines · Mark Brown
Quoted 2 lines · Harry Pan

Conflicts:
sound/soc/soc-dapm.c

Don't include noise like this in upstream submissions.

I learned, thanks.

Quoted 9 lines

sound/soc/soc-dapm.c static ssize_t dapm_widget_show_component(struct snd_soc_component *cmpnt, · line 2193

Quoted 3 lines
sound/soc/soc-dapm.c +3 -0
+	if (!strcmp(cmpnt->name, "snd-soc-dummy"))
+		return 0;
+

This doesn't make much sense and is going to be very fragile. We should either make the dummy component look like other components or make the code cope with them as they stand, that way we don't have random undocumented special cases scattered through the code. Probably it's better to make the dummy component look like others.

I do agree, basically.

Allow me to explain more detail that I saw during debug; since the commit 6e78108bda78 (ASoC: core: Don't probe the component which is dummy), an exception has been made that dummy component won't be probed, thus the 'card' passed into soc_probe_component() would not be assigned to this component. In the other hand, the component struct is initially created in snd_soc_register_platform() by kzalloc() of platform struct, its 'card' pointer is remaining an NULL pointer even the widget node being read.

Perhaps another option is to refine soc_probe_component(), which I have not dive in.

Sincerely,
Harry

maintainer
#3 lore raw
Quoted 11 lines · Harry

Allow me to explain more detail that I saw during debug; since the commit 6e78108bda78 (ASoC: core: Don't probe the component which is dummy), an exception has been made that dummy component won't be probed, thus the 'card' passed into soc_probe_component() would not be assigned to this component. In the other hand, the component struct is initially created in snd_soc_register_platform() by kzalloc() of platform struct, its 'card' pointer is remaining an NULL pointer even the widget node being read.

Perhaps another option is to refine soc_probe_component(), which I have not dive in.

Another approach might be to create a separate dummy component for each card rather than trying to reuse the same one for all of them (which was what the commit you mention was doing) - that way we don't need to worry about it getting added to multiple cards which was the original problem that was being looked at here.

#4 lore raw
Quoted 11 lines · Mark Brown
Quoted 8 lines · Harry

Allow me to explain more detail that I saw during debug; since the commit 6e78108bda78 (ASoC: core: Don't probe the component which is dummy), an exception has been made that dummy component won't be probed, thus the 'card' passed into soc_probe_component() would not be assigned to this component. In the other hand, the component struct is initially created in snd_soc_register_platform() by kzalloc() of platform struct, its 'card' pointer is remaining an NULL pointer even the widget node being read.

Quoted 8 lines
Quoted 2 lines

Perhaps another option is to refine soc_probe_component(), which I have not dive in.

Another approach might be to create a separate dummy component for each card rather than trying to reuse the same one for all of them (which was what the commit you mention was doing) - that way we don't need to worry about it getting added to multiple cards which was the original problem that was being looked at here.

I'd say as a quick fix for stable check that card is not NULL in dapm_widget_show_component(). And as a longterm fix get rid of dapm_widget file. Nobody should hopefully use it anymore with debugfs being available as the far better alternative.

- Lars

author
#5 lore raw
Quoted 8 lines

I'd say as a quick fix for stable check that card is not NULL in dapm_widget_show_component(). And as a longterm fix get rid of dapm_widget
file. Nobody should hopefully use it anymore with debugfs being available as
the far better alternative.

- Lars

Well, that was my original approach while I realized problem is caused by de-referencing a null pointer to its member of 'widget' list.

i.e.
https://chromium-review.googlesource.com/#/c/331285/3/sound/soc/soc-dap
m.c

+   if (WARN_ON(!codec->component.card))
+       return 0;
+

Additional remark is that I was working on chromium-os v3.18 kernel, so that the interface and argument are sort of different than what I then cherry-pick'ed then sent, which was based on latest 4.5.

Then I was stuck at here couple days keeping hunting root cause, Turned out I found that commit skipped probing dummy component.

Long story short.

-Harry

maintainer
#6 lore raw
In reply to Lars-Peter Clausen
Quoted 4 lines · Lars-Peter Clausen

I'd say as a quick fix for stable check that card is not NULL in dapm_widget_show_component(). And as a longterm fix get rid of dapm_widget file. Nobody should hopefully use it anymore with debugfs being available as the far better alternative.

Getting rid of the file is definitely not a bad idea but I'd still like to see us make the dummy component more consistent with other components in order to minimise the chances that we'll run into other special cases.

#7 lore raw
Quoted 11 lines · Mark Brown
Quoted 4 lines · Lars-Peter Clausen

I'd say as a quick fix for stable check that card is not NULL in dapm_widget_show_component(). And as a longterm fix get rid of dapm_widget file. Nobody should hopefully use it anymore with debugfs being available as the far better alternative.

Getting rid of the file is definitely not a bad idea but I'd still like to see us make the dummy component more consistent with other components in order to minimise the chances that we'll run into other special cases.

Right, I do see that we need dummy component to be fixed up. Today if we use dummy twice in a card it refers to same instance whereas IMO it should create separate instances. I will try something on these lines in next month or so...

Signature · 1 line
~Vinod