Re: [PATCH net v2] net: pcs: enable autonegotiation for 10g-usxgmii

On Mon, Aug 24, 2026 at 12:36:12PM +0200, Patryk Biel wrote:

The Lynx PCS USXGMII setup programs the replicator advertisement, but
does not explicitly enable and restart in-band autonegotiation or program
the replicator link timers.

This leaves the PCS dependent on firmware or bootloader state. Systems
which do not get the USXGMII replicator preconfigured before Linux may
therefore fail to negotiate the link correctly.

After programming the USXGMII device ability, configure the replicator
BMCR with reset, autonegotiation enable and autonegotiation restart. Also
program the replicator link timer registers with the values used by the
ENETC/Felix setup.

Signed-off-by: Patryk Biel <redacted>
---
This is a follow-up to the discussion started here:

Link: https://lore.kernel.org/netdev/CA+DkFDaW_wJ5p9_P7pMpz-8iE6xeKkdF-MQcd2m2GcyVUE3S4Q@mail.gmail.com/ (local)

To summarize: on systems that don't rely on the U-Boot Felix switch
driver to pre-configure 10G-QXGMII in-band autonegotiation, the Lynx
PCS USXGMII code programs the replicator device ability but never
actually enables/restarts autonegotiation nor sets up the replicator
link timers. This leaves link establishment dependent on bootloader
state that isn't guaranteed to exist.

This series only addresses the PCS side of the problem: it configures
the USXGMII replicator BMCR (reset/AN enable/AN restart) and the link
timer registers whenever lynx_pcs_config_usxgmii() is called, so that
in-band AN comes up correctly regardless of what the bootloader did.

It intentionally does NOT yet remove the "only supports in-band AN for
now" limitation, nor does it wire up neg_mode-based configuration to
support the managed = "in-band-status" property being absent from the
device tree. That part still needs more work/testing on my side (in
particular the in-band-disable path isn't behaving as expected yet
with the PHY I'm testing against), and I'd like to discuss the right
approach for it separately before sending a follow-up series.

Feedback welcome, especially on whether this is an acceptable
incremental step or whether it should be bundled together with the
neg_mode/in-band-disable work

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?