diff mbox

[net-next,03/12] e1000e: add check on e1e_wphy() return value

Message ID 20170809214746.28139-4-jeffrey.t.kirsher@intel.com
State Accepted, archived
Delegated to: David Miller
Headers show

Commit Message

Kirsher, Jeffrey T Aug. 9, 2017, 9:47 p.m. UTC 
From: Gustavo A R Silva <garsilva@embeddedor.com>

Check return value from call to e1e_wphy(). This value is being
checked during previous calls to function e1e_wphy() and it seems
a check was missing here.

Addresses-Coverity-ID: 1226905
Signed-off-by: Gustavo A R Silva <garsilva@embeddedor.com>
Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Joe Perches Aug. 10, 2017, 5:56 p.m. UTC | #1 
On Wed, 2017-08-09 at 14:47 -0700, Jeff Kirsher wrote:
> From: Gustavo A R Silva <garsilva@embeddedor.com>
> 
> Check return value from call to e1e_wphy(). This value is being
> checked during previous calls to function e1e_wphy() and it seems
> a check was missing here.

The use of "it seems" here is less than compelling.

Perhaps the write of 0x3140 to MII_BMCR takes too long for
the return value used.

Many other uses of e1e_wphy.*MII_BMCR are also not checked.

For instance: the e100e/ethtool uses.

> diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
[]
> @@ -2437,6 +2437,8 @@ static s32 e1000_hv_phy_workarounds_ich8lan(struct e1000_hw *hw)
>  		if (hw->phy.revision < 2) {
>  			e1000e_phy_sw_reset(hw);
>  			ret_val = e1e_wphy(hw, MII_BMCR, 0x3140);
> +			if (ret_val)
> +				return ret_val;
>  		}
>  	}
>
Gustavo A. R. Silva Aug. 11, 2017, 2:47 a.m. UTC | #2 
Hello everybody,

I'm a little confused. Is this patch causing any trouble?

On 08/10/2017 12:56 PM, Joe Perches wrote:
> On Wed, 2017-08-09 at 14:47 -0700, Jeff Kirsher wrote:
>> From: Gustavo A R Silva <garsilva@embeddedor.com>
>>
>> Check return value from call to e1e_wphy(). This value is being
>> checked during previous calls to function e1e_wphy() and it seems
>> a check was missing here.
>
> The use of "it seems" here is less than compelling.
>

This is one of the first patches I sent. Maybe I should have added a 
note saying that this patch needed some testing, as I don't have the 
hardware to test it.

> Perhaps the write of 0x3140 to MII_BMCR takes too long for
> the return value used.
>
> Many other uses of e1e_wphy.*MII_BMCR are also not checked.
>
> For instance: the e100e/ethtool uses.
>
>> diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> []
>> @@ -2437,6 +2437,8 @@ static s32 e1000_hv_phy_workarounds_ich8lan(struct e1000_hw *hw)
>>  		if (hw->phy.revision < 2) {
>>  			e1000e_phy_sw_reset(hw);
>>  			ret_val = e1e_wphy(hw, MII_BMCR, 0x3140);
>> +			if (ret_val)
>> +				return ret_val;
>>  		}
>>  	}
>>

Thanks
Joe Perches Aug. 11, 2017, 2:53 a.m. UTC | #3 
On Thu, 2017-08-10 at 21:47 -0500, Gustavo A. R. Silva wrote:
> Hello everybody,
> 
> I'm a little confused. Is this patch causing any trouble?

Not to me.  I no longer have an e1000e.

Given the commit message, this just seemed to be a patch
that _might_ cause an issue if this code patch is actually
untested.

Compilation wise, it's obviously fine.

> On 08/10/2017 12:56 PM, Joe Perches wrote:
> > On Wed, 2017-08-09 at 14:47 -0700, Jeff Kirsher wrote:
> > > From: Gustavo A R Silva <garsilva@embeddedor.com>
> > > 
> > > Check return value from call to e1e_wphy(). This value is being
> > > checked during previous calls to function e1e_wphy() and it seems
> > > a check was missing here.
> > 
> > The use of "it seems" here is less than compelling.
> > 
> 
> This is one of the first patches I sent. Maybe I should have added a 
> note saying that this patch needed some testing, as I don't have the 
> hardware to test it.
> 
> > Perhaps the write of 0x3140 to MII_BMCR takes too long for
> > the return value used.
> > 
> > Many other uses of e1e_wphy.*MII_BMCR are also not checked.
> > 
> > For instance: the e100e/ethtool uses.
> > 
> > > diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> > 
> > []
> > > @@ -2437,6 +2437,8 @@ static s32 e1000_hv_phy_workarounds_ich8lan(struct e1000_hw *hw)
> > >  		if (hw->phy.revision < 2) {
> > >  			e1000e_phy_sw_reset(hw);
> > >  			ret_val = e1e_wphy(hw, MII_BMCR, 0x3140);
> > > +			if (ret_val)
> > > +				return ret_val;
> > >  		}
> > >  	}
> > > 
> 
> Thanks
Kirsher, Jeffrey T Aug. 11, 2017, 3:54 a.m. UTC | #4 
On Thu, 2017-08-10 at 19:53 -0700, Joe Perches wrote:
> On Thu, 2017-08-10 at 21:47 -0500, Gustavo A. R. Silva wrote:
> > Hello everybody,
> > 
> > I'm a little confused. Is this patch causing any trouble?
> 
> Not to me.  I no longer have an e1000e.
> 
> Given the commit message, this just seemed to be a patch
> that _might_ cause an issue if this code patch is actually
> untested.
> 
> Compilation wise, it's obviously fine.

Fortunately, I have all patches submitted to me thoroughly tested.  It
was a good catch, and we confirmed it does provide a valid fix.
diff mbox

Patch

diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 68ea8b4555ab..d6d4ed7acf03 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -2437,6 +2437,8 @@  static s32 e1000_hv_phy_workarounds_ich8lan(struct e1000_hw *hw)
 		if (hw->phy.revision < 2) {
 			e1000e_phy_sw_reset(hw);
 			ret_val = e1e_wphy(hw, MII_BMCR, 0x3140);
+			if (ret_val)
+				return ret_val;
 		}
 	}