May 2023 - Sound-open-firmware - mailman.alsa-project.org

Re: [PATCH 1/2] ASoC: SOF: mediatek: add mt8188 audio support
by Pierre-Louis Bossart 01 Jun '23

01 Jun '23

On 5/15/23 10:05, Mark Brown wrote: > On Mon, May 15, 2023 at 01:25:44PM +0200, AngeloGioacchino Del Regno wrote: >> Il 15/05/23 07:25, Trevor Wu ha scritto: > >>> +{ >>> + /* common defaults */ >>> + memcpy(&sof_mt8188_ops, &sof_mt8186_ops, sizeof(struct snd_sof_dsp_ops)); > >> Never use sizeof(type), always use destination var size! Anyway, there's more. >> >> I don't think we need to perform this memcpy: we'll never see an instance of >> both mt8186 and mt8188 drivers on the same machine, so you can safely just use >> sof_mt8186_ops for mt8188... > >>> + sof_mt8188_ops.drv = mt8188_dai; > >> ...which obviously means that this becomes > >> sof_mt8186_ops.drv = mt8188_dai; > > This does have the issue that it then means the ops struct isn't const > which isn't ideal. It's also not the end of the world though so I don't > have super strong feelings. We do the same for Intel devices, we have a common structure which is copied and only the members that differ in specific SOCs are updated. You're right that it's not constant, but it avoids copy-paste of a rather large structure just to change a couple of lines.

2 2

[PATCH v2 0/2] ASoC: SOF: add mt8188 audio support
by Trevor Wu 30 May '23

30 May '23

This series adds mt8188 audio support and dbg_dump callback for mt8186 and mt8188. Changes since v1: - fix typo - adopt reviewer's suggestion Trevor Wu (2): ASoC: SOF: mediatek: add mt8188 audio support ASoC: SOF: mediatek: add adsp debug dump sound/soc/sof/mediatek/mt8186/mt8186.c | 83 +++++++++++++++++++++++++- 1 file changed, 82 insertions(+), 1 deletion(-) -- 2.18.0

2 3

[PATCH] sound: Fix incorrect calculation of object size by sizeof
by Lu Hongfei 30 May '23

30 May '23

What we need to calculate is the size of the object, not the size of the pointer. This patch can fix this error. Signed-off-by: Lu Hongfei <luhongfei(a)vivo.com> --- sound/soc/sof/ipc4-topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) mode change 100644 => 100755 sound/soc/sof/ipc4-topology.c diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c index 5abe616a2054..29b6dede53b0 --- a/sound/soc/sof/ipc4-topology.c +++ b/sound/soc/sof/ipc4-topology.c @@ -220,7 +220,7 @@ static int sof_ipc4_get_audio_fmt(struct snd_soc_component *scomp, ret = sof_update_ipc_object(scomp, available_fmt, SOF_AUDIO_FMT_NUM_TOKENS, swidget->tuples, - swidget->num_tuples, sizeof(available_fmt), 1); + swidget->num_tuples, sizeof(*available_fmt), 1); if (ret) { dev_err(scomp->dev, "Failed to parse audio format token count\n"); return ret; -- 2.39.0

1 0

[PATCH AUTOSEL 6.1 29/57] ASoC: SOF: pm: save io region state in case of errors in resume
by Sasha Levin 25 May '23

25 May '23

From: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> [ Upstream commit 171b53be635ac15d4feafeb33946035649b1ca14 ] If there are failures in DSP runtime resume, the device state will not reach active and this makes it impossible e.g. to retrieve a possible DSP panic dump via "exception" debugfs node. If CONFIG_SND_SOC_SOF_DEBUG_ENABLE_DEBUGFS_CACHE=y is set, the data in cache is stale. If debugfs cache is not used, the region simply cannot be read. To allow debugging these scenarios, update the debugfs cache contents in resume error handler. User-space can then later retrieve DSP panic and other state via debugfs (requires SOF debugfs cache to be enabled in build). Reported-by: Curtis Malainey <cujomalainey(a)chromium.org Link: https://github.com/thesofproject/linux/issues/4274 Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com Reviewed-by: Curtis Malainey <cujomalainey(a)chromium.org Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com Link: https://lore.kernel.org/r/20230512104638.21376-1-peter.ujfalusi@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/pm.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/sound/soc/sof/pm.c b/sound/soc/sof/pm.c index 26ffcbb6e30f4..a1bfa5a37e2ad 100644 --- a/sound/soc/sof/pm.c +++ b/sound/soc/sof/pm.c @@ -159,7 +159,7 @@ static int sof_resume(struct device *dev, bool runtime_resume) ret = tplg_ops->set_up_all_pipelines(sdev, false); if (ret < 0) { dev_err(sdev->dev, "Failed to restore pipeline after resume %d\n", ret); - return ret; + goto setup_fail; } } @@ -173,6 +173,18 @@ static int sof_resume(struct device *dev, bool runtime_resume) dev_err(sdev->dev, "ctx_restore IPC error during resume: %d\n", ret); } +setup_fail: +#if IS_ENABLED(CONFIG_SND_SOC_SOF_DEBUG_ENABLE_DEBUGFS_CACHE) + if (ret < 0) { + /* + * Debugfs cannot be read in runtime suspend, so cache + * the contents upon failure. This allows to capture + * possible DSP coredump information. + */ + sof_cache_debugfs(sdev); + } +#endif + return ret; } -- 2.39.2

1 0

[PATCH AUTOSEL 6.1 28/57] ASoC: SOF: sof-client-probes: fix pm_runtime imbalance in error handling
by Sasha Levin 25 May '23

25 May '23

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> [ Upstream commit bc424273c74c1565c459c8f2a6ed95caee368d0a ] When an error occurs, we need to make sure the device can pm_runtime suspend instead of keeping it active. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com Reviewed-by: Daniel Baluta <daniel.baluta(a)nxp.com Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com Link: https://lore.kernel.org/r/20230512103315.8921-4-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/sof-client-probes.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/sound/soc/sof/sof-client-probes.c b/sound/soc/sof/sof-client-probes.c index ddeabbb5580e1..1e521a9e34d27 100644 --- a/sound/soc/sof/sof-client-probes.c +++ b/sound/soc/sof/sof-client-probes.c @@ -441,12 +441,7 @@ static ssize_t sof_probes_dfs_points_read(struct file *file, char __user *to, ret = sof_probes_points_info(cdev, &desc, &num_desc); if (ret < 0) - goto exit; - - pm_runtime_mark_last_busy(dev); - err = pm_runtime_put_autosuspend(dev); - if (err < 0) - dev_err_ratelimited(dev, "debugfs read failed to idle %d\n", err); + goto pm_error; for (i = 0; i < num_desc; i++) { offset = strlen(buf); @@ -464,6 +459,13 @@ static ssize_t sof_probes_dfs_points_read(struct file *file, char __user *to, ret = simple_read_from_buffer(to, count, ppos, buf, strlen(buf)); kfree(desc); + +pm_error: + pm_runtime_mark_last_busy(dev); + err = pm_runtime_put_autosuspend(dev); + if (err < 0) + dev_err_ratelimited(dev, "debugfs read failed to idle %d\n", err); + exit: kfree(buf); return ret; -- 2.39.2

1 0

[PATCH AUTOSEL 6.1 27/57] ASoC: SOF: pcm: fix pm_runtime imbalance in error handling
by Sasha Levin 25 May '23

25 May '23

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> [ Upstream commit da0fe8fd515a471d373acc3682bfb5522cca4d55 ] When an error occurs, we need to make sure the device can pm_runtime suspend instead of keeping it active. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com Reviewed-by: Daniel Baluta <daniel.baluta(a)nxp.com Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com Link: https://lore.kernel.org/r/20230512103315.8921-3-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/pcm.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/sound/soc/sof/pcm.c b/sound/soc/sof/pcm.c index 14571b821ecac..be6f38af37b5d 100644 --- a/sound/soc/sof/pcm.c +++ b/sound/soc/sof/pcm.c @@ -619,16 +619,17 @@ static int sof_pcm_probe(struct snd_soc_component *component) "%s/%s", plat_data->tplg_filename_prefix, plat_data->tplg_filename); - if (!tplg_filename) - return -ENOMEM; + if (!tplg_filename) { + ret = -ENOMEM; + goto pm_error; + } ret = snd_sof_load_topology(component, tplg_filename); - if (ret < 0) { + if (ret < 0) dev_err(component->dev, "error: failed to load DSP topology %d\n", ret); - return ret; - } +pm_error: pm_runtime_mark_last_busy(component->dev); pm_runtime_put_autosuspend(component->dev); -- 2.39.2

1 0

[PATCH AUTOSEL 6.1 26/57] ASoC: SOF: debug: conditionally bump runtime_pm counter on exceptions
by Sasha Levin 25 May '23

25 May '23

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> [ Upstream commit 3de975862f985f1c9e225a0d13aa3d501373f7c3 ] When a firmware IPC error happens during a pm_runtime suspend, we ignore the error and suspend anyways. However, the code unconditionally increases the runtime_pm counter. This results in a confusing configuration where the code will suspend, resume but never suspend again due to the use of pm_runtime_get_noresume(). The intent of the counter increase was to prevent entry in D3, but if that transition to D3 is already started it cannot be stopped. In addition, there's no point in that case in trying to prevent anything, the firmware error is handled and the next resume will re-initialize the firmware completely. This patch changes the logic to prevent suspend when the device is pm_runtime active and has a use_count > 0. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com Reviewed-by: Daniel Baluta <daniel.baluta(a)nxp.com Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com Link: https://lore.kernel.org/r/20230512103315.8921-2-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/debug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/debug.c b/sound/soc/sof/debug.c index ade0507328af4..5042312b1b98d 100644 --- a/sound/soc/sof/debug.c +++ b/sound/soc/sof/debug.c @@ -437,8 +437,8 @@ void snd_sof_handle_fw_exception(struct snd_sof_dev *sdev, const char *msg) /* should we prevent DSP entering D3 ? */ if (!sdev->ipc_dump_printed) dev_info(sdev->dev, - "preventing DSP entering D3 state to preserve context\n"); - pm_runtime_get_noresume(sdev->dev); + "Attempting to prevent DSP from entering D3 state to preserve context\n"); + pm_runtime_get_if_in_use(sdev->dev); } /* dump vital information to the logs */ -- 2.39.2

1 0

[PATCH AUTOSEL 6.3 34/67] ASoC: SOF: pm: save io region state in case of errors in resume
by Sasha Levin 25 May '23

25 May '23

From: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> [ Upstream commit 171b53be635ac15d4feafeb33946035649b1ca14 ] If there are failures in DSP runtime resume, the device state will not reach active and this makes it impossible e.g. to retrieve a possible DSP panic dump via "exception" debugfs node. If CONFIG_SND_SOC_SOF_DEBUG_ENABLE_DEBUGFS_CACHE=y is set, the data in cache is stale. If debugfs cache is not used, the region simply cannot be read. To allow debugging these scenarios, update the debugfs cache contents in resume error handler. User-space can then later retrieve DSP panic and other state via debugfs (requires SOF debugfs cache to be enabled in build). Reported-by: Curtis Malainey <cujomalainey(a)chromium.org Link: https://github.com/thesofproject/linux/issues/4274 Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com Reviewed-by: Curtis Malainey <cujomalainey(a)chromium.org Reviewed-by: Péter Ujfalusi <peter.ujfalusi(a)linux.intel.com Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com Link: https://lore.kernel.org/r/20230512104638.21376-1-peter.ujfalusi@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/pm.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/sound/soc/sof/pm.c b/sound/soc/sof/pm.c index 85412aeb1ca16..40f392efd8246 100644 --- a/sound/soc/sof/pm.c +++ b/sound/soc/sof/pm.c @@ -159,7 +159,7 @@ static int sof_resume(struct device *dev, bool runtime_resume) ret = tplg_ops->set_up_all_pipelines(sdev, false); if (ret < 0) { dev_err(sdev->dev, "Failed to restore pipeline after resume %d\n", ret); - return ret; + goto setup_fail; } } @@ -173,6 +173,18 @@ static int sof_resume(struct device *dev, bool runtime_resume) dev_err(sdev->dev, "ctx_restore IPC error during resume: %d\n", ret); } +setup_fail: +#if IS_ENABLED(CONFIG_SND_SOC_SOF_DEBUG_ENABLE_DEBUGFS_CACHE) + if (ret < 0) { + /* + * Debugfs cannot be read in runtime suspend, so cache + * the contents upon failure. This allows to capture + * possible DSP coredump information. + */ + sof_cache_debugfs(sdev); + } +#endif + return ret; } -- 2.39.2

1 0

[PATCH AUTOSEL 6.3 33/67] ASoC: SOF: sof-client-probes: fix pm_runtime imbalance in error handling
by Sasha Levin 25 May '23

25 May '23

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> [ Upstream commit bc424273c74c1565c459c8f2a6ed95caee368d0a ] When an error occurs, we need to make sure the device can pm_runtime suspend instead of keeping it active. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com Reviewed-by: Daniel Baluta <daniel.baluta(a)nxp.com Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com Link: https://lore.kernel.org/r/20230512103315.8921-4-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/sof-client-probes.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/sound/soc/sof/sof-client-probes.c b/sound/soc/sof/sof-client-probes.c index fff126808bc04..8d9e9d5f40e45 100644 --- a/sound/soc/sof/sof-client-probes.c +++ b/sound/soc/sof/sof-client-probes.c @@ -218,12 +218,7 @@ static ssize_t sof_probes_dfs_points_read(struct file *file, char __user *to, ret = ipc->points_info(cdev, &desc, &num_desc); if (ret < 0) - goto exit; - - pm_runtime_mark_last_busy(dev); - err = pm_runtime_put_autosuspend(dev); - if (err < 0) - dev_err_ratelimited(dev, "debugfs read failed to idle %d\n", err); + goto pm_error; for (i = 0; i < num_desc; i++) { offset = strlen(buf); @@ -241,6 +236,13 @@ static ssize_t sof_probes_dfs_points_read(struct file *file, char __user *to, ret = simple_read_from_buffer(to, count, ppos, buf, strlen(buf)); kfree(desc); + +pm_error: + pm_runtime_mark_last_busy(dev); + err = pm_runtime_put_autosuspend(dev); + if (err < 0) + dev_err_ratelimited(dev, "debugfs read failed to idle %d\n", err); + exit: kfree(buf); return ret; -- 2.39.2

1 0

[PATCH AUTOSEL 6.3 32/67] ASoC: SOF: pcm: fix pm_runtime imbalance in error handling
by Sasha Levin 25 May '23

25 May '23

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> [ Upstream commit da0fe8fd515a471d373acc3682bfb5522cca4d55 ] When an error occurs, we need to make sure the device can pm_runtime suspend instead of keeping it active. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com Reviewed-by: Daniel Baluta <daniel.baluta(a)nxp.com Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com Link: https://lore.kernel.org/r/20230512103315.8921-3-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/pcm.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/sound/soc/sof/pcm.c b/sound/soc/sof/pcm.c index 445acb5c3a21b..2570f33db9f3e 100644 --- a/sound/soc/sof/pcm.c +++ b/sound/soc/sof/pcm.c @@ -616,16 +616,17 @@ static int sof_pcm_probe(struct snd_soc_component *component) "%s/%s", plat_data->tplg_filename_prefix, plat_data->tplg_filename); - if (!tplg_filename) - return -ENOMEM; + if (!tplg_filename) { + ret = -ENOMEM; + goto pm_error; + } ret = snd_sof_load_topology(component, tplg_filename); - if (ret < 0) { + if (ret < 0) dev_err(component->dev, "error: failed to load DSP topology %d\n", ret); - return ret; - } +pm_error: pm_runtime_mark_last_busy(component->dev); pm_runtime_put_autosuspend(component->dev); -- 2.39.2

1 0

[PATCH AUTOSEL 6.3 31/67] ASoC: SOF: debug: conditionally bump runtime_pm counter on exceptions
by Sasha Levin 25 May '23

25 May '23

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> [ Upstream commit 3de975862f985f1c9e225a0d13aa3d501373f7c3 ] When a firmware IPC error happens during a pm_runtime suspend, we ignore the error and suspend anyways. However, the code unconditionally increases the runtime_pm counter. This results in a confusing configuration where the code will suspend, resume but never suspend again due to the use of pm_runtime_get_noresume(). The intent of the counter increase was to prevent entry in D3, but if that transition to D3 is already started it cannot be stopped. In addition, there's no point in that case in trying to prevent anything, the firmware error is handled and the next resume will re-initialize the firmware completely. This patch changes the logic to prevent suspend when the device is pm_runtime active and has a use_count > 0. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com Reviewed-by: Daniel Baluta <daniel.baluta(a)nxp.com Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com Link: https://lore.kernel.org/r/20230512103315.8921-2-peter.ujfalusi@linux.intel.… Signed-off-by: Mark Brown <broonie(a)kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/debug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/debug.c b/sound/soc/sof/debug.c index ade0507328af4..5042312b1b98d 100644 --- a/sound/soc/sof/debug.c +++ b/sound/soc/sof/debug.c @@ -437,8 +437,8 @@ void snd_sof_handle_fw_exception(struct snd_sof_dev *sdev, const char *msg) /* should we prevent DSP entering D3 ? */ if (!sdev->ipc_dump_printed) dev_info(sdev->dev, - "preventing DSP entering D3 state to preserve context\n"); - pm_runtime_get_noresume(sdev->dev); + "Attempting to prevent DSP from entering D3 state to preserve context\n"); + pm_runtime_get_if_in_use(sdev->dev); } /* dump vital information to the logs */ -- 2.39.2

1 0

[PATCH AUTOSEL 6.3 08/67] ASoC: SOF: amd: Fix NULL pointer crash in acp_sof_ipc_msg_data function
by Sasha Levin 25 May '23

25 May '23

From: V sujith kumar Reddy <Vsujithkumar.Reddy(a)amd.com> [ Upstream commit 051d71e073614a72ad423d6dacba37a7eeff274d ] Check substream and runtime variables before assigning. Signed-off-by: V sujith kumar Reddy <Vsujithkumar.Reddy(a)amd.com Link: https://lore.kernel.org/r/20230508070510.6100-1-Vsujithkumar.Reddy@amd.com Signed-off-by: Mark Brown <broonie(a)kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/amd/acp-ipc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/sound/soc/sof/amd/acp-ipc.c b/sound/soc/sof/amd/acp-ipc.c index 4e0c48a361599..749e856dc6011 100644 --- a/sound/soc/sof/amd/acp-ipc.c +++ b/sound/soc/sof/amd/acp-ipc.c @@ -209,7 +209,12 @@ int acp_sof_ipc_msg_data(struct snd_sof_dev *sdev, struct snd_sof_pcm_stream *sp acp_mailbox_read(sdev, offset, p, sz); } else { struct snd_pcm_substream *substream = sps->substream; - struct acp_dsp_stream *stream = substream->runtime->private_data; + struct acp_dsp_stream *stream; + + if (!substream || !substream->runtime) + return -ESTRPIPE; + + stream = substream->runtime->private_data; if (!stream) return -ESTRPIPE; -- 2.39.2

1 0

[PATCH v2 0/2] ASoC: do not include runtime_pm.h if not needed
by Claudiu Beznea 23 May '23

23 May '23

Hi, Series removes the pm_runtime.h inclusion in files where APIs exported though pm_runtime.h are not used. In case of files that make use of pm.h which comes form pm_runtime.h added patch 2/2. Changes were built with allmodconfig on ARM and x86_64 and checked all the changed files were built at least once. Thank you, Claudiu Beznea Changes in v2: - removed cs35l45 handling - changed a bit commit description - added patch 2/2 - collected Jarkko Nikula's tag Claudiu Beznea (2): ASoC: do not include pm_runtime.h if not used ASoC: use pm.h instead of runtime_pm.h sound/hda/hdac_regmap.c | 1 - sound/pci/hda/hda_bind.c | 1 - sound/soc/amd/acp/acp-pci.c | 1 - sound/soc/amd/acp/acp-platform.c | 1 - sound/soc/codecs/max98090.c | 1 - sound/soc/codecs/max98373-i2c.c | 2 +- sound/soc/codecs/pcm186x.c | 1 - sound/soc/codecs/rk3328_codec.c | 1 - sound/soc/codecs/rt5682-i2c.c | 1 - sound/soc/codecs/rt5682s.c | 1 - sound/soc/codecs/tas2562.c | 1 - sound/soc/codecs/tas5720.c | 1 - sound/soc/codecs/tas6424.c | 1 - sound/soc/codecs/wm_adsp.c | 1 - sound/soc/fsl/imx-audmix.c | 1 - sound/soc/intel/atom/sst/sst_acpi.c | 1 - sound/soc/intel/atom/sst/sst_ipc.c | 1 - sound/soc/intel/atom/sst/sst_loader.c | 1 - sound/soc/intel/atom/sst/sst_pci.c | 1 - sound/soc/intel/atom/sst/sst_stream.c | 1 - sound/soc/mediatek/mt8186/mt8186-afe-control.c | 1 - sound/soc/mediatek/mt8186/mt8186-mt6366-da7219-max98357.c | 1 - sound/soc/mediatek/mt8186/mt8186-mt6366-rt1019-rt5682s.c | 1 - sound/soc/mediatek/mt8192/mt8192-afe-control.c | 2 -- sound/soc/qcom/lpass-sc7180.c | 2 +- sound/soc/qcom/lpass-sc7280.c | 2 +- sound/soc/soc-compress.c | 1 - sound/soc/soc-pcm.c | 1 - sound/soc/sof/intel/hda-loader-skl.c | 1 - sound/soc/sof/intel/hda-stream.c | 1 - sound/soc/sof/intel/skl.c | 1 - sound/soc/sof/mediatek/mt8186/mt8186-clk.c | 1 - sound/soc/sof/mediatek/mt8195/mt8195-clk.c | 1 - sound/soc/tegra/tegra20_ac97.c | 1 - sound/soc/ti/omap-mcbsp-st.c | 1 - 35 files changed, 3 insertions(+), 36 deletions(-) -- 2.34.1

2 3

[PATCH next] ASoC: SOF: Intel: hda-dai: Fix locking in hda_ipc4_pre_trigger()
by Harshit Mogalapalli 23 May '23

23 May '23

hda_ipc4_pre_trigger() has two issues: 1. In the default case, we are returning without unlocking the mutex. 2. In case SNDRV_PCM_TRIGGER_STOP: when ret is less than zero it goes to out, unlocks but returns zero instead of a negative value. Fix this by changing the final return value to 'ret' instead of zero, and initialize 'ret' to zero in the start of the function. Fixes: 225f37b578a9 ("ASoC: SOF: ipc4-pcm: reset all pipelines during FE DAI hw_free") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- Only compile tested. This is found using static anlysis with Smatch. --- sound/soc/sof/intel/hda-dai-ops.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/soc/sof/intel/hda-dai-ops.c b/sound/soc/sof/intel/hda-dai-ops.c index 5a508e118e3d..1e58256c8003 100644 --- a/sound/soc/sof/intel/hda-dai-ops.c +++ b/sound/soc/sof/intel/hda-dai-ops.c @@ -183,7 +183,7 @@ static int hda_ipc4_pre_trigger(struct snd_sof_dev *sdev, struct snd_soc_dai *cp struct sof_ipc4_pipeline *pipeline; struct snd_sof_widget *swidget; struct snd_soc_dapm_widget *w; - int ret; + int ret = 0; w = snd_soc_dai_get_widget(cpu_dai, substream->stream); swidget = w->dobj.private; @@ -208,11 +208,11 @@ static int hda_ipc4_pre_trigger(struct snd_sof_dev *sdev, struct snd_soc_dai *cp break; default: dev_err(sdev->dev, "unknown trigger command %d\n", cmd); - return -EINVAL; + ret = -EINVAL; } out: mutex_unlock(&ipc4_data->pipeline_state_mutex); - return 0; + return ret; } static int hda_trigger(struct snd_sof_dev *sdev, struct snd_soc_dai *cpu_dai, -- 2.31.1

3 2

[PATCH -next] ASoC: SOF: ipc4-topology: Fix an unsigned comparison which can never be negative
by Yang Li 23 May '23

23 May '23

The return value from the call to sof_ipc4_get_valid_bits() is int. However, the return value is being assigned to an unsigned int variable 'out_ref_valid_bits', so making it an int. Eliminate the following warning: ./sound/soc/sof/ipc4-topology.c:1537:6-24: WARNING: Unsigned expression compared with zero: out_ref_valid_bits < 0 Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4985 Signed-off-by: Yang Li <yang.lee(a)linux.alibaba.com> --- sound/soc/sof/ipc4-topology.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c index dce2f8f7f518..d82ac5701eb2 100644 --- a/sound/soc/sof/ipc4-topology.c +++ b/sound/soc/sof/ipc4-topology.c @@ -1381,8 +1381,8 @@ sof_ipc4_prepare_copier_module(struct snd_sof_widget *swidget, void **ipc_config_data; int *ipc_config_size; u32 **data; - int ipc_size, ret; - u32 out_ref_rate, out_ref_channels, out_ref_valid_bits; + int ipc_size, ret, out_ref_valid_bits; + u32 out_ref_rate, out_ref_channels; u32 deep_buffer_dma_ms = 0; int output_fmt_index; -- 2.20.1.7.g153144c

3 2

[PATCH] ASoC: SOF: amd: Add pci revision id check
by Venkata Prasad Potturu 23 May '23

23 May '23

Add pci revision id check for renoir and rembrandt platforms. Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu(a)amd.com> --- sound/soc/sof/amd/acp.h | 3 +++ sound/soc/sof/amd/pci-rmb.c | 3 +++ sound/soc/sof/amd/pci-rn.c | 3 +++ 3 files changed, 9 insertions(+) diff --git a/sound/soc/sof/amd/acp.h b/sound/soc/sof/amd/acp.h index 1c535cc6c3a9..dc624f727aa3 100644 --- a/sound/soc/sof/amd/acp.h +++ b/sound/soc/sof/amd/acp.h @@ -55,6 +55,9 @@ #define ACP_DSP_TO_HOST_IRQ 0x04 +#define ACP_RN_PCI_ID 0x01 +#define ACP_RMB_PCI_ID 0x6F + #define HOST_BRIDGE_CZN 0x1630 #define HOST_BRIDGE_RMB 0x14B5 #define ACP_SHA_STAT 0x8000 diff --git a/sound/soc/sof/amd/pci-rmb.c b/sound/soc/sof/amd/pci-rmb.c index eaf70ea6e556..58b3092425f1 100644 --- a/sound/soc/sof/amd/pci-rmb.c +++ b/sound/soc/sof/amd/pci-rmb.c @@ -65,6 +65,9 @@ static int acp_pci_rmb_probe(struct pci_dev *pci, const struct pci_device_id *pc { unsigned int flag; + if (pci->revision != ACP_RMB_PCI_ID) + return -ENODEV; + flag = snd_amd_acp_find_config(pci); if (flag != FLAG_AMD_SOF && flag != FLAG_AMD_SOF_ONLY_DMIC) return -ENODEV; diff --git a/sound/soc/sof/amd/pci-rn.c b/sound/soc/sof/amd/pci-rn.c index 4809cb644152..7409e21ce5aa 100644 --- a/sound/soc/sof/amd/pci-rn.c +++ b/sound/soc/sof/amd/pci-rn.c @@ -65,6 +65,9 @@ static int acp_pci_rn_probe(struct pci_dev *pci, const struct pci_device_id *pci { unsigned int flag; + if (pci->revision != ACP_RN_PCI_ID) + return -ENODEV; + flag = snd_amd_acp_find_config(pci); if (flag != FLAG_AMD_SOF && flag != FLAG_AMD_SOF_ONLY_DMIC) return -ENODEV; -- 2.25.1

1 0

Potential license violation
by ryan 19 May '23

19 May '23

Hey there, I hope this email finds you well. I am writing to report a potential SOF license violation. A person by the name CoolStar (aka starplayer132 and coolstarorg) is a developer in the custom Chromebook modding scene who creates drivers for Chromebooks running Windows 10/11. They sell SOF drivers for $10. However, when the driver is decompiled/deobfuscated using a reverse engineering program called Ghidra, the strings in the binary are identical to the ones in the Linux driver. Here is a function from the Linux driver found in the Windows one: The issue is that this SOF-based driver is closed source and, most importantly, paid, which completely violates the GPL license the original driver is using. Only about 15% of this code is their own property if you exclude the DRM inserted to paywall users from a simple audio driver. The following links are links to CoolStar's websites. https://coolstar.org/chromebook/ https://github.com/coolstar https://www.reddit.com/user/coolstarorg Thank you for your time. Have a good day. You can contact me from this email, meghann6(a)proton.me.

2 3

[PATCH] ASoC: SOF: Simplify the calculation of variables
by Jiapeng Chong 15 May '23

15 May '23

./sound/soc/sof/pcm.c:372:27-29: WARNING !A || A && B is equivalent to !A || B. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4938 Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- sound/soc/sof/pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/pcm.c b/sound/soc/sof/pcm.c index 567db32173a8..d14e7fd2c2ee 100644 --- a/sound/soc/sof/pcm.c +++ b/sound/soc/sof/pcm.c @@ -369,7 +369,7 @@ static int sof_pcm_trigger(struct snd_soc_component *component, case SNDRV_PCM_TRIGGER_PAUSE_PUSH: case SNDRV_PCM_TRIGGER_STOP: /* invoke platform trigger to stop DMA even if pcm_ops isn't set or if it failed */ - if (!pcm_ops || (pcm_ops && !pcm_ops->platform_stop_during_hw_free)) + if (!pcm_ops || !pcm_ops->platform_stop_during_hw_free) snd_sof_pcm_platform_trigger(sdev, substream, cmd); break; default: -- 2.20.1.7.g153144c

3 2

[PATCH 0/2] ASoC: SOF: add mt8188 audio support
by Trevor Wu 15 May '23

15 May '23

This series adds mt8188 audio support and dbg_dump callback for mt8186 and mt8188. Trevor Wu (2): ASoC: SOF: mediatek: add mt8188 audio support ASoC: SOF: mediatek: add adsp debug dump sound/soc/sof/mediatek/mt8186/mt8186.c | 83 +++++++++++++++++++++++++- sound/soc/sof/mediatek/mt8186/mt8186.h | 5 ++ 2 files changed, 87 insertions(+), 1 deletion(-) -- 2.18.0

2 3

[PATCH] ASoC: SOF: topology: Fix missing error code in sof_route_load()
by Jiapeng Chong 12 May '23

12 May '23

The error code is missing in this code scenario, add the error code '-EINVAL' to the return value 'err'. sound/soc/sof/topology.c:2060 sof_route_load() warn: missing error code 'ret'. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4935 Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- sound/soc/sof/topology.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c index d3d536b0a8f5..3ca3a72f1805 100644 --- a/sound/soc/sof/topology.c +++ b/sound/soc/sof/topology.c @@ -2045,7 +2045,6 @@ static int sof_route_load(struct snd_soc_component *scomp, int index, if (!source_swidget) { dev_err(scomp->dev, "error: source %s not found\n", route->source); - ret = -EINVAL; goto err; } @@ -2064,7 +2063,6 @@ static int sof_route_load(struct snd_soc_component *scomp, int index, if (!sink_swidget) { dev_err(scomp->dev, "error: sink %s not found\n", route->sink); - ret = -EINVAL; goto err; } @@ -2087,6 +2085,8 @@ static int sof_route_load(struct snd_soc_component *scomp, int index, return 0; err: kfree(sroute); + ret = -EINVAL; + return ret; } -- 2.20.1.7.g153144c

1 0

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])
by Jaroslav Kysela 10 May '23

10 May '23

On 09. 05. 23 11:37, Mark Brown wrote: > On Tue, May 09, 2023 at 09:12:55AM +0200, Jaroslav Kysela wrote: >> On 08. 05. 23 9:52, Takashi Iwai wrote: > > [alsa-devel rewriting mails in a way that renders them useless with b4] > >>> Jaroslav, could you investigate it? I checked again, and it seems >>> that all "approved" posts from non-subscribers are modified to the >>> sender addresses with alsa-project.org. I guess there must be some >>> option to prevent it. > >> The answer is DMARC. And the "mangling" applies only to senders which >> domains have restricted DMARC settings (reject or quarantine) - >> collabora.com has quarantine. More information: > >> https://lore.kernel.org/alsa-devel/6f003598-4cae-a521-233f-2c19eb439359@per… > >> I am open to any suggestions, but the default mailman settings (do not do >> anything) causes that some (mostly gmail) users do not receive their e-mails >> because the ALSA's mail server has a bad reputation. Many companies are >> using the google mail service for their domains nowadays. > >> The information is not lost - the original e-mail is just encapsulated (as >> an attachmnent) to new with the "allowed from" header for DMARC. But yes, it >> requires some more work (reply to the attachment, update scripts). > > Copying in Konstantin - as I said this is massively disruptive to using > b4 with anything that's been mangled, to the point where the messages > are unusable without substantial manual mangling (and signature > verification fails too). It'd be more usable to just not have the > messages from the list getting to lore and manually bounce patches to > the list. The signature is correct in the encapsulated original e-mail. The b4 should be improved in my opinion. For example, here is the original message: https://lore.kernel.org/alsa-devel/168311377075.26.14919941665402646886@mai… As you see, the header and all signatures are correct in the attachment: From: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=collabora.com header.i=(a)collabora.com header.a=rsa-sha256 header.s=mail header.b=HSzFx8Gb > Is it possible to take steps to improve the reptuation of the ALSA > servers so this isn't needed, or could we migrate the lists elsewhere (I It is not possible to talk with gmail administrators. I tried that several times. The outgoing ALSA server is not on any spam list. > know we set up linux-sound@vger at one point with the idea of > migrating). I guess that the vger servers have similar issues, because servers with DMARC enabled on the ingress side can reject e-mails. It's related to e-mail standards. Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

2 5

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])
by Geraldo Nascimento 10 May '23

10 May '23

On Wed, May 10, 2023 at 11:05:59AM +0900, Mark Brown wrote: > AFAICT the only other option is munging the From without enclosing the > message in a wrapper? That's potentially marginally less harmful but > it's still going to break things badly enough that I'm not sure it's a > worthwhile improvement. The readymade mitigations for DMARC in mailman 3 are "munge_from" and "wrap_message". The fact "wrap_message" messes around with signatures in mutt is definitely not a good sign, and "munge_from" will change the author's email and name from the perspective of git-am. The middle way could be to patch mailman 3 to "munge_from" while adding the correct "From:" as the first thing in the body of the message if it doesn't contain one already. This will make git-am pickup the correct author's details and it should be some simple logic. If Jaroslav is brave enough to maintain this supposed patch to mailman 3 in case it doesn't get picked-up upstream by the FSF folks... I understand the maintainers needs must come first but it will be terrible to get the GMail bouncing behaviour again, I don't want to press the point since Jaroslav already made the speech I think it was needed. Thanks, Geraldo Nascimento

3 3

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]
by Takashi Iwai 10 May '23

10 May '23

On Thu, 04 May 2023 03:09:45 +0200, Mark Brown wrote: > > Hi, > > Here's another mail (one of several in this series) that got completely > mangled by the alsa-project.org mailman to the point of unusability. I > didn't see any response to my last mail about this, is there any news on > fixing mailman to not do this? It's extremely disruptive to working > with lore. It seems that alsa-project.org mailman re-sends the post with xxx(a)alsa-project.org address sometimes, indeed. I don't know the condition, but now I noticed it while checking the pending approvals. Those that appeared in the list wrongly were likely the posts I approved without knowing them being superfluously resent ones. Jaroslav, could you check your mailman configuration? thanks, Takashi > Thanks, > Mark > Subject: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe > From: AngeloGioacchino Del Regno via Alsa-devel <alsa-devel(a)alsa-project.org> > Date: Wed, 03 May 2023 13:34:11 +0200 > Message-Id: <168311377075.26.14919941665402646886(a)mailman-core.alsa-project.org> > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > > Use devm_pm_runtime_enable() and pm_runtime_resume_and_get() to > to simplify the probe function. > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> > --- > sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 22 ++++++++++++---------- > 1 file changed, 12 insertions(+), 10 deletions(-) > > diff --git a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c > index 9e45efeada55..a54c16e0aa05 100644 > --- a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c > +++ b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c > @@ -3179,16 +3179,16 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev) > > mt8195_afe_parse_of(afe, pdev->dev.of_node); > > - pm_runtime_enable(dev); > - if (!pm_runtime_enabled(dev)) { > - ret = mt8195_afe_runtime_resume(dev); > - if (ret) > - return ret; > - } > - > /* enable clock for regcache get default value from hw */ > afe_priv->pm_runtime_bypass_reg_ctl = true; > - pm_runtime_get_sync(dev); > + > + ret = devm_pm_runtime_enable(dev); > + if (ret) > + return ret; > + > + ret = pm_runtime_resume_and_get(dev); > + if (ret) > + return dev_err_probe(dev, ret, "Failed to resume device\n"); > > afe->regmap = devm_regmap_init_mmio(&pdev->dev, afe->base_addr, > &mt8195_afe_regmap_config); > @@ -3238,7 +3238,10 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev) > > mt8195_afe_init_registers(afe); > > - pm_runtime_put_sync(dev); > + ret = pm_runtime_put_sync(dev); > + if (ret) > + return dev_err_probe(dev, ret, "Failed to suspend device\n"); > + > afe_priv->pm_runtime_bypass_reg_ctl = false; > > regcache_cache_only(afe->regmap, true); > @@ -3248,7 +3251,6 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev) > > err_pm_put: > pm_runtime_put_sync(dev); > - pm_runtime_disable(dev); > > return ret; > } > -- > 2.40.1

