netdev - Re: [PATCH][RESEND] net: fec: Fix PHY init after phy_reset_after_clk

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: <6b600a23-cdf9-827f-2ff8-501ed0f1bdb1@denx.de>
Date:   Fri, 9 Oct 2020 09:21:06 +0200
From:   Marek Vasut <marex@...x.de>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
        Richard Leitner <richard.leitner@...data.com>,
        Christoph Niedermaier <cniedermaier@...electronics.com>,
        "David S . Miller" <davem@...emloft.net>,
        NXP Linux Team <linux-imx@....com>,
        Shawn Guo <shawnguo@...nel.org>
Subject: Re: [PATCH][RESEND] net: fec: Fix PHY init after
 phy_reset_after_clk_enable()

On 10/9/20 2:51 AM, Jakub Kicinski wrote:
> On Tue,  6 Oct 2020 15:52:53 +0200 Marek Vasut wrote:
>> The phy_reset_after_clk_enable() does a PHY reset, which means the PHY
>> loses its register settings. The fec_enet_mii_probe() starts the PHY
>> and does the necessary calls to configure the PHY via PHY framework,
>> and loads the correct register settings into the PHY. Therefore,
>> fec_enet_mii_probe() should be called only after the PHY has been
>> reset, not before as it is now.
>>
>> Fixes: 1b0a83ac04e3 ("net: fec: add phy_reset_after_clk_enable() support")
>> Reviewed-by: Andrew Lunn <andrew@...n.ch>
>> Tested-by: Richard Leitner <richard.leitner@...data.com>
>> Signed-off-by: Marek Vasut <marex@...x.de>
> 
> Is moving the reset before fec_enet_mii_probe() the reason you need the
> second patch?
> 
>   net: fec: Fix phy_device lookup for phy_reset_after_clk_enable()

No, the second patch addresses separate issue.