ClearFog GT 8K not initialising SFP-H10GB-CU1M transceiver on 5.4.150

[Jordan Vrtanoski]

Hi,
    After bisecting, the regression defect was introduced in 5.4.90 with the following patch:
"[PATCH net v3] net: mvpp2: disable force link UP during port init procedure”

    The patch is changing the configuration of the port during the initialisation of MVPP22_XLG_CTRL0_REG, which
on ClearFog GT 8K is preventing the MVPP2 to properly start the MAC after the transceiver is detected. After reverting 
the patch, the transceiver works properly.

    Here is the patch for 5.4.150 I applied (reversing the patch "[PATCH net v3] net: mvpp2: disable force link UP during port init procedure”):

--- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c      2021-11-22 09:36:45.176710763 +0000
+++ drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c      2021-09-30 08:09:26.000000000 +0000
@@ -4545,7 +4545,7 @@
        struct mvpp2 *priv = port->priv;
        struct mvpp2_txq_pcpu *txq_pcpu;
        unsigned int thread;
-       int queue, err;
+       int queue, err, val;

        /* Checks for hardware constraints */
        if (port->first_rxq + port->nrxqs >
@@ -4559,6 +4559,18 @@
        mvpp2_egress_disable(port);
        mvpp2_port_disable(port);

+       if (mvpp2_is_xlg(port->phy_interface)) {
+               val = readl(port->base + MVPP22_XLG_CTRL0_REG);
+               val &= ~MVPP22_XLG_CTRL0_FORCE_LINK_PASS;
+               val |= MVPP22_XLG_CTRL0_FORCE_LINK_DOWN;
+               writel(val, port->base + MVPP22_XLG_CTRL0_REG);
+       } else {
+               val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+               val &= ~MVPP2_GMAC_FORCE_LINK_PASS;
+               val |= MVPP2_GMAC_FORCE_LINK_DOWN;
+               writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+       }
+
        port->tx_time_coal = MVPP2_TXDONE_COAL_USEC;

        port->txqs = devm_kcalloc(dev, port->ntxqs, sizeof(*port->txqs),


> On 21.11.2021, at 09:37 , Jordan Vrtanoski <jordan.vrtanoski at gmail.com> wrote:
> 
> I also suspect that it could be a case of the misconfiguration of the hardware,
> and I believe it’s coming from MVPP2 driver.
> 
> I will try 5.4.0, and if it works, I will bisect till 5.4.150 to see when the defect was introduced.
> 
>> On 20.11.2021, at 23:41 , Russell King (Oracle) <linux at armlinux.org.uk> wrote:
>> 
>> On Sat, Nov 20, 2021 at 10:57:39PM +0400, Jordan Vrtanoski wrote:
>>> I have tried the same config on 5.10.80 and the transceiver is properly initialised, link between PHY and MAC established and IP address obtained trough DHCP.
>>> This is definitely a regression defect in 5.4.x.
>>> 
>>> What I managed to find till now by adding debugging messages in the phylink and mvpp2 is that when the phylink_resolve
>>> is invoked, phylink_resolve will invoke mvpp2_phylink_mac_link_state (trough the pl->ops). 
>>> The stat that is returned is same with the old state, so the phylink_mac_link_up is never executed.
>>> From what I can conclude from the code, it looks like the MVPP22_XLG_STATUS_LINK_UP is not set in the registry MVPP22_XLG_STATUS  
>>> 
>>> I have also noticed that the mvpp2_link_status_isr is not invoked when the transciver is inserted. Is this expected behaviour? 
>>> Who should set the MVPP22_XLG_STATUS_LINK_UP after it’s detected that the module was inserted in the cage?
>> 
>> The hardware does, when it detects valid 10GBASE-R signal being received
>> from the SFP. It could mean something is misconfigured with the COMPHY
>> block, or something wrong with the mvpp2 driver.
>> 
>> I'm afraid that getting a bug report against a stable kernel is about
>> the worst situation for me - I don't track the stable kernels or what
>> goes into them. To be honest, I don't remember much about the 5.4
>> kernel (I blame that on getting old!)
>> 
>> Please can you test vanilla 5.4? If that works, then please bisect
>> between 5.4 and the 5.4.x kernel that you've identified as failing.
>> It could be some patch has been backported into that stable kernel
>> that should not have been.
>> 
>> Thanks.
>> 
>> -- 
>> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
>> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
>