netdev - Re: Multi-PHYs and multiple-ports bonding support

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: <Y00fYeZEcG/E3FPV@shell.armlinux.org.uk>
Date:   Mon, 17 Oct 2022 10:24:49 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc:     netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Antoine Tenart <atenart@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Tobias Waldekranz <tobias@...dekranz.com>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: Multi-PHYs and multiple-ports bonding support

On Mon, Oct 17, 2022 at 10:51:00AM +0200, Maxime Chevallier wrote:
> 2) Changes in Phylink
> 
> This might be the tricky part, as we need to track several ports,
> possibly connected to different PHYs, to get their state. For now, I
> haven't prototyped any of this yet.

The problem is _way_ larger than phylink. It's a fundamental throughout
the net layer that there is one-PHY to one-MAC relationship. Phylink
just adopts this because it is the established norm, and trying to fix
it is rather rediculous without a use case.

See code such as the ethtool code, where the MAC and associated layers
are# entirely bypassed with all the PHY-accessing ethtool commands and
the commands are passed directly to phylib for the PHY registered
against the netdev.

We do have use cases though - consider a setup such as the mcbin with
the 3310 in SGMII mode on the fibre link and a copper PHY plugged in
with its own PHY - a stacked PHY situation (we don't support this
right now.) Which PHY should the MII ioctls, ethtool, and possibly the
PTP timestamp code be accessing with a copper SFP module plugged in?

This needs to be solved for your multi-PHY case, because you need to
deal with programming e.g. the link advertisement in both PHYs, not
just one - and with the above model, you have no choice which PHY gets
the call, it's always going to be the one registered with the netdev.

The point I'm making is that you're suggesting this is a phylink issue,
but it isn't, it's a generic networking layering bypass issue. If the
net code always forwarded the ethtool etc stuff to the MAC and let the
MAC make appropriate decisions about how these were handled, then we
would have a properly layered approach where each layer can decide
how a particular interface is implemented - to cope with situations
such as the one you describe.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!