[PATCH] ASoC: SOF: topology: Use more common error handling code in sof_link_load()

[PATCH] ASoC: SOF: topology: Use more common error handling code in sof_link_load()

[Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
Date: Wed, 17 Jun 2026 09:33:45 +0200

Use an additional label so that a bit of exception handling can be better
reused at the end of this function implementation.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
 sound/soc/sof/topology.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
index 8fc7726aec29..999eeea2f512 100644
--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -1940,8 +1940,7 @@ static int sof_link_load(struct snd_soc_component *scomp, int index, struct snd_
 			       private->array, le32_to_cpu(private->size));
 	if (ret < 0) {
 		dev_err(scomp->dev, "Failed tp parse common DAI link tokens\n");
-		kfree(slink);
-		return ret;
+		goto free_slink;
 	}
 
 	token_list = tplg_ops ? tplg_ops->token_list : NULL;
@@ -2010,8 +2009,8 @@ static int sof_link_load(struct snd_soc_component *scomp, int index, struct snd_
 	/* allocate memory for tuples array */
 	slink->tuples = kzalloc_objs(*slink->tuples, num_tuples);
 	if (!slink->tuples) {
-		kfree(slink);
-		return -ENOMEM;
+		ret = -ENOMEM;
+		goto free_slink;
 	}
 
 	if (token_list[SOF_DAI_LINK_TOKENS].tokens) {
@@ -2067,6 +2066,7 @@ static int sof_link_load(struct snd_soc_component *scomp, int index, struct snd_
 
 err:
 	kfree(slink->tuples);
+free_slink:
 	kfree(slink);
 
 	return ret;
-- 
2.54.0

Re: [PATCH] ASoC: SOF: topology: Use more common error handling code in sof_link_load()

[Mark Brown]

On Wed, 17 Jun 2026 09:56:22 +0200, Markus Elfring wrote:
> ASoC: SOF: topology: Use more common error handling code in sof_link_load()

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.3

Thanks!

[1/1] ASoC: SOF: topology: Use more common error handling code in sof_link_load()
      https://git.kernel.org/broonie/sound/c/a33e6fa400d1

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

Re: ASoC: SOF: topology: Use more common error handling code in sof_link_load()

[Markus Elfring]

>> ASoC: SOF: topology: Use more common error handling code in sof_link_load()
> 
> Applied to
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.3
> 
> Thanks!
> 
> [1/1] ASoC: SOF: topology: Use more common error handling code in sof_link_load()
>       https://git.kernel.org/broonie/sound/c/a33e6fa400d1
Thanks for another bit of positive feedback.


Will the chances grow that further development ideas also from my change selection
can be integrated better?

Examples:
* ASoC: SOF: topology: Replace devm_kasprintf() call by devm_kstrdup() in sof_copy_tuples()
  2025-04-16
  https://patchwork.kernel.org/project/alsa-devel/patch/3e473ff5-1554-4065-a305-6b3661e0b941@web.de/

* ASoC: SOF: topology: Move a variable assignment behind condition checks in sof_dai_load()
  2023-04-13
  https://patchwork.kernel.org/project/alsa-devel/patch/46d8e10e-25dc-dfd7-3e39-92b86058126a@web.de/


Regards,
Markus

Re: ASoC: SOF: topology: Use more common error handling code in sof_link_load()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Tue, Jun 30, 2026 at 07:08:39PM +0200, Markus Elfring wrote:

> Will the chances grow that further development ideas also from my change selection
> can be integrated better?

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: ASoC: SOF: topology: Use more common error handling code in sof_link_load()

[Markus Elfring]

>> Will the chances grow that further development ideas also from my change selection
>> can be integrated better?
> 
> Please don't send content free pings

How did you come to such a view after I dared to present reminders
for two concrete patches which can eventually be taken better into account
also by known patchwork interfaces?


>                                      and please allow a reasonable time
> for review.

Some years passed accordingly.


> Sending content free pings adds to the mail volume (if they are seen at
> all) which is often the problem and since they can't be reviewed
> directly if something has gone wrong you'll have to resend the patches
> anyway, so sending again is generally a better approach though there are
> some other maintainers who like them - if in doubt look at how patches
> for the subsystem are normally handled.
I hope that remaining development ideas can occasionally be handled in
more constructive ways.

Regards,
Markus