4 6

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])
by Chen-Yu Tsai 10 May '23

10 May '23

On Wed, May 10, 2023 at 10:08 AM Mark Brown <broonie(a)kernel.org> wrote: > > On Tue, May 09, 2023 at 08:03:39PM +0200, Jaroslav Kysela wrote: > > On 09. 05. 23 16:35, Mark Brown wrote: > > > > It's not b4 that's the issue here except in that it causes me to fetch > > > copies of the message that went to the list instead of my inbox which > > > didn't get mangled by the list. git am just does not understand what's > > > b4 can detect, if the e-mail is wrapped and use only the wrapped message. > > The wrapping is the correct semantics per mailman 3 not mangling (see [1]). > > > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/d… > > As Konstantin pointed out this isn't entirely practical, especially with > the message ID rewriting breaking things. I suspect any mitigation here > would have to be on the archive side with it trying to unpack and > archive the enclosed message but that doesn't deal with all the issues. > > > > if I try to apply it the top of the commit message looks like: > > > > | commit 8f0e0ee514b189cf7b4e7fa09581e3f1d246fa09 (HEAD -> tmp) > > > | Author: Richard Fitzgerald via Alsa-devel <alsa-devel(a)alsa-project.org> > > > | Date: Thu Apr 20 11:20:43 2023 +0100 > > > > with all the headers dumped in there which is just completely mangled. > > > Note the rewritten author. > > > You should apply the wrapped message not the capsule. > > That's just not how any of the tooling works here, it is *possible* to > unpack things but it's really fighting against the tooling. > > > > mutt also represents this incredibly badly, it just shows the > > > "attachment" as the body of the message with all the headers dumped in > > > I think that you can configure the tool to process this attachment in mutt. > > I don't know off hand what that configuration would be, and in any case > it'd have knock on effects with reordering messages in the mailboxes > plus the overhead of having to open the mailbox to figure out if there's > any mangled messages in there. > > > > The issue I'm seeing here is the rewriting which I'm not aware of any > > > other lists having turned on, even infradead ones which are also mailman > > > based. Either they're just tolerating people having issues with gmail > > > (which seems reasonable TBH) or they're jumping through some additional > > > hoops to avoid issues. > > > I checked infradead and they're using mailman 2. Mailman 2 does not support > > DMARC mitigation. > > AFAICT that "mitigation" is actively harmful... > > > > I believe vger does sometimes manage some backchannel which probably > > > helps it somewhat. > > > Using a non-standard mechanism is not a big win. > > > DMARC is a internet standard - see RFC7489, RFC8616. It means that the > > mailing lists cannot send e-mails with From from other domains which have > > restricted policies set by *their* administrators. So basically, all mail > > I'm perfectly aware of what DMARC is, though I've not run a list server > since it became a thing. As far as I'm aware the backchannel stuff for > vger is more on the policy front (eg, with stuff like rate limit based > mitigations) and not anything to do with relaxing any standards based > security. > > > servers violates this if they keep the From header. Mailman 3 implemented > > several types of mitigations and the message wrap is the best one in my > > eyes. The mangling of the From header or reject e-mails from those senders > > is even worse (see [1]). > > AFAICT the only other option is munging the From without enclosing the > message in a wrapper? That's potentially marginally less harmful but > it's still going to break things badly enough that I'm not sure it's a > worthwhile improvement. > > > When I turn off the mitigation in mailman, my ALSA server will have bad > > reputation for gmail users soon in an unpredictable manner. I also saw that > > ATT incoming mail servers had similar issues. We can expect that the list of > > the ingress SMTP servers not accepting e-mails based on the DMARC policy > > will grow. It's something that we don't have under control. > > It's not quite that broken. > > > If we don't find that it's time to move forward and accept this policy, I > > can turn off the mitigation, but in a cost that gmail (and soon maybe other) > > users will bomb me (they already did last years) that the ALSA mail server > > does not deliver e-mails for them. Are we a community on internet or not? > > > Ideally, we should start upgrade and fix our tools... > > > Let me just know, if you (and Takashi) insist to turn the mitigation off > > after this discussion. I'll do so... > > I'd really like to see it turned off, in conjunction with the > suggestions from Konstantin for passing DMARC. As far as I can tell the > standards are not so broken as to be unusable, though any list is going > to have some issues with gmail due to things like people incorrectly > reporting spam (eg, when they want to unsubscribe or didn't realise what > sort of list they were signing up for), > > For the signatures thing IIRC even before this change to wrap things the > list server was mangling incoming siguatures, they'd typically not > verify if they came through the list - I never checked into it fully > since it was just something I had to be aware of but that's been there > since b4 had signature verification. I *think* ideally existing > signatures should be preserved, or a new one added if there is none. > That may well be more of the issue than anything else. Last time this topic was raised (on infradead), I talked to someone from Gmail. The ask was that originating servers implement DKIM signing, and intermediate servers, i.e. mailing lists, not mangle the signed fields. The latter includes not adding footers, and not re-emitting headers, which may alter the amount of whitespace, based on some of my experiments. ChenYu

1 0

Re: DMARC (Was: Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe])
by Jaroslav Kysela 09 May '23

