On Tue, 2 Jun 2020 at 00:21, Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx> wrote: > > On Mon, Jun 01, 2020 at 11:57:30PM +0300, Vladimir Oltean wrote: > > On Mon, 1 Jun 2020 at 03:28, Russell King - ARM Linux admin > > <linux@xxxxxxxxxxxxxxx> wrote: > > > And yes, I do have some copper SFP modules that have an (inaccessible) > > > AR803x PHY on them - Microtik S-RJ01 to be exact. I forget exactly > > > which variant it is, and no, I haven't seen any of this "SGMII fails > > > to come up" - in fact, the in-band SGMII status is the only way to > > > know what the PHY negotiated with its link partner... and this SFP > > > module works with phylink with no issues. > > > > See, you should also specify what kernel you're testing on. Since > > Heiner did the PHY_AN cleanup, phy_aneg_done is basically dead code > > from the state machine's perspective, only a few random drivers call > > it: > > https://elixir.bootlin.com/linux/latest/A/ident/phy_aneg_done > > So I would not be at all surprised that you're not hitting it simply > > because at803x_aneg_done is never in your call path. > > Please re-read the paragraph of my reply that is quoted above, and > consider your response to it in light of the word *inaccessible* in > my paragraph above. > > Specifically, ask yourself the question: "if the PHY is inaccessible, > does it matter what kernel version is being tested? Does it matter > what the at803x code is doing?" > > The point that I was trying to get across, but you seem to have missed, > is that this SFP module uses an AR803x PHY that is inaccessible and I > have never seen a problem with the SGMII side coming up - and if the > SGMII side does not come up, we have no way to know what the copper > side is doing. With this module, we are totally reliant on the SGMII > side working correctly to work out what the copper side status is. > > *Frustrated*. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up So I ignored the "inaccessible" part because I failed to understand the relevance of your reply given the issue at hand. I wasn't trying to suggest that the AT803x SGMII AN logic is broken.
