From: Michael Walle <email@example.com> To: Vladimir Oltean <firstname.lastname@example.org> Cc: "David S. Miller" <email@example.com>, Jakub Kicinski <firstname.lastname@example.org>, Antoine Tenart <email@example.com>, Quentin Schulz <firstname.lastname@example.org>, email@example.com, Heiner Kallweit <firstname.lastname@example.org>, Andrew Lunn <email@example.com>, Florian Fainelli <firstname.lastname@example.org>, Russell King - ARM Linux admin <email@example.com>, Ioana Ciornei <firstname.lastname@example.org>, Maxim Kochetkov <email@example.com>, Bjarni Jonasson <firstname.lastname@example.org>, Steen Hegelund <email@example.com>, UNGLinuxDriver@microchip.com Subject: Re: [PATCH net-next 1/2] net: phylink: explicitly configure in-band autoneg for PHYs that support it Date: Sat, 13 Feb 2021 17:53:41 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20210213003641.gybb6gstjpkcwr6z@skbuf> Am 2021-02-13 01:36, schrieb Vladimir Oltean: > On Fri, Feb 12, 2021 at 11:40:59PM +0100, Michael Walle wrote: >> Am 2021-02-12 18:23, schrieb Vladimir Oltean: >> > From: Vladimir Oltean <email@example.com> >> > >> > Currently Linux has no control over whether a MAC-to-PHY interface uses >> > in-band signaling or not, even though phylink has the >> > managed = "in-band-status"; >> > property which denotes that the MAC expects in-band signaling to be >> > used. >> > >> > The problem is really that if the in-band signaling is configurable in >> > both the PHY and the MAC, there is a risk that they are out of sync >> > unless phylink manages them both. Most if not all in-band autoneg state >> > machines follow IEEE 802.3 clause 37, which means that they will not >> > change the operating mode of the SERDES lane from control to data mode >> > unless in-band AN completed successfully. Therefore traffic will not >> > work. >> > >> > It is particularly unpleasant that currently, we assume that PHYs which >> > have configurable in-band AN come pre-configured from a prior boot stage >> > such as U-Boot, because once the bootloader changes, all bets are off. >> >> Fun fact, now it may be the other way around. If the bootloader >> doesn't >> configure it and the PHY isn't reset by the hardware, it won't work in >> the bootloader after a reboot ;) > > My understanding is that this is precisely the reason why the U-Boot > people don't want to support booting from RAM, and want to assume that > the nothing else ran between Power On Reset and the bootloader: > https://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM > [ that does make me wonder what they think about ARM TF-A ] It isn't that easy sometimes. Eg. there might be boards without a proper reset of the peripherals, maybe the SoC will just generate an internal reset, whatever. One might conisder that a broken board. But, for example, on the kontron sl28, we deliberatly chose not to do a PHY reset (well it is actually configurable) because this will also prevent WoL by the PHY. >> > Let's introduce a new PHY driver method for configuring in-band autoneg, >> > and make phylink be its first user. The main PHY library does not call >> > phy_config_inband_autoneg, because it does not know what to configure it >> > to. Presumably, non-phylink drivers can also call >> > phy_config_inband_autoneg >> > individually. >> >> If you disable aneg between MAC and PHY, what would be the actual >> speed >> setting/duplex mode then? I guess it have to match the external speed? >> >> I'm trying this on the AT8031. I've removed 'managed = >> "in-band-status";' >> for the PHY. Confirmed that it won't work and then I've implemented >> your >> new callback. That will disable the SGMII aneg (which is done via the >> BMCR of fiber page if I'm not entirely mistaken); ethernet will then >> work again. But only for gigabit. I presume because the speed setting >> of the SGMII link is set to gigabit. > > Which MAC driver are you testing on? enetc > Are you saying that it doesn't > force the link to the speed resolved over MDIO and passed to > .phylink_mac_link_up, or that the speed communicated to it is > incorrect? That seem to work: [ 5313.852406] fsl_enetc 0000:00:00.0 gbe0: phy link down sgmii/Unknown/Unknown [ 5313.852414] fsl_enetc 0000:00:00.0 gbe0: Link is Down [ 5315.900687] fsl_enetc 0000:00:00.0 gbe0: phy link up sgmii/100Mbps/Full [ 5315.916816] fsl_enetc 0000:00:00.0 gbe0: Link is Up - 100Mbps/Full - flow control rx/tx But the Atheros PHY seems to have a problem with the SGMII link if there is no autoneg. No matter what I do, I can't get any traffic though if its not gigabit on the copper side. Unfortunately, I don't have access to an oscilloscope right now to see whats going on on the SGMII link. -michael
next prev parent reply other threads:[~2021-02-13 16:54 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-12 17:23 [PATCH net-next 0/2] Let phylink manage in-band AN for the PHY Vladimir Oltean 2021-02-12 17:23 ` [PATCH net-next 1/2] net: phylink: explicitly configure in-band autoneg for PHYs that support it Vladimir Oltean 2021-02-12 22:40 ` Michael Walle 2021-02-13 0:18 ` Russell King - ARM Linux admin 2021-02-13 16:41 ` Michael Walle 2021-02-13 16:59 ` Andrew Lunn 2021-02-13 17:06 ` Russell King - ARM Linux admin 2021-02-13 0:36 ` Vladimir Oltean 2021-02-13 16:53 ` Michael Walle [this message] 2021-02-13 17:09 ` Michael Walle 2021-02-13 18:56 ` Vladimir Oltean 2021-02-13 19:57 ` Michael Walle 2021-02-13 20:12 ` Vladimir Oltean 2021-02-13 20:16 ` Russell King - ARM Linux admin 2021-02-14 10:35 ` Russell King - ARM Linux admin 2021-02-14 11:10 ` Vladimir Oltean 2021-02-14 13:18 ` Russell King - ARM Linux admin 2021-02-12 17:23 ` [PATCH net-next 2/2] net: phy: mscc: configure in-band auto-negotiation for VSC8514 Vladimir Oltean
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 \ --firstname.lastname@example.org \ --email@example.com \ --cc=UNGLinuxDriver@microchip.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH net-next 1/2] net: phylink: explicitly configure in-band autoneg for PHYs that support it' \ /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
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).