netdev - Re: [net PATCH 1/2] net: phy: Cleanup handling of recent changes to phy_lookup

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] [day] [month] [year] [list]

Message-ID: <CAKgT0UeA3Nv3w52YTt-FaFA5GQcx4wrUY+CXH6-OJmWAMo7WWQ@mail.gmail.com>
Date: Mon, 7 Apr 2025 16:01:49 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Jakub Kicinski <kuba@...nel.org>, "Russell King (Oracle)" <linux@...linux.org.uk>, 
	Maxime Chevallier <maxime.chevallier@...tlin.com>, netdev@...r.kernel.org, 
	hkallweit1@...il.com, davem@...emloft.net, pabeni@...hat.com
Subject: Re: [net PATCH 1/2] net: phy: Cleanup handling of recent changes to phy_lookup_setting

On Mon, Apr 7, 2025 at 12:34 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > Arguably understanding this code, both phylink and our own MAC/PCS/PMD
> > code, has been a real grind but I think I am getting there. If I am
> > not mistaken the argument is that we aren't "fixed-link" as we have
> > control over what the PCS/PMA configuration is. We are essentially
> > managing things top down, whereas the expectation for "fixed-link" is
> > more of a bottom up.
>
> Fixed link is there to emulate something which does not
> exist. Typically you have a MAC connected to a PHY, or a MAC connected
> to an SFP. The PHY or the SFP tell you how to configure the MAC so the
> chain MAC/PHY/Media works.
>
> However, there are use cases where you connect one MAC directly to
> another MAC. E.G you connect a NIC MAC to the MAC port of a switch.
>
> Fixed link allows you to emulate the missing PHY, so that the MAC has
> no idea the PHY is missing. The end result is that the MAC gets
> configured to make the MAC-MAC link work, without the MAC even knowing
> it is connected to another MAC.
>
> When talking about top down vs bottom up, i think you mean MAC towards
> the media, vs media towards the MAC. Because of Base-T autoneg, etc,
> phylink configures stuff upwards from the media. It needs to wait for
> the PHY to determine what the media is going to do. The PHY will then
> decided what its host side needs, SGMII, 2500BaseX, 10Gbase etc. That
> then allows phylink to configure the PCS to output that. And then you
> need to configure the MAC to feed the PCSs at the correct speed. I
> don't think SFPs are so different. The SFP will probably indicate what
> its maximum bandwidth is. You configure that in the PCS and let is
> negotiate with the link partner PCS to determine the speed, pause
> etc. You can then configure the MAC with the results of that
> negotiation.

That isn't really true for phylink though. We have to specify a
phy_interface_t before autoneg is even an option. In our case that
will probably be doable since we just have to press the FW to give us
the value. If we don't have an SFP cage you aren't changing that
interface type either.

> So fixed-link is not really bottom up, the whole configuration chain
> is media towards the MAC, and it makes no difference if the PHY is
> being emulated via a fixed-link because it does not exist.

I'm not sure what you are talking about. When I refer to the bottom I
am referring to the media. That is how it is depicted in all the IEEE
drawings. I think we are actually agreeing, but I am not sure.

What I was saying is that in our case we end up with the userspace or
FW providing a link setting and we push it down to the PMD from the
MAC side of things. Whereas for something like fixed-link you are
essentially faking the autoneg and making it work from the bottom up.