[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZBMfV2BwiMLyKC7w@ninjato>
Date: Thu, 16 Mar 2023 14:53:27 +0100
From: Wolfram Sang <wsa+renesas@...g-engineering.com>
To: Wei Fang <wei.fang@....com>
Cc: "linux-renesas-soc@...r.kernel.org"
<linux-renesas-soc@...r.kernel.org>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
Shenwei Wang <shenwei.wang@....com>,
Clark Wang <xiaoning.wang@....com>,
dl-linux-imx <linux-imx@....com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 3/4] fec: add FIXME to move 'mac_managed_pm' to
probe
> Thank you Wolfram. But I'm not sure whether it's really an issue. The flag
> " mac_managed_pm" indicates that the MAC driver will take care of
> suspending/resuming the PHY, that is to say the MAC driver calls
> phy_stop()/phy_start() in its PM callbacks. If a ethernet interface never
> brings up, the MAC PM callbacks do nothing and just return 0 directly. So I
> think it's fine for the MDIO PM to do suspend/resume the PHY unless the MDIO
> bus can't be accessed.
I have one board here where accessing the MDIO bus times out, although I
don't really understand why. And another one where the call to
phy_init_hw() during resume causes issues. There might be more problems
with these boards, but I think it is cleaner to avoid any MDIO bus
suspend/resume if we have 'mac_managed_pm' anyway.
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists