.../ethernet/mellanox/mlxbf_gige/mlxbf_gige_mdio.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
From: asmaa <asmaa@nvidia.com>
Once the BlueField-3 MDIO clock is enabled by software, it is expected
and intended for it to keep toggling. BlueField-3 has a hardware GPIO bug
where constant toggling at "high frequencies" will lead to GPIO
degradation.
The workaround suggested by the hardware team is to lower down the clock
frequency. That will increase the "life expectation" of the GPIO.
The lowest possible frequency we can achieve is 1.09Mhz by setting
mdio_period = 0xFF.
Fixes: f92e1869d74e ("Add Mellanox BlueField Gigabit Ethernet driver")
Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com>
---
.../ethernet/mellanox/mlxbf_gige/mlxbf_gige_mdio.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxbf_gige/mlxbf_gige_mdio.c b/drivers/net/ethernet/mellanox/mlxbf_gige/mlxbf_gige_mdio.c
index 654190263535..d6dd36ab599e 100644
--- a/drivers/net/ethernet/mellanox/mlxbf_gige/mlxbf_gige_mdio.c
+++ b/drivers/net/ethernet/mellanox/mlxbf_gige/mlxbf_gige_mdio.c
@@ -96,6 +96,7 @@ static struct mlxbf_gige_mdio_gw mlxbf_gige_mdio_gw_t[] = {
#define MLXBF_GIGE_MDIO_FREQ_REFERENCE 156250000ULL
#define MLXBF_GIGE_MDIO_COREPLL_CONST 16384ULL
#define MLXBF_GIGE_MDC_CLK_NS 400
+#define MLXBF_GIGE_BF3_MDIO_PERIOD 0xFF
#define MLXBF_GIGE_MDIO_PLL_I1CLK_REG1 0x4
#define MLXBF_GIGE_MDIO_PLL_I1CLK_REG2 0x8
#define MLXBF_GIGE_MDIO_CORE_F_SHIFT 0
@@ -178,9 +179,16 @@ static u8 mdio_period_map(struct mlxbf_gige *priv)
u8 mdio_period;
u64 i1clk;
- i1clk = calculate_i1clk(priv);
-
- mdio_period = div_u64((MLXBF_GIGE_MDC_CLK_NS >> 1) * i1clk, 1000000000) - 1;
+ /* The MDIO clock frequency need to be set as low as possible to avoid
+ * a BF3 hardware GPIO degradation. The lowest frequency can be achieved
+ * by setting MdioPeriod = 0xFF.
+ */
+ if (priv->hw_version == MLXBF_GIGE_VERSION_BF3) {
+ mdio_period = MLXBF_GIGE_BF3_MDIO_PERIOD;
+ } else {
+ i1clk = calculate_i1clk(priv);
+ mdio_period = div_u64((MLXBF_GIGE_MDC_CLK_NS >> 1) * i1clk, 1000000000) - 1;
+ }
return mdio_period;
}
--
2.47.0
On Fri, Nov 22, 2024 at 10:48:27PM +0000, Asmaa Mnebhi wrote: > From: asmaa <asmaa@nvidia.com> > > Once the BlueField-3 MDIO clock is enabled by software, it is expected > and intended for it to keep toggling. BlueField-3 has a hardware GPIO bug > where constant toggling at "high frequencies" will lead to GPIO > degradation. > > The workaround suggested by the hardware team is to lower down the clock > frequency. That will increase the "life expectation" of the GPIO. > The lowest possible frequency we can achieve is 1.09Mhz by setting > mdio_period = 0xFF. 802.3 says: 22.2.2.13 MDC (management data clock) MDC is sourced by the station management entity to the PHY as the timing reference for transfer of information on the MDIO signal. MDC is an aperiodic signal that has no maximum high or low times. The minimum high and low times for MDC shall be 160 ns each, and the minimum period for MDC shall be 400 ns, regardless of the nominal period of TX_CLK and RX_CLK. My reading of this is that you can stop the clock when it is not needed. Maybe tie into the Linux runtime power management framework. It can keep track of how long a device has been idle, and if a timer is exceeded, make a callback to power it down. If you have an MDIO bus with one PHY on it, the access pattern is likely to be a small bunch of reads followed by about one second of idle time. I would of thought that stopping the clock increases the life expectancy of you hardware more than just slowing it down. Andrew
© 2016 - 2026 Red Hat, Inc.