linux-kernel - [RFC PATCH] ravb: assert PHY reset during probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 21 Mar 2023 11:33:57 +0100
From:   Wolfram Sang <wsa+renesas@...g-engineering.com>
To:     netdev@...r.kernel.org
Cc:     linux-renesas-soc@...r.kernel.org,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Sergey Shtylyov <s.shtylyov@....ru>,
        "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
Subject: [RFC PATCH] ravb: assert PHY reset during probe

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@...g-engineering.com>
---
 drivers/net/ethernet/renesas/ravb_main.c | 1 +
 1 file changed, 1 insertion(+)

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);
-- 
2.30.2