ClearFog GT 8K not initialising SFP-H10GB-CU1M transceiver on 5.4.150
Jordan Vrtanoski
jordan.vrtanoski at gmail.com
Sat Nov 20 21:37:45 PST 2021
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!
More information about the linux-arm-kernel
mailing list