[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <668cd20c-3863-4d16-ab05-30399e4449f6@lunn.ch>
Date: Sat, 28 Jun 2025 10:40:02 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Asmaa Mnebhi <asmaa@...dia.com>
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
> Hi Andrew,
>
> I implemented and tested the changes you suggested and the
> runtime_resume/suspend work smoothly for MDIO.
> However, we have another issue. I noticed that even if
> mdio_read/write() functions are not being called,
> runtime_resume/suspend() are still called regularly. After
> investigation, I found out that this is due to ethtool being called
> regularly. Ethtool automatically triggers the resume/suspend even if
> we do no MDIO access. A different team wrote a script which monitors
> "ethtool -S eth0" every 60 seconds. So every minute, we are running
> resume/suspend and enabling/disabling the MDIO clock. Seems counter
> productive. That team said that it is a requirement that they
> collect these statistics about the mlxbf_gige interface.
> Is there any way to prevent ethtool from calling resume/suspend
> without changing core kernel code?
> If not, what would you suggest?
You need to put the MDIO bus device into its own pm_domain. Try
calling dev_pm_domain_set() to separate the MDIO bus from the MAC
driver in terms of power domains. ethtool will then power on/off the
MAC but leave the MDIO bus alone.
Andrew
Powered by blists - more mailing lists