From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: rohkumar@qti.qualcomm.com, alsa-devel@alsa-project.org,
bgoswami@codeaurora.org, vinod.koul@linaro.org,
linux-kernel@vger.kernel.org, plai@codeaurora.org,
tiwai@suse.com, lgirdwood@gmail.com,
Ajit Pandey <ajitp@codeaurora.org>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>,
Rohit kumar <rohitkr@codeaurora.org>,
asishb@codeaurora.org, srinivas.kandagatla@linaro.org
Subject: Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component
Date: Tue, 15 Jan 2019 13:35:07 -0600 [thread overview]
Message-ID: <796a856c-a9a6-022d-da63-947279090198@linux.intel.com> (raw)
In-Reply-To: <20190115000610.GM11073@sirena.org.uk>
On 1/14/19 6:06 PM, Mark Brown wrote:
> On Fri, Jan 11, 2019 at 03:49:08PM -0600, Pierre-Louis Bossart wrote:
>
>> Adding some traces I can see that the the platform name we use doesn't seem
>> compatible with your logic. All the Intel boards used a constant platform
>> name matching the PCI ID, see e.g. [1], which IIRC is used to bind
>> components. Liam, do you recall in more details if this is really required?
> That's telling me that either snd_soc_find_components() isn't finding
> components in the same way that we do when we bind things which isn't
> good or we're binding links without having fully matched everything on
> the link which also isn't good.
>
> Without a system that shows the issue I can't 100% confirm but I think
> it's the former - I'm fairly sure that those machines are relying on the
> component name being initialized to fmt_single_name() in
> snd_soc_component_initialize(). That is supposed to wind up using
> dev_name() (which would be the PCI address for a PCI device) as the
> basis of the name. What I can't currently see is how exactly that gets
> bound (or how any of the other links avoid trouble for that matter). We
> could revert and push this into cards but I would rather be confident
> that we understand what's going on, I'm not comfortable that we aren't
> just pushing the breakage around rather than fixing it. Can someone
> with an x86 system take a look and confirm exactly what's going on with
> binding these cards please?
Beyond the fact that the platform_name seems to be totally useless,
additional tests show that the patch ('ASoC: soc-core: defer card probe
until all component is added to list') adds a new restriction which
contradicts existing error checks.
None of the Intel machine drivers set the dailink "cpu_name" field but
use the "cpu_dai_name" field instead. This was perfectly legit as
documented by the code at the end of soc_init_dai_link()
/*
* At least one of CPU DAI name or CPU device name/node must be
* specified
*/
if (!link->cpu_dai_name &&
!(link->cpu_name || link->cpu_of_node)) {
dev_err(card->dev,
"ASoC: Neither cpu_dai_name nor cpu_name/of_node are set
for %s\n",
link->name);
return -EINVAL;
}
The code contributed by Qualcomm only checks for cpu_name, which
prevents the init from completing.
So if we want to be consistent, the new code should be something like:
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index b680c673c553..2791da9417f8 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1154,7 +1154,7 @@ static int soc_init_dai_link(struct snd_soc_card
*card,
* Defer card registartion if cpu dai component is not added to
* component list.
*/
- if (!soc_find_component(link->cpu_of_node, link->cpu_name))
+ if (!link->cpu_dai_name &&
!soc_find_component(link->cpu_of_node, link->cpu_name))
return -EPROBE_DEFER;
/*
or try to call soc_find_component with both cpu_name or cpu_dai_name, if
this makes sense?
next prev parent reply other threads:[~2019-01-15 19:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 8:14 [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component Rohit kumar
2019-01-11 15:44 ` [alsa-devel] " Pierre-Louis Bossart
2019-01-11 21:49 ` Pierre-Louis Bossart
2019-01-12 6:07 ` Rohit kumar
2019-01-14 15:40 ` [alsa-devel] " Liam Girdwood
2019-01-15 0:06 ` Mark Brown
2019-01-15 3:08 ` Pierre-Louis Bossart
2019-01-15 19:35 ` Pierre-Louis Bossart [this message]
2019-01-15 21:07 ` Mark Brown
2019-01-15 21:11 ` Matthias Reichl
2019-01-15 21:16 ` [alsa-devel] " Pierre-Louis Bossart
2019-01-15 21:41 ` Mark Brown
2019-01-15 21:48 ` [alsa-devel] " Matthias Reichl
2019-01-18 23:02 ` Pierre-Louis Bossart
2019-01-19 1:12 ` Curtis Malainey
2019-01-19 1:15 ` [alsa-devel] " Curtis Malainey
2019-01-21 18:30 ` Mark Brown
2019-01-22 20:11 ` Pierre-Louis Bossart
2019-01-23 1:36 ` [alsa-devel] " Curtis Malainey
2019-01-23 2:01 ` Pierre-Louis Bossart
2019-01-24 18:44 ` Mark Brown
2019-01-24 19:07 ` [alsa-devel] " Pierre-Louis Bossart
2019-01-24 19:26 ` Mark Brown
2019-01-25 1:32 ` Curtis Malainey
2019-01-21 19:17 ` Mark Brown
2019-01-14 23:26 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=796a856c-a9a6-022d-da63-947279090198@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=ajitp@codeaurora.org \
--cc=alsa-devel@alsa-project.org \
--cc=asishb@codeaurora.org \
--cc=bgoswami@codeaurora.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=plai@codeaurora.org \
--cc=rohitkr@codeaurora.org \
--cc=rohkumar@qti.qualcomm.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=tiwai@suse.com \
--cc=vinod.koul@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.