Re: [PATCH] media: dvb-frontends/cxd2099: report errors

[Mauro Carvalho Chehab]

Em Wed, 22 Jul 2020 06:41:26 -0700
trix@xxxxxxxxxx escreveu:

> From: Tom Rix <trix@xxxxxxxxxx>
> 
> Clang static analysis reports this error
> 
> drivers/media/dvb-frontends/cxd2099.c:420:2: warning: Undefined
>   or garbage value returned to caller
>         return val;
>         ^~~~~~~~~~
> 
> In read_cam_control, the call to read_io can fail.
> When it fails val is not set.
> 
> The failure status should be returned to the caller,
> not the unset val.
> 
> Similar problem with read_attribute_mem
> 
> Fixes: 0f0b270f905b ("[media] ngene: CXD2099AR Common Interface driver")
> 
> Signed-off-by: Tom Rix <trix@xxxxxxxxxx>
> ---
>  drivers/media/dvb-frontends/cxd2099.c | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/dvb-frontends/cxd2099.c b/drivers/media/dvb-frontends/cxd2099.c
> index f88b5355493e..9dfaf18fc4b4 100644
> --- a/drivers/media/dvb-frontends/cxd2099.c
> +++ b/drivers/media/dvb-frontends/cxd2099.c
> @@ -387,12 +387,15 @@ static int read_attribute_mem(struct dvb_ca_en50221 *ca,
>  {
>  	struct cxd *ci = ca->data;
>  	u8 val;
> +	int ret;
>  
>  	mutex_lock(&ci->lock);
>  	set_mode(ci, 1);
> -	read_pccard(ci, address, &val, 1);
> +	ret = read_pccard(ci, address, &val, 1);
> +	if (!ret)
> +		ret = val;
>  	mutex_unlock(&ci->lock);
> -	return val;
> +	return ret;
>  }
>  
>  static int write_attribute_mem(struct dvb_ca_en50221 *ca, int slot,
> @@ -412,12 +415,15 @@ static int read_cam_control(struct dvb_ca_en50221 *ca,
>  {
>  	struct cxd *ci = ca->data;
>  	unsigned int val;
> +	int ret;
>  
>  	mutex_lock(&ci->lock);
>  	set_mode(ci, 0);
> -	read_io(ci, address, &val);
> +	ret = read_io(ci, address, &val);
> +	if (!ret)
> +		ret = val;
>  	mutex_unlock(&ci->lock);
> -	return val;
> +	return ret;
>  }
>  
>  static int write_cam_control(struct dvb_ca_en50221 *ca, int slot,

Hmm... Had you test this one on a real hardware? It is not
uncommon to have some DVB devices that would fail reading
when the firmware is on cold state.

Without testing a patch like that at a real hardware, there's
no way to know if this is intentional or if the original
developer forgot to add a check for the error.

So, at most, it could print some warning message for
non-zero return codes.


Thanks,
Mauro