09 May '23

On 09. 05. 23 16:35, Mark Brown wrote: > On Tue, May 09, 2023 at 11:54:18AM +0200, Jaroslav Kysela wrote: > >> The signature is correct in the encapsulated original e-mail. The b4 should >> be improved in my opinion. > > It's not b4 that's the issue here except in that it causes me to fetch > copies of the message that went to the list instead of my inbox which > didn't get mangled by the list. git am just does not understand what's b4 can detect, if the e-mail is wrapped and use only the wrapped message. The wrapping is the correct semantics per mailman 3 not mangling (see [1]). https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/d… > happening with attachments. For example for: > > 168198605952.26.13645408104113633580(a)mailman-core.alsa-project.org > > if I try to apply it the top of the commit message looks like: > > | commit 8f0e0ee514b189cf7b4e7fa09581e3f1d246fa09 (HEAD -> tmp) > | Author: Richard Fitzgerald via Alsa-devel <alsa-devel(a)alsa-project.org> > | Date: Thu Apr 20 11:20:43 2023 +0100 > | > | ASoC: cs35l56: Remove duplicate mbox log messages > | > | Received: by alsa1.perex.cz (Postfix, from userid 50401) > | id 7A47CF80155; Thu, 20 Apr 2023 12:20:56 +0200 (CEST) > | X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on alsa1.perex.cz > > with all the headers dumped in there which is just completely mangled. > Note the rewritten author. You should apply the wrapped message not the capsule. > mutt also represents this incredibly badly, it just shows the > "attachment" as the body of the message with all the headers dumped in > like they're just plain text in the body of the mail - I wouldn't have > thought this was an attachment if it hadn't been mentioned in this > thread, none of the atacment UI shows. To reverse the mangling you have > to view attachments then save the root of the message to a folder. AIUI > mutt assumes that whatever the root of the message is is intended to be > the message body and does the best it can to display it as such. I think that you can configure the tool to process this attachment in mutt. > Lore *does* show the body of the message as an attachment. Yes, the original message is in the attachment - no information is lost. >> As you see, the header and all signatures are correct in the attachment: > > None of our tooling or processes understand this, they're working with > the top level message. > >>> Is it possible to take steps to improve the reptuation of the ALSA >>> servers so this isn't needed, or could we migrate the lists elsewhere (I > >> It is not possible to talk with gmail administrators. I tried that several >> times. The outgoing ALSA server is not on any spam list. > > I know there is a lot of discussion going round about which hoops to > jump through to play nice with gmail, I don't know if there's any new > stuff that's come up there recently. > >>> know we set up linux-sound@vger at one point with the idea of >>> migrating). > >> I guess that the vger servers have similar issues, because servers with >> DMARC enabled on the ingress side can reject e-mails. It's related to e-mail >> standards. > > The issue I'm seeing here is the rewriting which I'm not aware of any > other lists having turned on, even infradead ones which are also mailman > based. Either they're just tolerating people having issues with gmail > (which seems reasonable TBH) or they're jumping through some additional > hoops to avoid issues. I checked infradead and they're using mailman 2. Mailman 2 does not support DMARC mitigation. > I believe vger does sometimes manage some backchannel which probably > helps it somewhat. Using a non-standard mechanism is not a big win. DMARC is a internet standard - see RFC7489, RFC8616. It means that the mailing lists cannot send e-mails with From from other domains which have restricted policies set by *their* administrators. So basically, all mail servers violates this if they keep the From header. Mailman 3 implemented several types of mitigations and the message wrap is the best one in my eyes. The mangling of the From header or reject e-mails from those senders is even worse (see [1]). When I turn off the mitigation in mailman, my ALSA server will have bad reputation for gmail users soon in an unpredictable manner. I also saw that ATT incoming mail servers had similar issues. We can expect that the list of the ingress SMTP servers not accepting e-mails based on the DMARC policy will grow. It's something that we don't have under control. If we don't find that it's time to move forward and accept this policy, I can turn off the mitigation, but in a cost that gmail (and soon maybe other) users will bomb me (they already did last years) that the ALSA mail server does not deliver e-mails for them. Are we a community on internet or not? Ideally, we should start upgrade and fix our tools... Let me just know, if you (and Takashi) insist to turn the mitigation off after this discussion. I'll do so... Jaroslav [1] https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/d… -- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

