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

[Jordan Vrtanoski]

Hi,
    Sorry, I didn’t notice that I create the patch in the opposite direction, here is the correct one.

Jordan

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

        /* Checks for hardware constraints */
        if (port->first_rxq + port->nrxqs >
@@ -4559,18 +4559,6 @@
        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 22.11.2021, at 14:51 , Jordan Vrtanoski <jordan.vrtanoski at gmail.com> wrote:
> 
> 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!
>> 
>