linux-kernel - Re: [PATCH net-next 3/3] net: fec: reset phy on resume after power-up

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211214223548.GA47132@francesco-nb.int.toradex.com>
Date:   Tue, 14 Dec 2021 23:35:48 +0100
From:   Francesco Dolcini <francesco.dolcini@...adex.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Philippe Schenker <philippe.schenker@...adex.com>,
        netdev@...r.kernel.org, Joakim Zhang <qiangqing.zhang@....com>,
        "David S . Miller" <davem@...emloft.net>,
        Russell King <linux@...linux.org.uk>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Francesco Dolcini <francesco.dolcini@...adex.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Fabio Estevam <festevam@...il.com>,
        Fugang Duan <fugang.duan@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 3/3] net: fec: reset phy on resume after power-up

Hello Andrew,

On Tue, Dec 14, 2021 at 07:54:54PM +0100, Andrew Lunn wrote:
> What i don't particularly like about this is that the MAC driver is
> doing it. Meaning if this PHY is used with any other MAC, the same
> code needs adding there.
This is exactly the same case as phy_reset_after_clk_enable() [1][2], to
me it does not look that bad.

> So maybe in the phy driver, add a suspend handler, which asserts the
> reset. This call here will take it out of reset, so applying the reset
> you need?
Asserting the reset in the phylib in suspend path is a bad idea, in the
general case in which the PHY is powered in suspend the
power-consumption is likely to be higher if the device is in reset
compared to software power-down using the BMCR register (at least for
the PHY datasheet I checked).

What we could do is to call phy_device_reset in the fec driver suspend
path when we know we are going to disable the regulator, I do not like
it, but it would solve the issue.

--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -4064,7 +4064,11 @@ static int __maybe_unused fec_suspend(struct device *dev)
        rtnl_unlock();

        if (fep->reg_phy && !(fep->wol_flag & FEC_WOL_FLAG_ENABLE))
+       {
                regulator_disable(fep->reg_phy);
+               phy_device_reset(ndev->phydev, 1);
+       }
+

        /* SOC supply clock to phy, when clock is disabled, phy link down
         * SOC control phy regulator, when regulator is disabled, phy link down

Francesco

[1] https://lore.kernel.org/netdev/20171211121700.10200-1-dev@g0hl1n.net/
[2] 1b0a83ac04e3 ("net: fec: add phy_reset_after_clk_enable() support")