From: linux@roeck-us.net (Guenter Roeck)
To: cocci@systeme.lip6.fr
Subject: [Cocci] [PATCH v2 2/2] hwmon: npcm750: add NPCM7xx PWM and Fan driver
Date: Wed, 20 Jun 2018 12:38:06 -0700 [thread overview]
Message-ID: <20180620193806.GA2054@roeck-us.net> (raw)
In-Reply-To: <a6a5a21236c37cfc63329e54248d941bf6d49e3c.camel@perches.com>
On Wed, Jun 20, 2018 at 11:25:08AM -0700, Joe Perches wrote:
> (adding Julia Lawall and cocci mailing list)
>
> On Wed, 2018-06-20 at 09:48 -0700, Guenter Roeck wrote:
> []
> > > +static inline void npcm7xx_fan_start_capture(struct npcm7xx_pwm_fan_data *data,
> > > + u8 fan, u8 cmp)
> > > +{
> > > + u8 fan_id = 0;
> > > + u8 reg_mode = 0;
> > > + u8 reg_int = 0;
> > > + unsigned long flags;
> > > +
> > > + fan_id = NPCM7XX_FAN_INPUT(fan, cmp);
> > > +
> > > + /* to check whether any fan tach is enable */
> > > + if (data->npcm7xx_fan[fan_id].FanStFlag != FAN_DISABLE) {
> > > + /* reset status */
> > > + spin_lock_irqsave(&data->npcm7xx_fan_lock[fan], flags);
> > > +
> > > + data->npcm7xx_fan[fan_id].FanStFlag = FAN_INIT;
> > > + reg_int = ioread8(NPCM7XX_FAN_REG_TIEN(data->fan_base, fan));
> > > +
> > > + if (cmp == NPCM7XX_FAN_CMPA) {
> > > + /* enable interrupt */
> > > + iowrite8((u8) (reg_int | (NPCM7XX_FAN_TIEN_TAIEN |
> > > + NPCM7XX_FAN_TIEN_TEIEN)),
> >
> > Is the (u8) typecast really necessary ? Seems unlikely.
>
> The cast is not really necessary here as there would
> be an implicit cast already.
>
> Some might complain about loss of type safety and
> "make W=123" would probably emit something here.
>
I spent (wasted) some time browsing through the kernel.
Similar typecasts are only used if there is a real type change.
A warning here would not make sense unless NPCM7XX_FAN_TIEN_TAIEN
or NPCM7XX_FAN_TIEN_TEIEN would be outside the u8 range, and then
there would be one anyway.
So, no, I am not going to accept those typecasts. They just make the code
more difficult to read. For example, the code here could have been
simplified to something like
reg_int = ioread8(NPCM7XX_FAN_REG_TIEN(data->fan_base, fan));
reg_mode = ioread8(NPCM7XX_FAN_REG_TCKC(data->fan_base, fan));
if (cmp == NPCM7XX_FAN_CMPA) {
reg_int |= NPCM7XX_FAN_TIEN_TAIEN | NPCM7XX_FAN_TIEN_TEIEN;
reg_mode |= NPCM7XX_FAN_TCKC_CLK1_APB;
} else {
reg_int |= NPCM7XX_FAN_TIEN_TBIEN | NPCM7XX_FAN_TIEN_TFIEN;
reg_mode |= NPCM7XX_FAN_TCKC_CLK2_APB;
}
iowrite8(reg_int, NPCM7XX_FAN_REG_TIEN(data->fan_base, fan);
iowrite8(reg_mode, NPCM7XX_FAN_REG_TCKC(data->fan_base, fan);
This, in turn, leads to the question if it is really not necessary
to _clear_ those mask bits in the same context.
Guenter
> But casts to the same type are not necessary.
>
> A possible coccinelle script to find casts to the
> same type is below, but there are some false positives
> for things like __force and __user casts
>
> Also, spatch (1.0.4) seems to have a defect for this
> when the type is used in operations that change a
> smaller type to int or unsigned int.
>
> i.e.: (offset is u16, but offset * 2 is int)
>
> While running the cocci script below:
>
> HANDLING: drivers/net/ethernet/intel/igb/e1000_nvm.c
> diff =
> diff -u -p a/drivers/net/drivers/net/ethernet/intel/igb/e1000_nvm.c b/drivers/net/ethernet/intel/igb/e1000_nvm.c
> --- a/drivers/net/ethernet/intel/igb/e1000_nvm.c
> +++ b/drivers/net/ethernet/intel/igb/e1000_nvm.c
> @@ -335,7 +335,7 @@ s32 igb_read_nvm_spi(struct e1000_hw *hw
>
> /* Send the READ command (opcode + addr) */
> igb_shift_out_eec_bits(hw, read_opcode, nvm->opcode_bits);
> - igb_shift_out_eec_bits(hw, (u16)(offset*2), nvm->address_bits);
> + igb_shift_out_eec_bits(hw, (offset * 2), nvm->address_bits);
>
> /* Read the data. SPI NVMs increment the address with each byte
> * read and will roll over if reading beyond the end. This allows
>
> ---
>
> Anyway, here's the cocci script:
>
> $ cat same_typecast.cocci
> @@
> type T;
> T foo;
> @@
>
> - (T *)&foo
> + &foo
>
> @@
> type T;
> T foo;
> @@
>
> - (T)foo
> + foo
>
WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: Joe Perches <joe@perches.com>
Cc: Tomer Maimon <tmaimon77@gmail.com>,
Julia Lawall <julia.lawall@lip6.fr>,
cocci <cocci@systeme.lip6.fr>,
robh+dt@kernel.org, mark.rutland@arm.com, jdelvare@suse.com,
avifishman70@gmail.com, yuenn@google.com,
brendanhiggins@google.com, venture@google.com, joel@jms.id.au,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hwmon@vger.kernel.org, openbmc@lists.ozlabs.org
Subject: Re: [PATCH v2 2/2] hwmon: npcm750: add NPCM7xx PWM and Fan driver
Date: Wed, 20 Jun 2018 12:38:06 -0700 [thread overview]
Message-ID: <20180620193806.GA2054@roeck-us.net> (raw)
In-Reply-To: <a6a5a21236c37cfc63329e54248d941bf6d49e3c.camel@perches.com>
On Wed, Jun 20, 2018 at 11:25:08AM -0700, Joe Perches wrote:
> (adding Julia Lawall and cocci mailing list)
>
> On Wed, 2018-06-20 at 09:48 -0700, Guenter Roeck wrote:
> []
> > > +static inline void npcm7xx_fan_start_capture(struct npcm7xx_pwm_fan_data *data,
> > > + u8 fan, u8 cmp)
> > > +{
> > > + u8 fan_id = 0;
> > > + u8 reg_mode = 0;
> > > + u8 reg_int = 0;
> > > + unsigned long flags;
> > > +
> > > + fan_id = NPCM7XX_FAN_INPUT(fan, cmp);
> > > +
> > > + /* to check whether any fan tach is enable */
> > > + if (data->npcm7xx_fan[fan_id].FanStFlag != FAN_DISABLE) {
> > > + /* reset status */
> > > + spin_lock_irqsave(&data->npcm7xx_fan_lock[fan], flags);
> > > +
> > > + data->npcm7xx_fan[fan_id].FanStFlag = FAN_INIT;
> > > + reg_int = ioread8(NPCM7XX_FAN_REG_TIEN(data->fan_base, fan));
> > > +
> > > + if (cmp == NPCM7XX_FAN_CMPA) {
> > > + /* enable interrupt */
> > > + iowrite8((u8) (reg_int | (NPCM7XX_FAN_TIEN_TAIEN |
> > > + NPCM7XX_FAN_TIEN_TEIEN)),
> >
> > Is the (u8) typecast really necessary ? Seems unlikely.
>
> The cast is not really necessary here as there would
> be an implicit cast already.
>
> Some might complain about loss of type safety and
> "make W=123" would probably emit something here.
>
I spent (wasted) some time browsing through the kernel.
Similar typecasts are only used if there is a real type change.
A warning here would not make sense unless NPCM7XX_FAN_TIEN_TAIEN
or NPCM7XX_FAN_TIEN_TEIEN would be outside the u8 range, and then
there would be one anyway.
So, no, I am not going to accept those typecasts. They just make the code
more difficult to read. For example, the code here could have been
simplified to something like
reg_int = ioread8(NPCM7XX_FAN_REG_TIEN(data->fan_base, fan));
reg_mode = ioread8(NPCM7XX_FAN_REG_TCKC(data->fan_base, fan));
if (cmp == NPCM7XX_FAN_CMPA) {
reg_int |= NPCM7XX_FAN_TIEN_TAIEN | NPCM7XX_FAN_TIEN_TEIEN;
reg_mode |= NPCM7XX_FAN_TCKC_CLK1_APB;
} else {
reg_int |= NPCM7XX_FAN_TIEN_TBIEN | NPCM7XX_FAN_TIEN_TFIEN;
reg_mode |= NPCM7XX_FAN_TCKC_CLK2_APB;
}
iowrite8(reg_int, NPCM7XX_FAN_REG_TIEN(data->fan_base, fan);
iowrite8(reg_mode, NPCM7XX_FAN_REG_TCKC(data->fan_base, fan);
This, in turn, leads to the question if it is really not necessary
to _clear_ those mask bits in the same context.
Guenter
> But casts to the same type are not necessary.
>
> A possible coccinelle script to find casts to the
> same type is below, but there are some false positives
> for things like __force and __user casts
>
> Also, spatch (1.0.4) seems to have a defect for this
> when the type is used in operations that change a
> smaller type to int or unsigned int.
>
> i.e.: (offset is u16, but offset * 2 is int)
>
> While running the cocci script below:
>
> HANDLING: drivers/net/ethernet/intel/igb/e1000_nvm.c
> diff =
> diff -u -p a/drivers/net/drivers/net/ethernet/intel/igb/e1000_nvm.c b/drivers/net/ethernet/intel/igb/e1000_nvm.c
> --- a/drivers/net/ethernet/intel/igb/e1000_nvm.c
> +++ b/drivers/net/ethernet/intel/igb/e1000_nvm.c
> @@ -335,7 +335,7 @@ s32 igb_read_nvm_spi(struct e1000_hw *hw
>
> /* Send the READ command (opcode + addr) */
> igb_shift_out_eec_bits(hw, read_opcode, nvm->opcode_bits);
> - igb_shift_out_eec_bits(hw, (u16)(offset*2), nvm->address_bits);
> + igb_shift_out_eec_bits(hw, (offset * 2), nvm->address_bits);
>
> /* Read the data. SPI NVMs increment the address with each byte
> * read and will roll over if reading beyond the end. This allows
>
> ---
>
> Anyway, here's the cocci script:
>
> $ cat same_typecast.cocci
> @@
> type T;
> T foo;
> @@
>
> - (T *)&foo
> + &foo
>
> @@
> type T;
> T foo;
> @@
>
> - (T)foo
> + foo
>
next prev parent reply other threads:[~2018-06-20 19:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-19 10:53 [PATCH v2 0/2] hwmon: Add NPCM7xx PWM and Fan driver support Tomer Maimon
2018-06-19 10:53 ` [PATCH v2 1/2] dt-binding: hwmon: Add NPCM7xx PWM and Fan controller documentation Tomer Maimon
2018-06-19 10:53 ` [PATCH v2 2/2] hwmon: npcm750: add NPCM7xx PWM and Fan driver Tomer Maimon
2018-06-19 14:31 ` kbuild test robot
2018-06-19 14:31 ` kbuild test robot
2018-06-19 19:43 ` kbuild test robot
2018-06-19 19:43 ` kbuild test robot
2018-06-20 16:48 ` Guenter Roeck
2018-06-20 18:25 ` [Cocci] " Joe Perches
2018-06-20 18:25 ` Joe Perches
2018-06-20 19:38 ` Guenter Roeck [this message]
2018-06-20 19:38 ` Guenter Roeck
2018-06-21 13:17 ` [Cocci] " Julia Lawall
2018-06-21 13:17 ` Julia Lawall
2018-06-21 14:48 ` [Cocci] " Joe Perches
2018-06-21 14:48 ` Joe Perches
2018-06-21 14:48 ` Joe Perches
2018-06-21 13:46 ` Guenter Roeck
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=20180620193806.GA2054@roeck-us.net \
--to=linux@roeck-us.net \
--cc=cocci@systeme.lip6.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.