When we fail to look up the control name in snd_soc_limit_volume() we don't
log anything, the error code isn't particularly descriptive and checking
the return value of the function at all is a bit erratic among the callers.
Since there is no reason why anyone should ever be attempting to limit the
volume of a nonexistant control add a log message in the core to improve
usability.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
 sound/soc/soc-ops.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c
index f966d4e13c7f..94e28fc780a5 100644
--- a/sound/soc/soc-ops.c
+++ b/sound/soc/soc-ops.c
@@ -503,6 +503,9 @@ int snd_soc_limit_volume(struct snd_soc_card *card, const char *name, int max)
 			mc->platform_max = max;
 			ret = snd_soc_clip_to_platform_max(kctl);
 		}
+	} else {
+		dev_warn(card->dev, "Volume limit for unknown control '%s'\n",
+			 name);
 	}
 
 	return ret;

---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260421-asoc-limit-volume-error-ca28188dc7c9

Best regards,
--  
Mark Brown <broonie@kernel.org>

On Tue, Apr 21, 2026 at 10:02 PM Mark Brown <broonie@kernel.org> wrote:
>
> When we fail to look up the control name in snd_soc_limit_volume() we don't
> log anything, the error code isn't particularly descriptive and checking
> the return value of the function at all is a bit erratic among the callers.
> Since there is no reason why anyone should ever be attempting to limit the
> volume of a nonexistant control add a log message in the core to improve
> usability.

Can confirm this works as expected for the case we discussed
previously. With this I get:

[   19.585906] snd-x1e80100 sound: Volume limit for unknown control
'WSA_RX0 Digital Volume'
[   19.585909] snd-x1e80100 sound: Volume limit for unknown control
'WSA_RX1 Digital Volume'

One thing I'd be worried about though is the number of false positives
this might generate.
The x1e80100 patch we discussed previously handles a  2-speaker and a
4-speaker configuration
by unconditionally adding limits for all of them. Previously the
missing ones didn't really matter with
this they also print warnings.

>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  sound/soc/soc-ops.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c
> index f966d4e13c7f..94e28fc780a5 100644
> --- a/sound/soc/soc-ops.c
> +++ b/sound/soc/soc-ops.c
> @@ -503,6 +503,9 @@ int snd_soc_limit_volume(struct snd_soc_card *card, const char *name, int max)
>                         mc->platform_max = max;
>                         ret = snd_soc_clip_to_platform_max(kctl);
>                 }
> +       } else {
> +               dev_warn(card->dev, "Volume limit for unknown control '%s'\n",
> +                        name);
>         }
>
>         return ret;
>
> ---
> base-commit: 028ef9c96e96197026887c0f092424679298aae8
> change-id: 20260421-asoc-limit-volume-error-ca28188dc7c9
>
> Best regards,
> --
> Mark Brown <broonie@kernel.org>
>

On Wed, Apr 22, 2026 at 12:09:33AM +0200, Tobias Heider wrote:

> One thing I'd be worried about though is the number of false positives
> this might generate.
> The x1e80100 patch we discussed previously handles a  2-speaker and a
> 4-speaker configuration
> by unconditionally adding limits for all of them. Previously the
> missing ones didn't really matter with
> this they also print warnings.

Right.  Ideally the card would know what it was registering but perhaps
that's more trouble than it's worth.  I'll split the difference and
lower the print to a dev_dbg().