[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <99eade9d-a580-4519-8399-832e196d335a@lunn.ch>
Date: Tue, 5 Sep 2023 14:09:29 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jijie Shao <shaojijie@...wei.com>
Cc: f.fainelli@...il.com, davem@...emloft.net, edumazet@...gle.com,
hkallweit1@...il.com, kuba@...nel.org, netdev@...r.kernel.org,
pabeni@...hat.com, rmk+kernel@...linux.org.uk,
"shenjian15@...wei.com" <shenjian15@...wei.com>,
"liuyonglong@...wei.com" <liuyonglong@...wei.com>,
wangjie125@...wei.com, chenhao418@...wei.com,
Hao Lan <lanhao@...wei.com>,
"wangpeiyang1@...wei.com" <wangpeiyang1@...wei.com>
Subject: Re: [PATCH net-next] net: phy: avoid kernel warning dump when
stopping an errored PHY
> When we do a phy_stop(), hardware might be error and we can't access to
> mdio.And our process is read/write mdio failed first, then do phy_stop(),
> reset hardware and call phy_start() finally.
If the hardware/fimrware is already dead, you have to expect a stack
trace, because the once a second poll can happen, before you notice
the hardware/firmware is dead and call phy_stop().
You might want to also disconnect the PHY and reconnect it after the
reset.
But you should prioritise finding why your hardware/firmware dies,
that is the real problem, and we should not really be adding hacks to
the phylib core to work around broken hardware. Such hacks belong
since your driver, e.g. if the MDIO read/write fails, check if the
firmware still responds, and trigger your reset process immediately.
Andrew
Powered by blists - more mailing lists