2 1

[PATCH] ASoC: SOF: amd: Fix NULL pointer crash in acp_sof_ipc_msg_data function
by V sujith kumar Reddy 09 May '23

09 May '23

Check substream and runtime variables before assigning. Signed-off-by: V sujith kumar Reddy <Vsujithkumar.Reddy(a)amd.com> --- sound/soc/sof/amd/acp-ipc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/sound/soc/sof/amd/acp-ipc.c b/sound/soc/sof/amd/acp-ipc.c index 4e0c48a36159..749e856dc601 100644 --- a/sound/soc/sof/amd/acp-ipc.c +++ b/sound/soc/sof/amd/acp-ipc.c @@ -209,7 +209,12 @@ int acp_sof_ipc_msg_data(struct snd_sof_dev *sdev, struct snd_sof_pcm_stream *sp acp_mailbox_read(sdev, offset, p, sz); } else { struct snd_pcm_substream *substream = sps->substream; - struct acp_dsp_stream *stream = substream->runtime->private_data; + struct acp_dsp_stream *stream; + + if (!substream || !substream->runtime) + return -ESTRPIPE; + + stream = substream->runtime->private_data; if (!stream) return -ESTRPIPE; -- 2.25.1

2 1

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]
by Geraldo Nascimento 08 May '23

