linux-kernel - Re: [PATCH] mux: suppress lookup errors for mux controls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c0f63b8a-7197-050a-ca01-a1050a2e287e@axentia.se>
Date: Mon, 14 Apr 2025 15:18:03 +0200
From: Peter Rosin <peda@...ntia.se>
To: Johan Hovold <johan+linaro@...nel.org>
Cc: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
 Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
 Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mux: suppress lookup errors for mux controls

Hi!

2025-04-14 at 14:42, Johan Hovold wrote:
> Since commit eec611d26f84 ("ASoC: codecs: wcd938x: add mux control
> support for hp audio mux") we have drivers looking up mux controls that
> are optional. This results in errors incorrectly being logged on
> machines like the Lenovo ThinkPad X13s where the mux is missing:
> 
>     wcd938x_codec audio-codec: /audio-codec: failed to get mux-control (0)
> 
> Suppress the error message when lookup of mux controls fails and make
> sure to return -ENOENT consistently also when looking up controls by
> name so that consumer drivers can easily determine how to proceed.
> 
> Note that most current consumers already log mux lookup failures
> themselves.
> 
> Fixes: eec611d26f84 ("ASoC: codecs: wcd938x: add mux control support for hp audio mux")
> Link: https://lore.kernel.org/lkml/Z-z_ZAyVBK5ui50k@hovoldconsulting.com/
> Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
> ---
>  drivers/mux/core.c | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mux/core.c b/drivers/mux/core.c
> index 02be4ba37257..b95bc03e3d6b 100644
> --- a/drivers/mux/core.c
> +++ b/drivers/mux/core.c
> @@ -544,8 +544,13 @@ static struct mux_control *mux_get(struct device *dev, const char *mux_name,
>  			index = of_property_match_string(np, "mux-control-names",
>  							 mux_name);
>  		if (index < 0) {
> -			dev_err(dev, "mux controller '%s' not found\n",
> -				mux_name);
> +			if (!state && index == -EINVAL)
> +				index = -ENOENT;

Why exclude states? For me, that's entirely random and inconsistent. If there's
a reason to exclude them, I'd like to hear about it. If there is no reason and
this is just defensive programming, then I'd like for someone to dig into it
and either find a reason for the difference or clean up the inconsistency.

I think the model of explicitly marking when you'd like a mux to be optional
is a better and less fragile model. Who is to say that -EINVAL from some other
call is, and will remain, a perfect match for the optional case you are aiming
for?

Srinivas Kandagatla is looking into optional muxes as a side issue to
exclusive muxes.
https://lore.kernel.org/all/20250326154613.3735-1-srinivas.kandagatla@linaro.org/

Cheers,
Peter

> +
> +			if (index != -ENOENT) {
> +				dev_err(dev, "mux controller '%s' not found\n",
> +					mux_name);
> +			}
>  			return ERR_PTR(index);
>  		}
>  	}
> @@ -559,8 +564,11 @@ static struct mux_control *mux_get(struct device *dev, const char *mux_name,
>  						 "mux-controls", "#mux-control-cells",
>  						 index, &args);
>  	if (ret) {
> -		dev_err(dev, "%pOF: failed to get mux-%s %s(%i)\n",
> -			np, state ? "state" : "control", mux_name ?: "", index);
> +		if (state || ret != -ENOENT) {
> +			dev_err(dev, "%pOF: failed to get mux-%s %s(%i)\n",
> +				np, state ? "state" : "control",
> +				mux_name ?: "", index);
> +		}
>  		return ERR_PTR(ret);
>  	}
>