Messages in this thread | | | Date | Fri, 6 Dec 2013 01:50:51 +0300 | From | Dan Carpenter <> | Subject | Re: [PATCH] staging: silicom: fix 'return is not a function, parentheses are not required' in bpctl_mod.c |
| |
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
| |