[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB8PR04MB679538D39673F03F399F8F20E6749@DB8PR04MB6795.eurprd04.prod.outlook.com>
Date: Thu, 8 Apr 2021 06:21:35 +0000
From: Joakim Zhang <qiangqing.zhang@....com>
To: Heiner Kallweit <hkallweit1@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Russell King - ARM Linux <linux@...linux.org.uk>,
Jakub Kicinski <kuba@...nel.org>,
David Miller <davem@...emloft.net>,
Fugang Duan <fugang.duan@....com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next 2/3] net: fec: use mac-managed PHY PM
> -----Original Message-----
> From: Heiner Kallweit <hkallweit1@...il.com>
> Sent: 2021年4月8日 14:00
> To: Joakim Zhang <qiangqing.zhang@....com>; Andrew Lunn
> <andrew@...n.ch>; Russell King - ARM Linux <linux@...linux.org.uk>; Jakub
> Kicinski <kuba@...nel.org>; David Miller <davem@...emloft.net>; Fugang
> Duan <fugang.duan@....com>
> Cc: netdev@...r.kernel.org
> Subject: Re: [PATCH net-next 2/3] net: fec: use mac-managed PHY PM
>
> On 08.04.2021 07:45, Joakim Zhang wrote:
> >
> >> -----Original Message-----
> >> From: Heiner Kallweit <hkallweit1@...il.com>
> >> Sent: 2021年4月7日 23:53
> >> To: Andrew Lunn <andrew@...n.ch>; Russell King - ARM Linux
> >> <linux@...linux.org.uk>; Jakub Kicinski <kuba@...nel.org>; David
> >> Miller <davem@...emloft.net>; Fugang Duan <fugang.duan@....com>
> >> Cc: netdev@...r.kernel.org; Joakim Zhang <qiangqing.zhang@....com>
> >> Subject: [PATCH net-next 2/3] net: fec: use mac-managed PHY PM
> >>
> >> Use the new mac_managed_pm flag to work around an issue with KSZ8081
> >> PHY that becomes unstable when a soft reset is triggered during aneg.
> >>
> >> Reported-by: Joakim Zhang <qiangqing.zhang@....com>
> >> Tested-by: Joakim Zhang <qiangqing.zhang@....com>
> >> Signed-off-by: Heiner Kallweit <hkallweit1@...il.com>
> >> ---
> >> drivers/net/ethernet/freescale/fec_main.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> >> b/drivers/net/ethernet/freescale/fec_main.c
> >> index 3db882322..70aea9c27 100644
> >> --- a/drivers/net/ethernet/freescale/fec_main.c
> >> +++ b/drivers/net/ethernet/freescale/fec_main.c
> >> @@ -2048,6 +2048,8 @@ static int fec_enet_mii_probe(struct net_device
> >> *ndev)
> >> fep->link = 0;
> >> fep->full_duplex = 0;
> >>
> >> + phy_dev->mac_managed_pm = 1;
> >> +
> >> phy_attached_info(phy_dev);
> >>
> >> return 0;
> >> @@ -3864,6 +3866,7 @@ static int __maybe_unused fec_resume(struct
> >> device *dev)
> >> netif_device_attach(ndev);
> >> netif_tx_unlock_bh(ndev);
> >> napi_enable(&fep->napi);
> >> + phy_init_hw(ndev->phydev);
> >
> >
> > For now, I think we doesn't need to re-initialize PHY after MAC resume back,
> it also can be done by PHY driver if it needed.
> >
> The PHY PM resume callback (that used to call phy_init_hw) is a no-op now.
> So we have to call it from the MAC resume callback. Power to the PHY may be
> off during system suspend, therefore it may be reset to power-on defaults.
> That's why phy_init_hw() should be called, that includes calling the PHY drivers
> config_init callback.
Yes, it is reasonable to invoke phy_init_hw() here to cover more cases. What I want to describe, we have not run into such case for FEC driver before.
At least no one complain it before as I know. Anyway, re-initialize PHY here indeed can benefit more scenarios.
Best Regards,
Joakim Zhang
> > Best Regards,
> > Joakim Zhang
> >> phy_start(ndev->phydev);
> >> }
> >> rtnl_unlock();
> >> --
> >> 2.31.1
> >>
> >
Powered by blists - more mailing lists