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