All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	linux-tegra@vger.kernel.org, Matthias Reichl <hias@horus.com>,
	alsa-devel@alsa-project.org,
	Marcel Ziswiler <marcel.ziswiler@toradex.com>,
	Takashi Iwai <tiwai@suse.com>,
	linux-kernel@vger.kernel.org,
	Marcel Ziswiler <marcel@ziswiler.com>
Subject: Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement
Date: Tue, 8 Jan 2019 12:03:25 +0000	[thread overview]
Message-ID: <d1e41ed2-da7c-b46c-bc6d-64cf3e536771@nvidia.com> (raw)
In-Reply-To: <b5164c93-8be8-1c3d-9415-c895da6ad622@nvidia.com>


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

WARNING: multiple messages have this Message-ID (diff)
From: Jon Hunter <jonathanh@nvidia.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	<linux-tegra@vger.kernel.org>, Matthias Reichl <hias@horus.com>,
	<alsa-devel@alsa-project.org>,
	Marcel Ziswiler <marcel.ziswiler@toradex.com>,
	Takashi Iwai <tiwai@suse.com>, <linux-kernel@vger.kernel.org>,
	Marcel Ziswiler <marcel@ziswiler.com>
Subject: Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement
Date: Tue, 8 Jan 2019 12:03:25 +0000	[thread overview]
Message-ID: <d1e41ed2-da7c-b46c-bc6d-64cf3e536771@nvidia.com> (raw)
In-Reply-To: <b5164c93-8be8-1c3d-9415-c895da6ad622@nvidia.com>


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

  reply	other threads:[~2019-01-08 12:03 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-18 11:18 [PATCH v1 0/3] ASoC: last minute fixes Marcel Ziswiler
2018-10-18 11:18 ` Marcel Ziswiler
2018-10-18 11:18 ` [PATCH v1 1/3] ASoC: tegra_sgtl5000: fix device_node refcounting Marcel Ziswiler
2018-10-18 11:18   ` Marcel Ziswiler
2018-10-18 11:18 ` [PATCH v1 2/3] ASoC: soc-core: fix trivial checkpatch issues Marcel Ziswiler
2018-10-18 11:18   ` Marcel Ziswiler
2018-10-19 12:26   ` Applied "ASoC: soc-core: fix trivial checkpatch issues" to the asoc tree Mark Brown
2018-10-19 12:26     ` Mark Brown
2018-10-19 12:26     ` Mark Brown
2018-10-19 12:34   ` Mark Brown
2018-10-19 12:34     ` Mark Brown
2018-10-19 12:34     ` Mark Brown
2018-10-18 11:18 ` [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement Marcel Ziswiler
2018-10-18 11:18   ` Marcel Ziswiler
2018-10-19 10:22   ` Jon Hunter
2018-10-19 10:22     ` Jon Hunter
2018-10-21 11:23     ` Mark Brown
2018-10-21 11:23       ` Mark Brown
2018-12-18 17:40       ` Matthias Reichl
2018-12-18 17:40         ` [alsa-devel] " Matthias Reichl
2019-01-03 16:42         ` Jon Hunter
2019-01-03 16:42           ` Jon Hunter
2019-01-08  2:25           ` Kuninori Morimoto
2019-01-08  2:25             ` Kuninori Morimoto
2019-01-08 10:50             ` Jon Hunter
2019-01-08 10:50               ` [alsa-devel] " Jon Hunter
2019-01-08 12:03               ` Jon Hunter [this message]
2019-01-08 12:03                 ` Jon Hunter
2019-01-08 15:48                 ` Jon Hunter
2019-01-08 15:48                   ` Jon Hunter
2019-01-08 16:09                   ` Mark Brown
2019-01-08 16:09                     ` [alsa-devel] " Mark Brown
2019-01-09  1:51                   ` Kuninori Morimoto
2019-01-09  1:51                     ` Kuninori Morimoto
2019-01-09 11:03                     ` Jon Hunter
2019-01-09 11:03                       ` Jon Hunter
2019-01-09 12:53                       ` Mark Brown
2019-01-09 12:53                         ` [alsa-devel] " Mark Brown
2019-01-09 14:11                         ` Jon Hunter
2019-01-09 14:11                           ` Jon Hunter
2019-01-09 14:14                           ` Mark Brown
2019-01-09 14:14                             ` [alsa-devel] " Mark Brown
2019-01-10  1:16                             ` Kuninori Morimoto
2019-01-10  3:46                               ` Kuninori Morimoto
2019-01-10 10:56                               ` Jon Hunter
2019-01-10 10:56                                 ` Jon Hunter
2019-01-11  0:52                                 ` Kuninori Morimoto
2019-01-11  0:52                                   ` [alsa-devel] " Kuninori Morimoto
2019-01-11  8:41                                   ` Jon Hunter
2019-01-11  8:41                                     ` Jon Hunter
2019-01-11  8:51                                     ` Kuninori Morimoto
2019-01-11  8:51                                       ` Kuninori Morimoto
2019-01-11  9:15                                       ` Jon Hunter
2019-01-11  9:15                                         ` Jon Hunter
2019-01-14 23:02                                         ` Mark Brown
2019-01-14 23:02                                           ` [alsa-devel] " Mark Brown
2019-01-15 15:26                                           ` Jon Hunter
2019-01-15 15:26                                             ` Jon Hunter
2019-01-15 18:07                                             ` Matthias Reichl
2019-01-08 15:33         ` Mark Brown
2019-01-08 15:33           ` [alsa-devel] " 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=d1e41ed2-da7c-b46c-bc6d-64cf3e536771@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=hias@horus.com \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=marcel.ziswiler@toradex.com \
    --cc=marcel@ziswiler.com \
    --cc=tiwai@suse.com \
    /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.