TG-641: 10g copper eth1 not recover after down/up#87
Closed
paul-sirin wants to merge 4 commits into
Closed
Conversation
…TG-641) On 88X3310 with PTP enabled, TX and RX stop working from the second ip link set up onwards. The root cause is a race in mv3310_power_up(): the function issues a software reset (SWRST, MV_V2_PORT_CTRL bit 15) followed by msleep(100), but when resume is called again before the previous SWRST has fully completed, the new SWRST is issued while bit 15 is still asserted by the PHY. This corrupts the reset sequence and leaves the data path in a broken state. Fix this by polling MV_V2_PORT_CTRL bit 15 before issuing SWRST, waiting up to 200ms for the PHY to signal it is ready for a new reset (bit 15 = 0). Profiling showed that in normal operation the wait is under 10ms, but occasionally reaches ~157ms. If the poll times out, a warning is emitted and execution continues rather than aborting the power-up sequence. This is only applied to 88X3310 with firmware >= 0.3.0.0, matching the existing guard for the SWRST
…e (TG-641) Issue caused TX/RX to fail on the second and subsequent ip-link-down/up cycles on an 88X3310 PHY paired with an mvpp2 MAC configured for 10GBASE-R: wrong MACTYPE mode in config_init. mv3310_config_init forced MACTYPE to 10GBASER (XFI/SGMII auto-neg). In auto-neg mode the PHY switches its host-side serdes to SGMII at 1G link speed, which causes phylink to invoke mac_prepare/mac_config with a changed interface, which in turn causes mvpp2 to reinitialise the comphy from 10GBASE-R to SGMII. Since the 88X3310 always presents a fixed 10GBASE-R (XFI) serdes toward the MAC, the comphy reconfiguration corrupts the link and RX stays broken. Fix: always select RATE_MATCH mode (MACTYPE 6). In this mode the PHY presents a fixed 10GBASE-R serdes to the MAC and adapts the copper rate internally, so the MAC/comphy never needs reconfiguring across speed changes. Add a copper_multispeed flag to mv3310_mactype so that RATE_MATCH entries still expose SGMII/2.5G/5G in possible_interfaces, allowing phylink to validate and announce all copper speeds to user space.
…x/TG-641-10g-copper-not-recover-down-up
…G-641) Enchances 262987b net: phy: marvell10g: fix 10GBASE-R host serdes reset after link cycle (TG-641) By: - Adding a 10ms static guard delay after the poll completes, to cover the observed gap between bit 15 clearing and PHY readiness. - Increasing the post-SWRST msleep from 100ms to 200ms to cover the observed worst-case SWRST completion time of ~157ms.
Author
|
200ms timeout is close to some timing margin and thus worsening the race |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains follow-up fix for issue in 88x3310 PHY driver with more relaxed timings for SWRST command execution