08 May '23

On Mon, May 08, 2023 at 08:33:59AM +0900, Mark Brown wrote: > On Fri, May 05, 2023 at 11:17:19PM -0300, Geraldo Nascimento wrote: > > On Sat, May 06, 2023 at 09:13:06AM +0900, Mark Brown wrote: > > > > Not just the headers in the message, the author information for the mail > > > also got rewritten. Try applying the patches with git am... > > > Mark, I think Jaroslav can change the behaviour in the the added Headers in the > > body of the message (the added Headers in the body have e.g. the correct From: > > email information). > > > If the message body *starts* with the "From:", "Subject:" and "Date:" fields > > I think git-am will pickup the correct information from the body instead of from > > the mangled headers. > > > Hopefully... > > No, it absolutely doesn't work properly - I only noticed this was > happening because b4/lore keep picking the copy from alsa-devel which is > mangled to the point of not being usable. Hi Mark, sorry to hear that. The fact mailman is disrupting your workflow as ASoC maintainer is alarming, and I hope you and Jaroslav can work out a solution. But besides my suggestion that the added headers in the body of the message *start* with at least the correct "From:" field, I can't be of much help. Thanks for the hard work, Geraldo Nascimento

1 0

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]
by Geraldo Nascimento 06 May '23

06 May '23

