[PATCH 0/2] ASoC: (SOF) topology: Regression fixes for next
Hi,
Today I came across two regressions in next with SOF:
The topology would not load with a failure of creating playback DAI the first patch is fixing this which was caused by a missing 'else' in the patch
After fixing the topology loading, the module unloading caused kernel panic. The second patch is correcting that which is I likely caused by copy-paste to set wrong unload callback for the graph element.
With these patches applied SOF is working on next and modules can be unloaded
Regards, Peter --- Peter Ujfalusi (2): ASoC: SOF: topology: Add missed "else" in sof_connect_dai_widget ASoC: topology: Set correct unload callback for graph type
sound/soc/soc-topology.c | 2 +- sound/soc/sof/topology.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
The conversion to use generic helpers missed the else for the dai direction check which leads to failure when loading playback widgets
Fixes: 323f09a61d43 ("ASoC: sof: use helper function") Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com --- sound/soc/sof/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c index 3cfdf782afca..4a62ccc71fcb 100644 --- a/sound/soc/sof/topology.c +++ b/sound/soc/sof/topology.c @@ -1065,7 +1065,7 @@ static int sof_connect_dai_widget(struct snd_soc_component *scomp,
if (w->id == snd_soc_dapm_dai_out) stream = SNDRV_PCM_STREAM_CAPTURE; - if (w->id == snd_soc_dapm_dai_in) + else if (w->id == snd_soc_dapm_dai_in) stream = SNDRV_PCM_STREAM_PLAYBACK; else goto end;
Hi Peter
The conversion to use generic helpers missed the else for the dai direction check which leads to failure when loading playback widgets
Fixes: 323f09a61d43 ("ASoC: sof: use helper function") Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com
Acked-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com
Thank you for your help !!
Best regards --- Kuninori Morimoto
Using the control_unload for graph type of elem will lead surprises on module unload.
The correct callback to use is the dapm_route_unload.
Fixes: 31e9273912bf ("ASoC: topology: Use unload() op directly") Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com --- sound/soc/soc-topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index caf547816ea7..78223603088e 100644 --- a/sound/soc/soc-topology.c +++ b/sound/soc/soc-topology.c @@ -1081,7 +1081,7 @@ static int soc_tplg_dapm_graph_elems_load(struct soc_tplg *tplg, /* add route dobj to dobj_list */ route->dobj.type = SND_SOC_DOBJ_GRAPH; if (tplg->ops) - route->dobj.unload = tplg->ops->control_unload; + route->dobj.unload = tplg->ops->dapm_route_unload; route->dobj.index = tplg->index; list_add(&route->dobj.list, &tplg->comp->dobj_list);
On 2/1/2023 12:28 PM, Peter Ujfalusi wrote:
Using the control_unload for graph type of elem will lead surprises on module unload.
The correct callback to use is the dapm_route_unload.
Fixes: 31e9273912bf ("ASoC: topology: Use unload() op directly") Signed-off-by: Peter Ujfalusi peter.ujfalusi@linux.intel.com
LGTM, thanks!
Reviewed-by: Amadeusz Sławiński amadeuszx.slawinski@linux.intel.com
On Wed, 01 Feb 2023 13:28:44 +0200, Peter Ujfalusi wrote:
Today I came across two regressions in next with SOF:
The topology would not load with a failure of creating playback DAI the first patch is fixing this which was caused by a missing 'else' in the patch
After fixing the topology loading, the module unloading caused kernel panic. The second patch is correcting that which is I likely caused by copy-paste to set wrong unload callback for the graph element.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: SOF: topology: Add missed "else" in sof_connect_dai_widget commit: afd7c141c750f3f043c755bd8d01a2ffee7e95b2 [2/2] ASoC: topology: Set correct unload callback for graph type commit: dd184c400e10295631e5742fc7318ba071c67007
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (4)
-
Amadeusz Sławiński -
Kuninori Morimoto -
Mark Brown -
Peter Ujfalusi