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

[Patryk Biel]

Hi,

On Thu, Aug 27, 2026 at 10:55 AM Vladimir Oltean
<vladimir.oltean@xxxxxxx> 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. 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?

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.

Best regards
Patryk