Re: [RFC PATCH net-next 0/7] net: phy: introduce phy numbering
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: 2023-09-12 15:51:45
Also in:
lkml
Hello Andrew, On Tue, 12 Sep 2023 17:36:56 +0200 Andrew Lunn [off-list ref] wrote:
quoted
The PHY namespace is for now contained within struct net_device, meaning that PHYs that aren't related at all to any net_device wouldn't be numbered as of right now. The only case I identified is when a PHY sits between 2 DSA switches, but I don't know how relevant this is.It might be relevant for the CPU port of the switch. The SoC ethernet with a PHY has its PHY associated to a netdev, and so it can be managed. However, the CPU port does not have a netdev, so the PHY is a bit homeless. Phylink gained the ability to manage PHYs which are not associated to a netdev, so i think it can manage such a PHY. If not, we assume the PHY is strapped to perform link up and autoneg on power on, and otherwise leave it alone.
I agree and my plan, although still a bit hazy, is to share the phy_ns between the netdev associated to the Ethernet MAC and the CPU dsa_port of the switch, as they are on the same link. We could grab infos on the PHYs connected to the port that way. Although the PHY isn't connected to the same MAC, it's part of the same link, so I think it would be OK to share the phy_ns. We already do something in that direction, which is the stats gathering on the CPU dsa port, which are reported alongside stats from the ethernet MAC. Would that be OK ? I haven't started the DSA part, I was waiting for review on the overall idea, but I tried to keep this into consideration hence the phy_ns notion :) Thanks, Maxime