On Sat, May 06, 2023 at 09:13:06AM +0900, Mark Brown wrote: > On Fri, May 05, 2023 at 05:38:28PM -0300, Geraldo Nascimento wrote: > > On Thu, May 04, 2023 at 10:09:45AM +0900, Mark Brown wrote: > > > > Here's another mail (one of several in this series) that got completely > > > mangled by the alsa-project.org mailman to the point of unusability. I > > > didn't see any response to my last mail about this, is there any news on > > > fixing mailman to not do this? It's extremely disruptive to working > > > with lore. > > > Are you complaining about the added headers in the message? Because the > > patch itself didn't look mangled from my side. From my understanding, > > Jaroslav had to start mangling mail addresses due to strict DMARC rules > > which make some servers reject the message from alsa-devel. > > Not just the headers in the message, the author information for the mail > also got rewritten. Try applying the patches with git am... Mark, I think Jaroslav can change the behaviour in the the added Headers in the body of the message (the added Headers in the body have e.g. the correct From: email information). If the message body *starts* with the "From:", "Subject:" and "Date:" fields I think git-am will pickup the correct information from the body instead of from the mangled headers. Hopefully... Good luck, Geraldo Nascimento

1 0

Re: [alsa-devel@alsa-project.org: [PATCH 3/5] ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe]
by Geraldo Nascimento 05 May '23

