On Fri, Mar 28, 2025 at 2:45 PM Andrew Lunn [off-list ref] wrote:

quoted

Also I am not sure it makes sense to say we can't support multiple
modes on a fixed connection. For example in the case of SerDes links
and the like it isn't unusual to see support for CR/KR advertised at
the same speed on the same link and use the exact same configuration
so a fixed config could support both and advertise both at the same
time if I am not mistaken.

Traditionally, fixed link has only supported one mode. The combination
of speed and duplex fully describes a base-T link. Even more
traditionally, it was implemented as an emulated C22 PHY, using the
genphy driver, so limited to just 1G. With multigige PHY we needed to
be a bit more flexible, so phylink gained its own fixed link
implementation which did not emulate a PHY, just the results of
talking to a multigige PHY.

But i don't think you are actually talking about a PHY. I think you
mean the PCS advertises CR/KR, and you want to emulate a fixed-link
PCS? That is a different beast.

        Andrew

A serdes PHY is part of it, but not a traditional twisted pair PHY as
we are talking about 25R, 50R(50GAUI & LAUI), and 100P interfaces. I
agree it is a different beast, but are we saying that the fixed-link
is supposed to be a twisted pair PHY only? That is the part I am
confused with as there are multiple scenarios where you might end up
with a fixed link configuration at a specific speed for something not
twisted pair. For example in our case the firmware provides us with
the fixed modulation/lanes/fec configuration so we can essentially
take that and treat it as a fixed-link configuration.

In addition one advantage is that it makes it possible to support
speeds that don't yet have a type in the phy_interface_t, so as I was
enabling things it allowed some backwards compatibility with older
kernels. In the case of fbnic I was planning to use pcs_validate to
strip down the supported features and essentially limit things based
on the bitrate per lane and the number of lanes. We were only using CR
so for us the result should only be 1 regardless based on the speed
match.

The general idea I had in mind for upstreaming the support for fbnic
was to initially bring it up as a fixed-link setup using
PHY_INTERFACE_MODE_INTERNAL as that is essentially what we have now
and I can get rid of the extraneous 40G stuff that we aren't using.
Then we pivot into enabling additional PHY interface modes and
QSFP+/28 support in the kernel. Then I would add a mailbox based i2c
and gpio to enable SFP/QSPF on fbnic. After that we could switch fbnic
back to the inband setup with support for the higher speed interfaces.

One option I would be open to is to have me take on addressing the
issue in net-next instead of net since I would need to sort it out to
enable my patches anyway. I was mostly bringing it up as I was
concerned that I may have not been the only one impacted. I was using
the fixed-link/internal combination to basically signal to the phylink
interface that we were locked in and weren't going to change it, as
such the only impact for me is it seemed to result in a warning
message about the link configuration not being recognized and the
supported/advertised modes being empty.