From: Andrew Lunn <andrew@lunn.ch>
To: Asmaa Mnebhi <asmaa@nvidia.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
David Thompson <davthompson@nvidia.com>
Subject: Re: [PATCH net v1] mlxbf-gige: Support workaround for MDIO GPIO degradation bug
Date: Tue, 26 Nov 2024 18:32:39 +0100 [thread overview]
Message-ID: <7c7e94dc-a87f-425b-b833-32e618497cf8@lunn.ch> (raw)
In-Reply-To: <20241122224829.457786-1-asmaa@nvidia.com>
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
next prev parent reply other threads:[~2024-11-26 17:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-22 22:48 Asmaa Mnebhi
2024-11-26 17:32 ` Andrew Lunn [this message]
2025-05-08 14:18 ` Asmaa Mnebhi
2025-05-08 14:44 ` Andrew Lunn
2025-05-08 14:53 ` Asmaa Mnebhi
2025-06-27 19:00 ` Asmaa Mnebhi
2025-06-28 8:40 ` Andrew Lunn
2025-07-02 20:56 ` Asmaa Mnebhi
2025-07-02 21:26 ` Andrew Lunn
2025-07-03 18:51 ` Asmaa Mnebhi
2025-07-03 20:49 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7c7e94dc-a87f-425b-b833-32e618497cf8@lunn.ch \
--to=andrew@lunn.ch \
--cc=asmaa@nvidia.com \
--cc=davem@davemloft.net \
--cc=davthompson@nvidia.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®