05 May '23

On Thu, May 04, 2023 at 10:09:45AM +0900, Mark Brown wrote: > Hi, > > Here's another mail (one of several in this series) that got completely > mangled by the alsa-project.org mailman to the point of unusability. I > didn't see any response to my last mail about this, is there any news on > fixing mailman to not do this? It's extremely disruptive to working > with lore. Hi Mark, Are you complaining about the added headers in the message? Because the patch itself didn't look mangled from my side. From my understanding, Jaroslav had to start mangling mail addresses due to strict DMARC rules which make some servers reject the message from alsa-devel. Thanks, Geraldo Nascimento > > Thanks, > Mark

1 0

Bad magic error when loading SOF firmware
by David Sayada 04 May '23

04 May '23

Hello SOF team, We are trying to evaluate the SOF project on our 8MPLUSSLPD4-EVK based product, and we are getting some issues when trying to run one of the "yocto compiled" SOF Firmware. Below is the procedure we are trying to perform: *echo /lib/firmware/imx/sof/sof-imx8m.ri > /sys/class/remoteproc/remoteproc0/firmware* *echo start > /sys/class/remoteproc/remoteproc0/state* We are getting, at the end, a "Image is corrupted (bad magic)" -22 return code. We have also created a VM (based on SOF 2.4.1) where we can compile (and sign, with default keys) the different toolchains and firmwares. Will that help in having a firmware run correctly? Maybe, we are doing incorrect things, if this is the case, please advise. Best regards, David Sayada.

2 5

[PATCH 0/5] ASoC: MediaTek MT8195/86 Cleanups
by AngeloGioacchino Del Regno 03 May '23

03 May '23

This series performs some cleanups for mainly MT8195 and switches both MT8195 and MT8186's SOF driver to the snd_sof_ipc_process_reply() helper. AngeloGioacchino Del Regno (5): ASoC: SOF: mediatek: mt8195: Use snd_sof_ipc_process_reply() helper ASoC: SOF: mediatek: mt8186: Use snd_sof_ipc_process_reply() helper ASoC: mediatek: mt8195-afe-pcm: Simplify runtime PM during probe ASoC: mediatek: mt8195-afe-pcm: Simplify with dev_err_probe() ASoC: mediatek: mt8195-afe-pcm: Clean up unnecessary functions sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 99 ++++++++-------------- sound/soc/sof/mediatek/mt8186/mt8186.c | 36 +------- sound/soc/sof/mediatek/mt8195/mt8195.c | 36 +------- 3 files changed, 36 insertions(+), 135 deletions(-) -- 2.40.1

3 9