netdev - Re: [net-next PATCH v2 09/11] fbnic: Add SW shim for MDIO interface to PMA/PMD and PCS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKgT0UeiLjk=9Ogqy1NU-roz4U32HXHjVs8LqRKEdnPqYNcBjQ@mail.gmail.com>
Date: Mon, 3 Nov 2025 12:18:38 -0800
From: Alexander Duyck <alexander.duyck@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, kuba@...nel.org, kernel-team@...a.com, 
	andrew+netdev@...n.ch, hkallweit1@...il.com, linux@...linux.org.uk, 
	pabeni@...hat.com, davem@...emloft.net
Subject: Re: [net-next PATCH v2 09/11] fbnic: Add SW shim for MDIO interface
 to PMA/PMD and PCS

On Mon, Nov 3, 2025 at 10:59 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> > The interface will consist of 2 PHYs each consisting of a PMA/PMD and a PCS
> > located at addresses 0 and 1.
>
> I'm missing a bit of architecture here.
>
> At least for speeds up to 10G, we have the MAC enumerate what it can
> do, the PCS enumerates its capabilities, and we read the EERPOM of the
> SFP to find out what it supports. From that, we can figure out the
> subset of link modes which are supported, and configure the MAC and
> PCS as required.

The hardware we have is divisible with multiple entities running it
parallel. It can be used as a single instance, or multiple. With our
hardware we have 2 MACs that are sharing a single QSFP connection, but
the hardware can in theory have 4 MACs sharing a QSFP-DD connection.
The basic limitation is that underneath each MAC we can support at
most 2 lanes of traffic, so just the Base-R/R2 modes. Effectively what
we would end up with is the SFP PHY having to be chained behind the
internal PHY if there is one. In the case of the CR/KR setups though
we are usually just running straight from point-to-point with a few
meter direct attach cable or internal backplane connection.

So from the MAC we have the XPCS which has support for 2 lanes. To
support that we will need to have access to 2 PCS instances as the IP
is divisible to support either 1 or 2 lanes through a single instance.
Then underneath that is an internal PCS PMA which I plan to merge in
with the PMA/PMD I am representing here as the RSFEC registers are
supposed to be a part of the PMA. Again with 2 lanes supported I need
to access two instances of it for the R2 modes. Then underneath that
we have the PMD which is configurable on a per-lane basis. Technically
it is just a SerDes PHY and doesn't have a link detection, it is just
detecting if there is a signal or not and then kicking off the
training, but we can essentially just represent it with the phydev so
that we can report if it is ready to handle the link or not.

> What information is missing from this picture that requires the
> PMA/PMD to be represented? And how is this going to work when we do
> have access to the SFPs EERPOM?

The issue is that the firmware is managing the PMD underneath us. As a
result we don't have full control of the link. One issue we are
running into is that the FW will start training when it first gets a
signal and it doesn't block the signal from getting to the PCS. The
PCS will see the signal and immediately report the link as "up" if the
quality is good enough. This results in us suddenly seeing the link
flapping for about 2-3 seconds while the training is happening. So to
prevent that from happening we are adding the phydev representing the
PMD to delay the link up by the needed 4 seconds to prevent the link
flap noise.