netdev - Re: [PATCH net] net: phy: broadcom: hook up soft

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: <ead6a351-0bd1-1395-d3ed-28d8d1422e7b@gmail.com>
Date:   Tue, 18 Jan 2022 14:03:22 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Robert Hancock <robert.hancock@...ian.com>, netdev@...r.kernel.org
Cc:     andrew@...n.ch, hkallweit1@...il.com, linux@...linux.org.uk,
        davem@...emloft.net, kuba@...nel.org,
        bcm-kernel-feedback-list@...adcom.com
Subject: Re: [PATCH net] net: phy: broadcom: hook up soft_reset for BCM54616S

On 1/18/22 1:52 PM, Robert Hancock wrote:
> A problem was encountered with the Bel-Fuse 1GBT-SFP05 SFP module (which
> is a 1 Gbps copper module operating in SGMII mode with an internal
> BCM54616S PHY device) using the Xilinx AXI Ethernet MAC core, where the
> module would work properly on the initial insertion or boot of the
> device, but after the device was rebooted, the link would either only
> come up at 100 Mbps speeds or go up and down erratically.
> 
> I found no meaningful changes in the PHY configuration registers between
> the working and non-working boots, but the status registers seemed to
> have a lot of error indications set on the SERDES side of the device on
> the non-working boot. I suspect the problem is that whatever happens on
> the SGMII link when the device is rebooted and the FPGA logic gets
> reloaded ends up putting the module's onboard PHY into a bad state.
> 
> Since commit 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
> the genphy_soft_reset call is not made automatically by the PHY core
> unless the callback is explicitly specified in the driver structure. For
> most of these Broadcom devices, there is probably a hardware reset that
> gets asserted to reset the PHY during boot, however for SFP modules
> (where the BCM54616S is commonly found) no such reset line exists, so if
> the board keeps the SFP cage powered up across a reboot, it will end up
> with no reset occurring during reboots.
> 
> Hook up the genphy_soft_reset callback for BCM54616S to ensure that a
> PHY reset is performed before the device is initialized. This appears to
> fix the issue with erratic operation after a reboot with this SFP
> module.
> 
> Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
> Signed-off-by: Robert Hancock <robert.hancock@...ian.com>

Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
-- 
Florian