linux-kernel - RE: [PATCH net v1] mlxbf-gige: Support workaround for MDIO GPIO degradation bug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <CH3PR12MB7738C758D2A87A9263414AFBD78BA@CH3PR12MB7738.namprd12.prod.outlook.com>
Date: Thu, 8 May 2025 14:18:00 +0000
From: Asmaa Mnebhi <asmaa@...dia.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com"
	<edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, David Thompson <davthompson@...dia.com>
Subject: RE: [PATCH net v1] mlxbf-gige: Support workaround for MDIO GPIO
 degradation bug

> > 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.

Hi Andrew, 

Thank you for your answer and apologies for the very late response. My concern with completely stopping the clock is the case we are using the PHY polling mode for the link status? We would need MDIO to always be operational for polling to work, wouldn't we?

Thanks.
Asmaa