On 08/01/2019 10:50, Jon Hunter wrote:
> Hi Kuninori,
>
> On 08/01/2019 02:25, Kuninori Morimoto wrote:
>>
>> Hi Jon
>>
>>> I have been looking at this again recently. I see this issue occurring
>>> all the time when the sound drivers are built as kernel modules and
>>> probing the sound card is deferred until the codec driver has been loaded.
>>>
>>> Commit daecf46ee0e5 ("ASoC: soc-core: use snd_soc_dai_link_component for
>>> platform") appears to introduce the problem because now we allocate the
>>> 'snd_soc_dai_link_component' structure for the platform we attempt to
>>> register the soundcard but we never clear the freed pointer on failure.
>>> Therefore, we only actually allocate it the first time. There is no easy
>>> way to clear this pointer for the memory allocated because this is done
>>> before the dai-links have been added to the list of dai-links for the
>>> soundcard.
>>>
>>> I don't see an easy solution that will be 100% robust unless you do opt
>>> for copying all the dai-link info from the platform (but this is
>>> probably not a trivial fix).
>>>
>>> Do you envision a fix any time soon, or should we be updating all the
>>> machine drivers to populate the platform snd_soc_dai_link_component so
>>> that it is handled by the machine drivers are not the core?
>>
>> Thank you for pointing it.
>> Indeed it is mess.
>> I think coping info is nice idea,
>> but it is not easy so far, and it uses much memory...
>>
>> I didn't test this, but can below patch solve your issue ?
>
> I will give it a try and let you know.
Yes so this does workaround the problem. However, per my previous
comments, I would like to explore whether it is necessary to allocate
the platform link component or if it can be static.
Cheers
Jon
--
nvpublic
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
