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(+)
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 581175a..0bc15c9 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -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;
--
2.1.2
On Wed, Mar 16, 2016 at 07:17:51PM +0800, Harry Pan wrote:
> Conflicts:
> sound/soc/soc-dapm.c
Don't include noise like this in upstream submissions.
> + 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.
On Thu, 2016-03-17 at 09:54 +0000, Mark Brown wrote:
> On Wed, Mar 16, 2016 at 07:17:51PM +0800, Harry Pan wrote:
>
> > Conflicts:
> > sound/soc/soc-dapm.c
>
> Don't include noise like this in upstream submissions.
>
I learned, thanks.
> > + 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
On Thu, Mar 17, 2016 at 10:38:36AM +0000, Pan, Harry wrote:
> 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.
On 03/17/2016 12:25 PM, Mark Brown wrote:
> On Thu, Mar 17, 2016 at 10:38:36AM +0000, Pan, Harry wrote:
>
>> 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.
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
> 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
On Thu, Mar 17, 2016 at 01:37:16PM +0100, Lars-Peter Clausen wrote:
> 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.
On Thursday 17 March 2016 09:12 PM, Mark Brown wrote:
> On Thu, Mar 17, 2016 at 01:37:16PM +0100, Lars-Peter Clausen wrote:
>
>> 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...
--
~Vinod