i40e: precedence bug in i40e_get_pfc_delay()
Subsystems (3)
PATCH 1/1 i40e: precedence bug in i40e_get_pfc_delay()
The ">>" operation has higher precedence than the "&" operation. Also the casting is not needed.
---
This is static checker work and I haven't tested it on real hardware.
drivers/net/ethernet/intel/i40e/i40e_dcb_nl.c +2 -2
@@ -40,8 +40,8 @@ static void i40e_get_pfc_delay(struct i40e_hw *hw, u16 *delay)u32 val; val =rd32 (hw,I40E_PRTDCB_GENC ); - *delay = (u16)(val &I40E_PRTDCB_GENC_PFCLDA_MASK >> -I40E_PRTDCB_GENC_PFCLDA_SHIFT ); + *delay = (val &I40E_PRTDCB_GENC_PFCLDA_MASK ) >> +I40E_PRTDCB_GENC_PFCLDA_SHIFT ; }/**
Quoted 33 lines
-----Original Message-----
From: Dan Carpenter [mailto:[email protected]]
Sent: Wednesday, October 29, 2014 9:10 AM
To: Kirsher, Jeffrey T; Nelson, Shannon
Cc: Brandeburg, Jesse; Allan, Bruce W; Wyborny, Carolyn; Skidmore, Donald C; Rose, Gregory V; Vick, Matthew; Ronciak, John; Williams, Mitch A; Linux NICS; Joe Perches; [email protected]; kernel- [email protected]
Subject: [patch] i40e: precedence bug ini40e_get_pfc_delay()The ">>" operation has higher precedence than the "&" operation. Also the casting is not needed.
Signed-off-by Dan Carpenter <[email protected]>---
This is static checker work and I haven't tested it on real hardware.drivers/net/ethernet/intel/i40e/i40e_dcb_nl.c +2
-2@@ -40,8 +40,8 @@ static void i40e_get_pfc_delay(struct i40e_hw *hw, u16 *delay)u32 val; val =rd32 (hw,I40E_PRTDCB_GENC ); - *delay = (u16)(val &I40E_PRTDCB_GENC_PFCLDA_MASK >> -I40E_PRTDCB_GENC_PFCLDA_SHIFT ); + *delay = (val &I40E_PRTDCB_GENC_PFCLDA_MASK ) >> +I40E_PRTDCB_GENC_PFCLDA_SHIFT ; }
Quoted 1 line
/**
Thanks. We had just recently caught this internally, as well. We'll have Jeff add this to our tree.
sln
Quoted 6 lines · Dan Carpenter
The ">>" operation has higher precedence than the "&" operation. Also the casting is not needed.
Signed-off-by Dan Carpenter <[email protected]>---
This is static checker work and I haven't tested it on real hardware.
As Shannon has already mentioned, we found this internally and I think that I already have a patch in the queue to resolve this. Thank you, and if I find I am incorrect and we do not already have a patch resolving this, I will add your patch to the queue. Thank you Dan!