On 03/05/2024 13:18, Ricky Wu wrote:
Originally, the sleep codes being moved forward only
ran if we met some conditions (e.g. BMSR_LSTATUS bit
not set in phy_status). Moving these sleep codes forward
makes the usec_interval take effect every time.
Signed-off-by: Ricky Wu <[email protected]>
---
In v2:
* Split the sleep codes into this patch
drivers/net/ethernet/intel/e1000e/phy.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/phy.c
b/drivers/net/ethernet/intel/e1000e/phy.c
index 93544f1cc2a5..4a58d56679c9 100644
--- a/drivers/net/ethernet/intel/e1000e/phy.c
+++ b/drivers/net/ethernet/intel/e1000e/phy.c
@@ -1777,6 +1777,11 @@ s32 e1000e_phy_has_link_generic(struct e1000_hw *hw, u32
iterations,
*success = false;
for (i = 0; i < iterations; i++) {
+ if (usec_interval >= 1000)
+ msleep(usec_interval / 1000);
+ else
+ udelay(usec_interval);
+
I do not understand this approach. Why wait before first
reading/accessing the PHY IEEE register?
For further discussion, I would like to introduce Dima Ruinskiy (architect)
/* Some PHYs require the MII_BMSR register to be read
* twice due to the link bit being sticky. No harm doing
* it across the board.
@@ -1799,10 +1804,6 @@ s32 e1000e_phy_has_link_generic(struct e1000_hw *hw, u32
iterations,
*success = true;
break;
}
- if (usec_interval >= 1000)
- msleep(usec_interval / 1000);
- else
- udelay(usec_interval);
}
return ret_val;
