Linux kernel staging patches
 help / color / mirror / Atom feed
From: Dan Carpenter <error27@gmail.com>
To: abdelnasser hussein <abdelnasserhussein11@gmail.com>
Cc: Vaibhav Agarwal <vaibhav.sr@gmail.com>,
	Mark Greer <mgreer@animalcreek.com>,
	Johan Hovold <johan@kernel.org>, Alex Elder <elder@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v2] staging: greybus: audio: check sscanf() result directly
Date: Mon, 15 Jun 2026 10:21:18 +0300	[thread overview]
Message-ID: <ai-n7jNPT862Wscj@stanley.mountain> (raw)
In-Reply-To: <20260614060857.15366-1-abdelnasserhussein11@gmail.com>

On Sun, Jun 14, 2026 at 09:08:57AM +0300, abdelnasser hussein wrote:
> Smatch warns:
> 
>   drivers/staging/greybus/audio_codec.c:335 gbaudio_module_update()
>   warn: sscanf doesn't return error codes
> 
> sscanf() returns the number of successfully matched input items, not a
> negative error code. Compare the return value directly with the expected
> number of conversions instead of storing it in ret as an error code.
> 
> Also remove the redundant else-if check for snd_soc_dapm_aif_out. The
> widget id is validated earlier in the function, so the remaining branch
> can only handle snd_soc_dapm_aif_out. This avoids a compiler warning
> about a potentially uninitialized variable.
> 
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202606140347.gGVWDnbi-lkp@intel.com/
> 
> Signed-off-by: abdelnasser hussein <abdelnasserhussein11@gmail.com>
> ---

This static checker warning is triggered when we propagate the return
from sscanf().

>  drivers/staging/greybus/audio_codec.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/greybus/audio_codec.c b/drivers/staging/greybus/audio_codec.c
> index 720aa752e17e..6daa4e706792 100644
> --- a/drivers/staging/greybus/audio_codec.c
> +++ b/drivers/staging/greybus/audio_codec.c
> @@ -311,8 +311,7 @@ int gbaudio_module_update(struct gbaudio_codec_info *codec,
>  	}
>  
>  	/* parse dai_id from AIF widget's stream_name */
> -	ret = sscanf(w->sname, "%s %d %s", intf_name, &dai_id, dir);
> -	if (ret < 3) {
> +	if (sscanf(w->sname, "%s %d %s", intf_name, &dai_id, dir) != 3) {
>  		dev_err(codec->dev, "Error while parsing dai_id for %s\n", w->name);
>  		return -EINVAL;

So this code is fine as-is since it's returning -EINVAL.

>  	}
> @@ -323,7 +322,7 @@ int gbaudio_module_update(struct gbaudio_codec_info *codec,
>  			ret = gbaudio_module_enable_tx(codec, module, dai_id);
>  		else
>  			ret = gbaudio_module_disable_tx(module, dai_id);
> -	} else if (w->id == snd_soc_dapm_aif_out) {
> +	} else {

Yes, this is what the static checker is complaining about.  It thinks
that the if statement might be false.  But to a human reader, the
else if or the plain else are equivalent.  It's just a style choice
which way to write it.

I would just leave this as-is since the original code is fine.  To be
honest, most old static checker warnings are stuff that someone
already decided to leave as is.

It's better to write new checks.  Just look for simple fixes in git
log and then you can vibe code a check.  Better to work against the
devel branch of smatch.

regards,
dan carpenter

>  		if (enable)
>  			ret = gbaudio_module_enable_rx(codec, module, dai_id);
>  		else



  parent reply	other threads:[~2026-06-15  7:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-14  6:08 [PATCH v2] staging: greybus: audio: check sscanf() result directly abdelnasser hussein
2026-06-14  6:15 ` Greg Kroah-Hartman
2026-06-14  8:42   ` nasser
2026-06-15  7:21 ` Dan Carpenter [this message]
2026-06-15  7:40   ` nasser

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=ai-n7jNPT862Wscj@stanley.mountain \
    --to=error27@gmail.com \
    --cc=abdelnasserhussein11@gmail.com \
    --cc=elder@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=greybus-dev@lists.linaro.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=lkp@intel.com \
    --cc=mgreer@animalcreek.com \
    --cc=vaibhav.sr@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox