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
| ||
|
Message-ID: <20230912190129.21e65690@fedora> Date: Tue, 12 Sep 2023 19:01:29 +0200 From: Maxime Chevallier <maxime.chevallier@...tlin.com> To: Andrew Lunn <andrew@...n.ch> Cc: davem@...emloft.net, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Florian Fainelli <f.fainelli@...il.com>, Heiner Kallweit <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>, Vladimir Oltean <vladimir.oltean@....com>, Oleksij Rempel <linux@...pel-privat.de>, Nicolò Veronese <nicveronese@...il.com>, thomas.petazzoni@...tlin.com, Christophe Leroy <christophe.leroy@...roup.eu> Subject: Re: [RFC PATCH net-next 1/7] net: phy: introduce phy numbering and phy namespaces Hello Andrew, On Tue, 12 Sep 2023 18:15:52 +0200 Andrew Lunn <andrew@...n.ch> wrote: > On Thu, Sep 07, 2023 at 11:23:59AM +0200, Maxime Chevallier wrote: > > Link topologies containing multiple network PHYs attached to the same > > net_device can be found when using a PHY as a media converter for use > > with an SFP connector, on which an SFP transceiver containing a PHY can > > be used. > > > > With the current model, the transceiver's PHY can't be used for > > operations such as cable testing, timestamping, macsec offload, etc. > > > > The reason being that most of the logic for these configuration, coming > > from either ethtool netlink or ioctls tend to use netdev->phydev, which > > in multi-phy systems will reference the PHY closest to the MAC. > > > > Introduce a numbering scheme allowing to enumerate PHY devices that > > belong to any netdev, which can in turn allow userspace to take more > > precise decisions with regard to each PHY's configuration. > > I think we need more than a number. Topology needs to be a core > concept here, otherwise how is the user supposed to know which PHY to > use cable test on, etc. > > However, it is not a simple problem. An SFP PHY should be the last in > a chain. So you can infer something from that. When we start adding > MII muxes, they will need to be part of the modal. You raise a good point, we need to set a cursor on the level of detail we want to have to describe the topology indeed. I do have a patch that adds a notion of topology by keeping track of the upstream device of each link component (either the ethernet controller, another PHY, a mux, and SFP cage), but I got carried away trying to find the correct granularity. For example, say we have a PCS with a dedicated driver in the chain, should it be part of the topology ? or do we stick to MAC, PHY, MUX, SFP ? To address the topology and more specifically cable-testing, I relied on adding support for a phy_port, that would represent front-facing ports, each PHY would have zero, one or more phy_ports, and from userspace perspective, we would let user pick which port to use, then have kernel-side logic to either deal with PHYs that have 2 ports, or an actual mii mux with two single-port PHYs. All in all for cable-testing, this solves the problem, as we could include a way for users to know which PHY is attached to a port, and therefore users could know which PHY is the outermost one. However, it's not sufficient for things like timestamping. I think you mentionned in another thread that there can be up to 7 devices that could do the timestamping, and here it could be interesting to know which is where, so that user can for example pick a PHY that has a precise timestamping unit but that is also close-enough to the physical port. In that case, I will include what I have for topology description in the next RFC. Thanks for the insightful feedback, Maxime > Andrew
Powered by blists - more mailing lists