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: <ea532586-6b6b-4acc-b733-9a09ca2c7054@lunn.ch>
Date: Tue, 2 Jul 2024 21:55:16 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Maxime Chevallier <maxime.chevallier@...tlin.com>,
	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 07:13:50PM +0100, Russell King (Oracle) wrote:
> 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.

Or at least minimise them.

SQI values probably don't cause an issue in this situation, that seems
to be mostly automotive which is unlikely to have multiple PHYs.

link_down_events probably should be cleaned up and set as part of
ethtool_ops->get_link_ext_stats.

All the plca is more automotive, i doubt there will be two PHYs
involved there.

PHY tunabled we need the work bootlin is doing so we can direct to
towards a specific PHY. Going through the MAC does not help us.  The
same is true for PHY statistics.

There are no PHY drivers which implement module_info, so that bypass
can be deleted.

Work is being done on tsinfo, etc.

Cable test ideally wants to be run on the outer PHY, but again, the
bootlin work should solve this.

PSE and multiple PHYs also seems unlikely.

So i don't think the problem is too big.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