From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Jordan Vrtanoski <jordan.vrtanoski@gmail.com>
Cc: mw@semihalf.com, linux-arm-kernel@lists.infradead.org
Subject: Re: ClearFog GT 8K not initialising SFP-H10GB-CU1M transceiver on 5.4.150
Date: Sat, 20 Nov 2021 19:41:46 +0000 [thread overview]
Message-ID: <YZlPeoRLSJKNJZ5F@shell.armlinux.org.uk> (raw)
In-Reply-To: <A2513E97-0C96-4E16-A9D2-98BB90490229@gmail.com>
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!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-11-20 19:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 10:11 ClearFog GT 8K not initialising SFP-H10GB-CU1M transceiver on 5.4.150 Jordan Vrtanoski
2021-11-16 10:51 ` Russell King (Oracle)
2021-11-20 18:57 ` Jordan Vrtanoski
2021-11-20 19:41 ` Russell King (Oracle) [this message]
2021-11-21 5:37 ` Jordan Vrtanoski
2021-11-22 10:51 ` Jordan Vrtanoski
2021-11-22 13:15 ` Jordan Vrtanoski
2021-11-22 19:53 ` Russell King (Oracle)
2021-11-23 12:20 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YZlPeoRLSJKNJZ5F@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=jordan.vrtanoski@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mw@semihalf.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).