Patch "net: phy: broadcom: hook up soft_reset for BCM54616S" has been added to the 5.15-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    net: phy: broadcom: hook up soft_reset for BCM54616S

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     net-phy-broadcom-hook-up-soft_reset-for-bcm54616s.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 752519bcd1ec32579aa9bf98d091d762e80ac221
Author: Robert Hancock <robert.hancock@xxxxxxxxxx>
Date:   Tue Jan 18 15:52:43 2022 -0600

    net: phy: broadcom: hook up soft_reset for BCM54616S
    
    [ Upstream commit d15c7e875d44367005370e6a82e8f3a382a04f9b ]
    
    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@xxxxxxxxxx>
    Reviewed-by: Florian Fainelli <f.fainelli@xxxxxxxxx>
    Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 83aea5c5cd03c..db26ff8ce7dbb 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -768,6 +768,7 @@ static struct phy_driver broadcom_drivers[] = {
 	.phy_id_mask	= 0xfffffff0,
 	.name		= "Broadcom BCM54616S",
 	/* PHY_GBIT_FEATURES */
+	.soft_reset     = genphy_soft_reset,
 	.config_init	= bcm54xx_config_init,
 	.config_aneg	= bcm54616s_config_aneg,
 	.config_intr	= bcm_phy_config_intr,



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux