Re: [PATCH] staging: silicom: fix 'return is not a function, parentheses are not required' in bpctl_mod.c

[Dan Carpenter <dan.carpenter@oracle.com>]

On Thu, Dec 05, 2013 at 10:23:53PM +0100, Will Tange wrote:
> Fixes warnings regarding redundant parantheses thrown by the checkpatch tool in bpctl_mod.c
> 

Fair enough, but if you wanted to go clean the returns up further then
you could.  Remove all the "!= 0" bits.

> @@ -3125,11 +3125,11 @@ static int tx_status(struct bpctl_dev *pbpctl_dev)
>  
>  		ctrl = BPCTL_READ_REG(pbpctl_dev, CTRL);
>  		if (pbpctl_dev->bp_i80)
> -			return ((ctrl & BPCTLI_CTRL_SWDPIN1) != 0 ? 0 : 1);
> +			return (ctrl & BPCTLI_CTRL_SWDPIN1) != 0 ? 0 : 1;

The double negative just makes the code not as not confusing as it could
be.  Simpler:

			return (ctrl & BPCTLI_CTRL_SWDPIN1) ? 0 : 1;

>  
>  	if ((pbpctl_dev->bp_caps & BP_CAP)) {
>  		if (pbpctl_dev->bp_ext_ver >= PXG2BPI_VER) {
> -			return ((((read_reg(pbpctl_dev, STATUS_REG_ADDR)) &
> +			return (((read_reg(pbpctl_dev, STATUS_REG_ADDR)) &
>  				  BYPASS_FLAG_MASK) ==
> -				 BYPASS_FLAG_MASK) ? 1 : 0);
> +				 BYPASS_FLAG_MASK) ? 1 : 0;

These super long lines would be better if we introduced a temporary
variable.
			reg = read_reg(pbpctl_dev, STATUS_REG_ADDR);
			return (reg & BYPASS_FLAG_MASK) == BYPASS_FLAG_MASK;

BYPASS_FLAG_MASK is poorly named.  It's actually just a bit or a flag
and not a mask, so it could be renamed.

			reg = read_reg(pbpctl_dev, STATUS_REG_ADDR);
			return (reg & BP_BYPASS_FLAG) ? 1 : 0;

Which is way simpler than the original and only 2 lines long instead of
4.  I don't know that "BP_" is the right prefix...  BYPASS_FLAG is too
generic.

> @@ -4730,7 +4730,7 @@ int get_disc_pwup_fn(struct bpctl_dev *pbpctl_dev)
>  		return -1;
>  
>  	ret = default_pwron_disc_status(pbpctl_dev);
> -	return (ret == 0 ? 1 : (ret < 0 ? BP_NOT_CAP : 0));
> +	return ret == 0 ? 1 : (ret < 0 ? BP_NOT_CAP : 0);


	if (ret < 0)
		return BP_NOT_CAP;
	if (ret == 0)
		return 1;
	return 0;

More lines, but simpler to understand than the original.

Think of checkpatch.pl as a pointer to bad code and not that we just
have to silence checkpatch and move on.

regards,
dan carpenter