[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZoRDXvO/4sxJuotC@shell.armlinux.org.uk>
Date: Tue, 2 Jul 2024 19:13:50 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Romain Gantois <romain.gantois@...tlin.com>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 5/6] net: phy: dp83869: Support SGMII SFP modules
On Tue, Jul 02, 2024 at 04:56:28PM +0200, Maxime Chevallier wrote:
> But I do agree with you in that this logic should not belong to any
> specific PHY driver, and be made generic. phylink is one place to
> implement that indeed, but so far phylink can't manage both PHYs on the
> link (if I'm not mistaken).
This is not a phylink problem, but a phy*lib* implementation problem.
It was decided that phy*lib* would take part in layering violations
with various functions called *direct* from the core networking layer
bypassing MAC drivers entirely.
Even with phy*link* that still happens - as soon as netdev->phydev
has been set, the networking core will forward PHY related calls
to that phydev bypassing the MAC driver and phylink.
If we want to start handling multiple layers of PHYs, then we have
to get rid of this layering bypass.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists