Netdev List
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Patryk Biel <pbiel7@gmail.com>
Cc: Ioana Ciornei <ioana.ciornei@nxp.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v2] net: pcs: enable autonegotiation for 10g-usxgmii
Date: Thu, 27 Aug 2026 12:48:12 +0300	[thread overview]
Message-ID: <20260827094812.52skjha73d3fddod@skbuf> (raw)
In-Reply-To: <CA+DkFDboHq+fw1bYdQR_2M9hM+Vp6W=jR0VYCO8u7KXWVq9F4A@mail.gmail.com> <CA+DkFDboHq+fw1bYdQR_2M9hM+Vp6W=jR0VYCO8u7KXWVq9F4A@mail.gmail.com>

On Thu, Aug 27, 2026 at 11:13:15AM +0200, Patryk Biel wrote:
> Hi,
> 
> On Thu, Aug 27, 2026 at 10:55 AM Vladimir Oltean
> <vladimir.oltean@nxp.com> wrote:
> > Furthermore, you don't need such a long text under ---, it will be
> > discarded when applying the patch. Fold whatever information isn't
> > duplicated in the commit message and drop the rest.
> >
> > It is acceptable as an incremental step because logically, it is a
> > different change compared to also supporting PHYLINK_PCS_NEG_INBAND_DISABLED.
> > No matter whether you also submit that or not, they would still be
> > separate patches.
> >
> > I guess the more important question is: do you also plan to submit a
> > PHYLINK_PCS_NEG_INBAND_DISABLED patch? Any problems there?
> 
> Yes I plan to submit this patch also, however I'm still working on
> disabling in-band autoneg on phy side as the procedure is not clearly
> described and I'm trying to recreate it from vendor's sdk code, and
> it's not that easy as the sdk carries I believe support for all their
> phys.
> However I also have one question regarding
> PHYLINK_PCS_NEG_INBAND_DISABLED on the host side. I planned to discuss
> it separately however, since you brought up this topic here, I would
> like to discuss one thing that is not clear for me and as you are the
> expert in this domain, perhaps you would be able to give me some
> hints.

As they say, an expert is someone who has made all the mistakes in one
area. I've definitely made a lot of mistakes, but I'm not sure I'm quite
there yet :-/

> Looking at the lynx_pcs_link_up_sgmii, once the neg_mode
> differs from PHYLINK_PCS_NEG_INBAND_ENABLED, the IF_MODE register is
> explicitly programmed with speed and duplex values. I browsed through
> the manual but did not find any similar register for 10g-qxgmii. This
> may just be due to my limited understanding of this area, but is this
> intentional? There is no need to epicly program speed and mode for 10g
> qxmgii with in-band autoneg off?

Yes, I suppose there should be.

I also don't see a register in the MDIO address space.

I do see QXGMIIaCR2 field USX_FORCE_SPD, but that's in the SerDes
protocol converter wrapper space (which is handled by
drivers/phy/freescale/phy-fsl-lynx-10g.c), so that's a bit unfortunate.

Looking at this register, it's not clear to me how individual 10G-QXGMII
ports could have their speeds forced individually to different values.
The single register handles the entire multi-port protocol converter,
it's not like QXGMIIaCR4-QXGMIIaCR7 which are per port.
This is something else I'll have to ask internally.

> Given all of the above, I just wanted to add that I'll be on vacation
> for three weeks starting at the beginning of September.
> So if you'd prefer to send these changes yourself before then, please
> don't let me be a blocker.

That's fine, I'll also have some vacation time during the same interval,
you can submit the work to net-next when you return.

  reply	other threads:[~2026-08-27  9:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 10:36 [PATCH net v2] net: pcs: enable autonegotiation for 10g-usxgmii Patryk Biel
2026-08-25 21:49 ` Vladimir Oltean
2026-08-26  7:37   ` Patryk Biel
2026-08-26 15:36     ` Vladimir Oltean
2026-08-27  8:59       ` Patryk Biel
2026-08-27  9:18         ` Vladimir Oltean
2026-08-27  8:55 ` Vladimir Oltean
2026-08-27  9:13   ` Patryk Biel
2026-08-27  9:48     ` Vladimir Oltean [this message]
2026-08-27 10:18       ` Patryk Biel

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=20260827094812.52skjha73d3fddod@skbuf \
    --to=vladimir.oltean@nxp.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=ioana.ciornei@nxp.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pbiel7@gmail.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