From: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
To: Zhang Yi <zhangyi@everest-semi.com>,
broonie@kernel.org, tiwai@suse.com, linux-sound@vger.kernel.org
Cc: peter.ujfalusi@linux.intel.com, yung-chuan.liao@linux.intel.com,
ranjani.sridharan@linux.intel.com, kai.vehmanen@linux.intel.com
Subject: Re: [PATCH v2 3/6] ASoC: sdw_utils: add soc_sdw_es9356
Date: Wed, 11 Mar 2026 20:55:13 -0700 [thread overview]
Message-ID: <e190aa72-9e1e-45de-951e-695f99e6111a@linux.dev> (raw)
In-Reply-To: <20260226073534.3347-4-zhangyi@everest-semi.com>
On 2/25/26 23:35, Zhang Yi wrote:
> Add a utility program for handling ES9356 in the universal machine driver
>
> Signed-off-by: Zhang Yi <zhangyi@everest-semi.com>
> ---
> sound/soc/sdw_utils/Makefile | 1 +
> sound/soc/sdw_utils/soc_sdw_es9356.c | 275 +++++++++++++++++++++++++++
> 2 files changed, 276 insertions(+)
> create mode 100644 sound/soc/sdw_utils/soc_sdw_es9356.c
>
> diff --git a/sound/soc/sdw_utils/Makefile b/sound/soc/sdw_utils/Makefile
> index e8bd5ffb1..f47b0cada 100644
> --- a/sound/soc/sdw_utils/Makefile
> +++ b/sound/soc/sdw_utils/Makefile
> @@ -7,6 +7,7 @@ snd-soc-sdw-utils-y := soc_sdw_utils.o soc_sdw_dmic.o soc_sdw_rt_dmic.o \
> soc_sdw_cs42l42.o soc_sdw_cs42l43.o \
> soc_sdw_cs42l45.o \
> soc_sdw_cs_amp.o \
> + soc_sdw_es9356.o \
> soc_sdw_maxim.o \
> soc_sdw_ti_amp.o
> obj-$(CONFIG_SND_SOC_SDW_UTILS) += snd-soc-sdw-utils.o
> diff --git a/sound/soc/sdw_utils/soc_sdw_es9356.c b/sound/soc/sdw_utils/soc_sdw_es9356.c
> new file mode 100644
> index 000000000..d6649f0e9
> --- /dev/null
> +++ b/sound/soc/sdw_utils/soc_sdw_es9356.c
> @@ -0,0 +1,275 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright (c) 2020 Intel Corporation
this doesn't seem right, and I mentioned it in the previous review...
> +int asoc_sdw_es9356_amp_init(struct snd_soc_card *card,
> + struct snd_soc_dai_link *dai_links,
> + struct asoc_sdw_codec_info *info,
> + bool playback)
> +{
> + struct asoc_sdw_mc_private *ctx = snd_soc_card_get_drvdata(card);
> + struct device *sdw_dev1, *sdw_dev2;
> + int ret;
> +
> + if (!playback)
> + return 0;
> +
> + info->amp_num++;
> +
> + if (info->amp_num == 2) {
> + sdw_dev1 = bus_find_device_by_name(&sdw_bus_type, NULL, dai_links->codecs[0].name);
> +
> + if (!sdw_dev1)
> + return -EPROBE_DEFER;
> +
> + ret = es9356_add_codec_device_props(sdw_dev1, ctx->mc_quirk);
> + if (ret < 0) {
> + put_device(sdw_dev1);
> + return ret;
> + }
> + ctx->amp_dev1 = sdw_dev1;
> +
> + sdw_dev2 = bus_find_device_by_name(&sdw_bus_type, NULL, dai_links->codecs[1].name);
> +
> + if (!sdw_dev2)
> + return -EPROBE_DEFER;
that doesn't seem right, since you've already added stuff for sdw_dev1.
> +
> + ret = es9356_add_codec_device_props(sdw_dev2, ctx->mc_quirk);
> + if (ret < 0) {
> + put_device(sdw_dev2);
this error handling seems weird, shouldn't you also do a put_device(sdw_dev1) here?
maybe the right thing is to check that both sdw_dev1 and sdw_dev2 can be found.
Then you can add properties for both.
I didn't find any other example of code where we deal with two sets of properties.
> + return ret;
> + }
> + ctx->amp_dev2 = sdw_dev2;
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL_NS(asoc_sdw_es9356_amp_init, "SND_SOC_SDW_UTILS");
next prev parent reply other threads:[~2026-03-12 4:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 7:35 [PATCH v2 0/6] Add es9356 focused SoundWire CODEC Zhang Yi
2026-02-26 7:35 ` [PATCH v2 1/6] ASoC: sdw_utils: Add ES9356 support functions Zhang Yi
2026-02-26 7:35 ` [PATCH v2 2/6] ASoC: sdw_utils: add ES9356 in codec_info_list Zhang Yi
2026-02-26 7:35 ` [PATCH v2 3/6] ASoC: sdw_utils: add soc_sdw_es9356 Zhang Yi
2026-03-12 3:55 ` Pierre-Louis Bossart [this message]
2026-02-26 7:35 ` [PATCH v2 4/6] ASoC: es9356-sdca: Add ES9356 SDCA driver Zhang Yi
2026-03-12 4:14 ` Pierre-Louis Bossart
2026-03-12 13:55 ` Mark Brown
2026-02-26 7:35 ` [PATCH v2 5/6] ASoC: Intel: soc-acpi: arl: Add es9356 support Zhang Yi
2026-02-26 7:35 ` [PATCH v2 6/6] ASoC: Intel: sof_sdw: add " Zhang Yi
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=e190aa72-9e1e-45de-951e-695f99e6111a@linux.dev \
--to=pierre-louis.bossart@linux.dev \
--cc=broonie@kernel.org \
--cc=kai.vehmanen@linux.intel.com \
--cc=linux-sound@vger.kernel.org \
--cc=peter.ujfalusi@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=tiwai@suse.com \
--cc=yung-chuan.liao@linux.intel.com \
--cc=zhangyi@everest-semi.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.