Re: Aquantia PHY in OCSGMII mode?

Alexander Wilhelm
2025-10-02T06:03:09Z

On Thu, Aug 28, 2025 at 12:28:59PM +0300, Vladimir Oltean wrote:
> On Wed, Aug 27, 2025 at 10:13:59AM +0100, Russell King (Oracle) wrote:
> > On Wed, Aug 27, 2025 at 11:03:42AM +0200, Alexander Wilhelm wrote:
> > > I asked the hardware engineer again. The point is that the MAC does not set
> > > SGMII for 100M. It still uses 2500base-x but with 10x paket repetition.
> >
> > No one uses symbol repetition when in 2500base-x mode. Nothing supports
> > it. Every device datasheet I've read states clearly that symbol
> > repetition is unsupported when operating at 2.5Gbps.
> >
> > Also think about what this means. If the link is operating at 2.5Gbps
> > with a 10x symbol repetition, that means the link would be passing
> > 250Mbps. That's not compatible with _anything_.
>
> FWIW, claim 5 of this active Cisco patent suggests dividing frames into
> 2 segments, replicating symbols from the first segment twice and symbols
> from the second segment three times.
> https://urldefense.com/v3/__https://patents.google.com/patent/US7356047B1/en__;!!I9LPvj3b!Fx2G5geAtgbXRIF2G5-FXZ1uR8K3DzHG9gwbOA0N3YRTEz4_c9Mx58Ejphl6RPuN5KXYHzAKyvPHyYnKNl1oJiY2aFmSNbRZ$
>
> I'm completely unaware of any implementations of this either, though.
>
> To remain on topic, I don't see how the hardware engineer's claim can be
> true. The PCS symbol replication is done through the IF_MODE_SPEED
> field, which lynx_pcs_link_up_2500basex() sets to SGMII_SPEED_2500 (same
> as SGMII_SPEED_1000, i.e. no replication). You can confirm that the
> IF_MODE register has the expected value by putting a print.

Hi Vladimir,

Thanks your for the hint with the IF_MODE register, I finally found the
root cause of my issue. Unfortunately, my U-Boot implementation was setting
the `IF_MODE_SGMII_EN` and `IF_MODE_USE_SGMII_AN` bits. This caused a 10x
symbol replication when operating at 100M speed. At the same time, the
`pcs-lynx` driver never modified these bits when 2500Base-X was configured.

I was able to fix this in U-Boot. Additionally, I explicitly cleared these
bits in the Lynx driver whenever 2500Base-X is configured (see patch
below). I’d like to hear your expertise on this: do you think this patch is
necessary, or could there be scenarios where these flags should remain set
for 2500Base-X?

Best regards
Alexander Wilhelm
---
drivers/net/pcs/pcs-lynx.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/net/pcs/pcs-lynx.c b/drivers/net/pcs/pcs-lynx.c
index 23b40e9eacbb..2774c62fb0db 100644
--- a/drivers/net/pcs/pcs-lynx.c
+++ b/drivers/net/pcs/pcs-lynx.c
@@ -169,6 +169,25 @@ static int lynx_pcs_config_giga(struct mdio_device *pcs,
neg_mode);
}

+static int lynx_pcs_config_2500basex(struct mdio_device *pcs,
+ unsigned int neg_mode)
+{
+ int err;
+
+ if (neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED) {
+ dev_err(&pcs->dev,
+ "AN not supported on 3.125GHz SerDes lane\n");
+ return -EOPNOTSUPP;
+ }
+
+ err = mdiodev_modify(pcs, IF_MODE,
+ IF_MODE_SGMII_EN | IF_MODE_USE_SGMII_AN, 0);
+ if (err)
+ return err;
+
+ return 0;
+}
+
static int lynx_pcs_config_usxgmii(struct mdio_device *pcs,
const unsigned long *advertising,
unsigned int neg_mode)
@@ -201,12 +220,7 @@ static int lynx_pcs_config(struct phylink_pcs *pcs, unsigned int neg_mode,
return lynx_pcs_config_giga(lynx->mdio, ifmode, advertising,
neg_mode);
case PHY_INTERFACE_MODE_2500BASEX:
- if (neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED) {
- dev_err(&lynx->mdio->dev,
- "AN not supported on 3.125GHz SerDes lane\n");
- return -EOPNOTSUPP;
- }
- break;
+ return lynx_pcs_config_2500basex(lynx->mdio, neg_mode);
case PHY_INTERFACE_MODE_USXGMII:
return lynx_pcs_config_usxgmii(lynx->mdio, advertising,
neg_mode);

base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
--
2.43.0