[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4252a4dc-0cf3-4ff2-aa55-c03e56345276@linux.intel.com>
Date: Fri, 1 Sep 2023 15:44:04 +0300
From: Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>
To: Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
Cc: alsa-devel@...a-project.org, Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Cezary Rojewski <cezary.rojewski@...el.com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
Bard Liao <yung-chuan.liao@...ux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
Mark Brown <broonie@...nel.org>,
Daniel Baluta <daniel.baluta@....com>,
linux-kernel@...r.kernel.org, sound-open-firmware@...a-project.org
Subject: Re: [PATCH v4 01/11] ASoC: SOF: core: add 'no_wq' probe and remove
callbacks
On 01/09/2023 15:15, Kai Vehmanen wrote:
> Hi,
>
> On Wed, 30 Aug 2023, Maarten Lankhorst wrote:
>
>> With the upcoming changes for i915/Xe driver relying on the
>> -EPROBE_DEFER mechanism, we need to have a first pass of the probe
>> which cannot be pushed to a workqueue. Introduce 2 new optional
>> callbacks.
> [...]
>> diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c
>> index 30db685cc5f4b..54c384a5d6140 100644
>> --- a/sound/soc/sof/core.c
>> +++ b/sound/soc/sof/core.c
>> @@ -327,8 +327,6 @@ static int sof_probe_continue(struct snd_sof_dev *sdev)
>> dsp_err:
>> snd_sof_remove(sdev);
>> probe_err:
>> - sof_ops_free(sdev);
>> -
>
> this seems a bit out-of-place in this patch. It seems a valid change,
> but not really related to this patch, right?
The ops needs to be preserved even if the wq fails since the patch wants
to call snd_sof_remove_no_wq() unconditionally on remove.
> We seem to have a related fix waiting to be sent to alsa-devel, by
> Peter:
> "ASoC: SOF: core: Only call sof_ops_free() on remove if the probe wa"
> https://github.com/thesofproject/linux/pull/4515
I guess we can revert that in sof-dev, if this is the preferred way?
> ... not yet in Mark's tree.
>
> Otherwise patch looks good to me.
I would have not created the snd_sof_remove_no_wq() as it makes not much
functional sense.
It might be even better if the remove in the wq would do the
hda_codec_i915_exit() as the module will remain in there until the user
removes it.
>
> Br, Kai
--
Péter
Powered by blists - more mailing lists