sound/soc/codecs/lpass-rx-macro.c | 1 - sound/soc/codecs/lpass-tx-macro.c | 1 - sound/soc/codecs/lpass-va-macro.c | 1 - sound/soc/codecs/lpass-wsa-macro.c | 1 - 4 files changed, 4 deletions(-)
All four Qualcomm SoC macro codecs define DAI IDs in an enum starting
with AIF_INVALID=0, which is nowhere used in the code thus actual DAI
IDs start from 1. Drivers do not have their own of_xlate_dai_name(),
thus snd_soc_get_dlc() expects the DTS to start numbering DAIs from 0,
which creates confusing debugging scenario, e.g. DTS should use
<&lpass_wsamacro 2> for WSA_MACRO_AIF_VI with dai->id=3.
This also wastes some space, because drivers allocate few arrays for all
DAIs and basically the [0] is never used.
Drop the confusing first AIF_INVALID DAI identifier so the enum with DAI
IDs will start from 0. This has little functional impact and does not
affect the ABI, except saving a few bytes of memory per driver.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
sound/soc/codecs/lpass-rx-macro.c | 1 -
sound/soc/codecs/lpass-tx-macro.c | 1 -
sound/soc/codecs/lpass-va-macro.c | 1 -
sound/soc/codecs/lpass-wsa-macro.c | 1 -
4 files changed, 4 deletions(-)
diff --git a/sound/soc/codecs/lpass-rx-macro.c b/sound/soc/codecs/lpass-rx-macro.c
index 45a6b83808b2..238dbdb46c18 100644
--- a/sound/soc/codecs/lpass-rx-macro.c
+++ b/sound/soc/codecs/lpass-rx-macro.c
@@ -619,7 +619,6 @@ static struct interp_sample_rate sr_val_tbl[] = {
};
enum {
- RX_MACRO_AIF_INVALID = 0,
RX_MACRO_AIF1_PB,
RX_MACRO_AIF2_PB,
RX_MACRO_AIF3_PB,
diff --git a/sound/soc/codecs/lpass-tx-macro.c b/sound/soc/codecs/lpass-tx-macro.c
index 27bae58f4072..40d79bee4584 100644
--- a/sound/soc/codecs/lpass-tx-macro.c
+++ b/sound/soc/codecs/lpass-tx-macro.c
@@ -208,7 +208,6 @@
#define MCLK_FREQ 19200000
enum {
- TX_MACRO_AIF_INVALID = 0,
TX_MACRO_AIF1_CAP,
TX_MACRO_AIF2_CAP,
TX_MACRO_AIF3_CAP,
diff --git a/sound/soc/codecs/lpass-va-macro.c b/sound/soc/codecs/lpass-va-macro.c
index 74ada6e77526..a49551f3fb29 100644
--- a/sound/soc/codecs/lpass-va-macro.c
+++ b/sound/soc/codecs/lpass-va-macro.c
@@ -165,7 +165,6 @@
static const DECLARE_TLV_DB_SCALE(digital_gain, -8400, 100, -8400);
enum {
- VA_MACRO_AIF_INVALID = 0,
VA_MACRO_AIF1_CAP,
VA_MACRO_AIF2_CAP,
VA_MACRO_AIF3_CAP,
diff --git a/sound/soc/codecs/lpass-wsa-macro.c b/sound/soc/codecs/lpass-wsa-macro.c
index c1fb71cfb5d0..da6adb3de21d 100644
--- a/sound/soc/codecs/lpass-wsa-macro.c
+++ b/sound/soc/codecs/lpass-wsa-macro.c
@@ -369,7 +369,6 @@ static struct interp_sample_rate int_mix_sample_rate_val[] = {
};
enum {
- WSA_MACRO_AIF_INVALID = 0,
WSA_MACRO_AIF1_PB,
WSA_MACRO_AIF_MIX1_PB,
WSA_MACRO_AIF_VI,
--
2.45.2
On Fri, 23 May 2025 14:18:12 +0200, Krzysztof Kozlowski wrote:
> All four Qualcomm SoC macro codecs define DAI IDs in an enum starting
> with AIF_INVALID=0, which is nowhere used in the code thus actual DAI
> IDs start from 1. Drivers do not have their own of_xlate_dai_name(),
> thus snd_soc_get_dlc() expects the DTS to start numbering DAIs from 0,
> which creates confusing debugging scenario, e.g. DTS should use
> <&lpass_wsamacro 2> for WSA_MACRO_AIF_VI with dai->id=3.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: codecs: lpass: Drop unused AIF_INVALID first DAI identifier
commit: bb4a0f497bc19558ba7fe9feac814286fc7ebe85
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
© 2016 - 2025 Red Hat, Inc.