Re: [PATCH net-next v5 09/13] net: phylink: Use phy_caps_lookup for fixed-link configuration

[Alexander Duyck]

On Fri, Mar 28, 2025 at 2:45 PM Andrew Lunn <andrew@xxxxxxx> wrote:
>
> > 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.