[Intel-wired-lan] [PATCH] e1000e: Add error handling for e1e_rphy_locked()

[Simon Horman]

On Mon, Apr 07, 2025 at 11:41:54AM +0800, Wentao Liang wrote:
> The e1000_suspend_workarounds_ich8lan() calls e1e_rphy_locked to disable
> the SMB release, but does not check its return value. A proper
> implementation can be found in e1000_resume_workarounds_pchlan() from
> /source/drivers/net/ethernet/intel/e1000e/ich8lan.c.
> 
> Add an error check for e1e_rphy_locked(). Log the error message and jump
> to 'release' label if the e1e_rphy_locked() fails.
> 
> Fixes: 2fbe4526e5aa ("e1000e: initial support for i217")
> Cc: stable at vger.kernel.org # v3.5+
> Signed-off-by: Wentao Liang <vulab at iscas.ac.cn>
> ---
>  drivers/net/ethernet/intel/e1000e/ich8lan.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> index 2f9655cf5dd9..d16e3aa50809 100644
> --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
> +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> @@ -5497,7 +5497,11 @@ void e1000_suspend_workarounds_ich8lan(struct e1000_hw *hw)
>  			e1e_wphy_locked(hw, I217_SxCTRL, phy_reg);
>  
>  			/* Disable the SMB release on LCD reset. */
> -			e1e_rphy_locked(hw, I217_MEMPWR, &phy_reg);
> +			ret_val = e1e_rphy_locked(hw, I217_MEMPWR, &phy_reg);
> +			if (ret_val) {
> +				e_dbg("Fail to Disable the SMB release on LCD reset.");
> +				goto release;
> +			}
>  			phy_reg &= ~I217_MEMPWR_DISABLE_SMB_RELEASE;
>  			e1e_wphy_locked(hw, I217_MEMPWR, phy_reg);
>  		}

Hi,

The next few lines of this function look like this:

		/* Enable MTA to reset for Intel Rapid Start Technology
		 * Support
		 */
		e1e_rphy_locked(hw, I217_CGFREG, &phy_reg);
		phy_reg |= I217_CGFREG_ENABLE_MTA_RESET;
		e1e_wphy_locked(hw, I217_CGFREG, phy_reg);

And I think that to be consistent with e1000_resume_workarounds_pchlan()
the return value of the above call to e1e_rphy_locked() should also be
checked.

However, I am not at all sure if the current absence of error checking is
intended as part of the logic flow, or if these are oversights.

Have you observed any run-time problems with this code?

I would naively expect that the i217 is or was a widely used device.  And
this code seems to have been around for a well over 10 years in it's
current form. Which makes me thing we should tread carefully when changing
it.