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

[Jordan Vrtanoski]

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?


> On 16.11.2021, at 14:51 , Russell King (Oracle) <linux at armlinux.org.uk> wrote:
> 
> On Tue, Nov 16, 2021 at 02:11:54PM +0400, Jordan Vrtanoski wrote:
>> Hi,
>> 
>> I am trying to build kernel 5.4.150 for SolidRun ClearFog GT 8K. The kernel is stable and I had not experiance any stability issue. The only issue I am facing is with enabling the support for the SFP+ module. 
>> 
>> I am using SFP-H10GB-CU1M direct coper cable module. The module works on earlier version of the kernel 5.1.x (verified on the same hardware), however once the device is booted under 5.4.150, the transceiver is not recognised and the interface remains down. There are no error messages reported by the kernel.
> 
> The transceiver is recognised, but for some reason the link isn't coming
> up - and from the debug kernel messages, there's no information pointing
> to why not. At a guess, mvpp2 is not reporting that it has link for some
> reason.
> 
> I don't think it's an issue with the module or the SFP layer - since
> that is going into "link up" state and the TX_DISABLE signal is being
> deasserted (not that they mean much for a DA cable.) So, I'd be thinking
> that the problem is with the comphy or mvpp2 drivers.
> 
> mvpp2 doesn't have much in the way of debugging messages to help with
> this, but phylink should at least be printing "mac link" messages in
> both 5.1.x and 5.4.x kernels - but it doesn't appear to be. That
> suggests enabling dynamic debug is not sufficient to get those messages
> out... I'm afraid I've never used dynamic debug so can't help with that.
> Maybe someone who knows now netdev_dbg() interacts with dynamic debug
> can help with that. Strangely, you are getting the netdev_dbg() from
> within phylink_sfp_module_insert(), so I don't really understand why
> you aren't getting anything else from phylink.
> 
> It all seems rather odd.
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!