diff mbox series

[RFC] ravb: assert PHY reset during probe

Message ID 20230321103357.18940-1-wsa+renesas@sang-engineering.com (mailing list archive)
State RFC
Delegated to: Netdev Maintainers
Headers show
Series [RFC] ravb: assert PHY reset during probe | expand

Checks

Context Check Description
netdev/series_format warning Single patches do not need cover letters; Target tree name not specified in the subject
netdev/tree_selection success Guessed tree name to be net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 18 this patch: 18
netdev/cc_maintainers warning 2 maintainers not CCed: phil.edworthy@renesas.com biju.das.jz@bp.renesas.com
netdev/build_clang success Errors and warnings before: 18 this patch: 18
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 18 this patch: 18
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 7 lines checked
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Wolfram Sang March 21, 2023, 10:33 a.m. UTC
The problem: Kernel+initramfs got loaded via TFTP by the bootloader,
thus the PHY reset is deasserted during boot. When suspend is entered
without bringing the interface up before, PHY reset is still deasserted.
Our KSZ9031 PHY doesn't like being suspended with reset deasserted, at
all. When resuming and trying to bring the interface up, we get MDIO bus
timeouts or stalled PHYs, depending on the board.

Once the interface was up once, reset handling is correct. PHY reset is
asserted before suspending. But if it wasn't up, there is this problem.

First, I tried to have a full reset cycle in phy_hw_init() like [1]. But
as expressed there, I had also worries about regressions for other PHYs.

This patch here assumes that the MAC should take care of it after it
claimed responsibility for the PHY PM by setting 'mac_managed_pm'. I am
not sure this is the right layer, though? But I am not sure where to put
it otherwise. Maybe we need something like phy_reset_after_power_on() as
proposed in [2] after all? I'd like to avoid pushing the responsibility
to the firmware but rather let Linux be more robust.

This patch depends on v6.3-rc3 or 7f5ebf5dae42 ("ravb: avoid PHY being
resumed when interface is not up").

Really looking forward to comments or pointers!

Thanks in advance and happy hacking,

   Wolfram

[1] https://patchwork.kernel.org/project/netdevbpf/patch/20211211130146.357794-1-francesco.dolcini@toradex.com/
[2] https://patchwork.kernel.org/project/netdevbpf/list/?series=595347&state=*

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/net/ethernet/renesas/ravb_main.c | 1 +
 1 file changed, 1 insertion(+)
diff mbox series

Patch

diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index 894e2690c643..d26944c0d4c8 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -2404,6 +2404,7 @@  static int ravb_mdio_init(struct ravb_private *priv)
 	phydev = of_phy_find_device(pn);
 	if (phydev) {
 		phydev->mac_managed_pm = true;
+		phy_device_reset(phydev, 1);
 		put_device(&phydev->mdio.dev);
 	}
 	of_node_put(pn);