| Message ID | 1458127071-14417-1-git-send-email-harry.pan@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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...
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;
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 <harry.pan@intel.com> --- sound/soc/soc-dapm.c | 3 +++ 1 file changed, 3 insertions(+)