From: lars@metafoo.de (Lars-Peter Clausen)
To: linux-arm-kernel@lists.infradead.org
Subject: [alsa-devel] [RFC PATCH] ASoC: Modify check condition of multiple bindings of components
Date: Wed, 14 Oct 2015 11:00:01 +0200 [thread overview]
Message-ID: <561E1991.1050705@metafoo.de> (raw)
In-Reply-To: <1444785549.26493.12.camel@mtksdaap41>
On 10/14/2015 03:19 AM, Koro Chen wrote:
> On Tue, 2015-10-13 at 16:42 +0200, Lars-Peter Clausen wrote:
>> On 10/13/2015 04:18 PM, Koro Chen wrote:
>>> On Tue, 2015-10-13 at 15:44 +0200, Lars-Peter Clausen wrote:
>>>> On 10/13/2015 03:37 PM, Koro Chen wrote:
>>>>> The patch "ASoC: Prevent components from being bound to multiple cards"
>>>>> adds check to prevent multiple cards from using the same component.
>>>>> However, snd_soc_register_platform() or snd_soc_register_codec() will
>>>>> also create components, and sharing the same platform by multiple cards
>>>>> is then refused. This happens with a platform having multiple
>>>>> independent DAIs that share the same DMA controller.
>>>>>
>>>>> Relax the condition by checking component->registered_as_component,
>>>>> which is only true in case of snd_soc_register_component() and
>>>>> will be false for components created by snd_soc_register_platform()
>>>>> or snd_soc_register_codec().
>>>>
>>>> Binding a component to multiple cards results in internal data structure
>>>> corruption, regardless of whether it is a raw component, CODEC or platform,
>>>> which is why the check was added. So the proposed change wont work.
>>>>
>>> Thanks for your comment. Is it possible to share an example of how the
>>> data structure will be corrupted? So I can study into this further.
>>
>> Just look at soc_probe_component() and think about what happens if that runs
>> twice for two different cards. Multiple calls to list_add() on the same
>> list, controls are added multiple times, DAPM widgets are created multiple
>> times, the card field will only point to the last card.
>>
> When multiple binding happens, soc_probe_component() just returns zero
> without doing anything after this patch (actually it also returned zero
> before the patch "ASoC: Prevent components from being bound to multiple
> cards"). So the component still binds to the first card. For this case I
> think it should be fine?
Same answer as before more or less. There is a lot of card specific
initialization happening in soc_probe_component(). The card field is
initialized to the card the component is bound to, the DAPM widgets are
created for the component in the cards DAPM graph, DAI link widgets are
created and so on. If you bind the component to multiple cards the
initialization will only be done for one card, the first one it was bound
to, that doesn't make too much sense. If you look at the snd_soc_component
data structure it should be obvious that it does not make sense to associate
it with more than a single card.
It was never intended that it is possible to bind a component to multiple
cards. That it was possible was a bug that was overlooked and some people
tried to do it which caused apparently random crashes later on, caused by
the data structure corruption. This is why we added the check to catch this
kind of mistake early and to avoid the crashes.
- Lars
next prev parent reply other threads:[~2015-10-14 9:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 13:37 [RFC PATCH] ASoC: Modify check condition of multiple bindings of components Koro Chen
2015-10-13 13:44 ` Lars-Peter Clausen
2015-10-13 14:18 ` [alsa-devel] " Koro Chen
2015-10-13 14:42 ` Lars-Peter Clausen
2015-10-14 1:19 ` Koro Chen
2015-10-14 9:00 ` Lars-Peter Clausen [this message]
2015-10-15 12:10 ` Mark Brown
2015-10-15 12:49 ` Koro Chen
2015-10-15 13:26 ` Lars-Peter Clausen
2015-10-16 2:31 ` Koro Chen
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=561E1991.1050705@metafoo.de \
--to=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).