ClearFog GT 8K not initialising SFP-H10GB-CU1M transceiver on 5.4.150
Russell King (Oracle)
linux at armlinux.org.uk
Sat Nov 20 11:41:46 PST 2021
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