From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Matthias Reichl <hias@horus.com>, Mark Brown <broonie@kernel.org>,
rohkumar@qti.qualcomm.com, alsa-devel@alsa-project.org,
bgoswami@codeaurora.org, vinod.koul@linaro.org,
lgirdwood@gmail.com, plai@codeaurora.org,
linux-kernel@vger.kernel.org, tiwai@suse.com,
Liam Girdwood <liam.r.girdwood@linux.intel.com>,
srinivas.kandagatla@linaro.org,
Rohit kumar <rohitkr@codeaurora.org>,
asishb@codeaurora.org, Ajit Pandey <ajitp@codeaurora.org>
Subject: Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component
Date: Tue, 15 Jan 2019 15:16:57 -0600 [thread overview]
Message-ID: <af2e9555-444f-7c40-865b-347f3db8fa76@linux.intel.com> (raw)
In-Reply-To: <20190115211137.rhdyjadu7fppp3p4@lenny.lan>
>> 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()
> This should be fixed by the patch
> "ASoC: core: Don't defer probe on optional, NULL components" which Mark
> already applied to his tree. See
> http://mailman.alsa-project.org/pipermail/alsa-devel/2019-January/144323.html
Ah yes, I missed this patch while I was debugging. Indeed this fixes the
problem and my devices work again with Mark's for-next branch. Thanks
Matthias!
>
> Maybe the defer card probe logic needs to be extended to also check if
> dai_link_name had already been registered (either cpu or cpu_dai_name
> needs to be set), not 100% sure which problem the defer card probe patch
> was trying to solve.
same here, I don't get why the deferred probe stuff only deals with one
of the two options.
next prev parent reply other threads:[~2019-01-15 21:16 UTC|newest]
Thread overview: 39+ 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-12 6:07 ` [alsa-devel] " Rohit kumar
2019-01-14 15:40 ` Liam Girdwood
2019-01-15 0:06 ` Mark Brown
2019-01-15 0:06 ` [alsa-devel] " Mark Brown
2019-01-15 3:08 ` Pierre-Louis Bossart
2019-01-15 3:08 ` [alsa-devel] " Pierre-Louis Bossart
2019-01-15 19:35 ` Pierre-Louis Bossart
2019-01-15 21:07 ` Mark Brown
2019-01-15 21:07 ` [alsa-devel] " Mark Brown
2019-01-15 21:11 ` Matthias Reichl
2019-01-15 21:11 ` [alsa-devel] " Matthias Reichl
2019-01-15 21:16 ` Pierre-Louis Bossart [this message]
2019-01-15 21:41 ` Mark Brown
2019-01-15 21:41 ` [alsa-devel] " Mark Brown
2019-01-15 21:48 ` 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-22 20:11 ` [alsa-devel] " Pierre-Louis Bossart
2019-01-23 1:36 ` Curtis Malainey
2019-01-23 2:01 ` Pierre-Louis Bossart
2019-01-23 2:01 ` Pierre-Louis Bossart
2019-01-24 18:44 ` Mark Brown
2019-01-24 18:44 ` [alsa-devel] " Mark Brown
2019-01-24 19:07 ` Pierre-Louis Bossart
2019-01-24 19:26 ` Mark Brown
2019-01-24 19:26 ` [alsa-devel] " Mark Brown
2019-01-25 1:32 ` Curtis Malainey
2019-01-25 1:32 ` [alsa-devel] " Curtis Malainey
2019-01-21 19:17 ` Mark Brown
2019-01-21 19:17 ` [alsa-devel] " Mark Brown
2019-01-14 23:26 ` 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=af2e9555-444f-7c40-865b-347f3db8fa76@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=hias@horus.com \
--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.