From: Vladimir Oltean <firstname.lastname@example.org> To: Michael Walle <email@example.com> Cc: "David S. Miller" <firstname.lastname@example.org>, Jakub Kicinski <email@example.com>, Antoine Tenart <firstname.lastname@example.org>, Quentin Schulz <email@example.com>, firstname.lastname@example.org, Heiner Kallweit <email@example.com>, Andrew Lunn <firstname.lastname@example.org>, Florian Fainelli <email@example.com>, Russell King - ARM Linux admin <firstname.lastname@example.org>, Ioana Ciornei <email@example.com>, Maxim Kochetkov <firstname.lastname@example.org>, Bjarni Jonasson <email@example.com>, Steen Hegelund <firstname.lastname@example.org>, 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 20:56:20 +0200 [thread overview] Message-ID: <20210213185620.3lij467kne6cm4gk@skbuf> (raw) In-Reply-To: <email@example.com> On Sat, Feb 13, 2021 at 06:09:13PM +0100, Michael Walle wrote: > Am 2021-02-13 17:53, schrieb Michael Walle: > > Am 2021-02-13 01:36, schrieb Vladimir Oltean: > > 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. > > Scrap that. It will work if I set the speed/duplex mode in BMCR > correctly. (I tried that before, but I shifted one bit. doh). > > So that will work, but when will it be done? There is no > callback to configure the PCS side of the PHY if a link up is > detected. That's interesting/odd, on VSC8514 there is no need to force the speed of the system side to what was negotiated on media side. I took a quick look through the AR8033 datasheet and there isn't any mentioning the ability to program the SGMII link according to internal state as opposed to register settings, but it's equally possible that I'm simply not seeing it. On the other hand, I never meant for the inband autoneg setting to only be configurable both ways. I expect some PHYs are not able to operate using noinband mode, and for those I guess you should simply return -EINVAL, allowing the system designer to know that the configuration will not work and why. I think you could hook into .config_aneg_done, for the autoneg=true case, and into .config_aneg for autoneg=false (I'm talking about autoneg on media side here), but honestly I think the PHY is pretty broken for requiring external coordination between the clause 28 and the clause 37 PCS. So unless there is a real need to configure noinband mode, I would probably not bother.
next prev parent reply other threads:[~2021-02-13 18:58 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 2021-02-13 17:09 ` Michael Walle 2021-02-13 18:56 ` Vladimir Oltean [this message] 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 \ --in-reply-to=20210213185620.3lij467kne6cm4gk@skbuf \ --firstname.lastname@example.org \ --cc=UNGLinuxDriver@microchip.com \ --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 \ --firstname.lastname@example.org \ --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).