| Message ID | 20230907092407.647139-1-maxime.chevallier@bootlin.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: phy: introduce phy numbering | expand |
On Thu, 7 Sep 2023 11:23:58 +0200 Maxime Chevallier wrote: > - the netlink API would need polishing, I struggle a bit with finding > the correct netlink design pattern to return variale-length list of u32. Think of them as a list, not an array. Dump them one by one, don't try to wrap them in any way: https://docs.kernel.org/next/userspace-api/netlink/specs.html#multi-attr-arrays People have tried other things in the past: https://docs.kernel.org/next/userspace-api/netlink/genetlink-legacy.html#attribute-type-nests but in the end they add constraints and pain for little benefit.
Hello Jakub On Fri, 8 Sep 2023 08:41:08 -0700 Jakub Kicinski <kuba@kernel.org> wrote: > On Thu, 7 Sep 2023 11:23:58 +0200 Maxime Chevallier wrote: > > - the netlink API would need polishing, I struggle a bit with finding > > the correct netlink design pattern to return variale-length list of u32. > > Think of them as a list, not an array. > > Dump them one by one, don't try to wrap them in any way: > https://docs.kernel.org/next/userspace-api/netlink/specs.html#multi-attr-arrays > People have tried other things in the past: > https://docs.kernel.org/next/userspace-api/netlink/genetlink-legacy.html#attribute-type-nests > but in the end they add constraints and pain for little benefit. Thanks for the pointers, this makes much more sense than my attempt at creating an array. This and your other comment on the .do vs .dump is exactly what I was missing in my understanding of netlink. Maxime
> 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. Andrew
Hello Andrew, On Tue, 12 Sep 2023 17:36:56 +0200 Andrew Lunn <andrew@lunn.ch> wrote: > > 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
Le 07/09/2023 à 11:23, Maxime Chevallier a écrit : > [Vous ne recevez pas souvent de courriers de maxime.chevallier@bootlin.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] > > Hello everyone, > > This is the first RFC series introducing ethernet PHY numbering, in an > effort to better represent the link components and allow userspace to > configure these. > > As of today, PHY devices are hidden behind the struct net_device from > userspace, but there exists commands such as PLCA configuration, > cable-testing, soon timestamping, that actually target the phy_device. > > These commands rely on the ndev->phydev pointer to find the phy_device. > > However, there exists use-cases where we have multiple PHY devices > between the MAC and the front-facing port. The most common case right > now is when a PHY acts as a media-converter, and is wired to an SFP > port : > > [MAC] - [PHY] - [SFP][PHY] FWIW when thinking about multiple PHY to a single MAC, what comes to my mind is the SIS 900 board, and its driver net/ethernet/sis/sis900.c It has a function sis900_default_phy() that loops over all phys to find one with up-link then to put all but that one in ISOLATE mode. Then when the link goes down it loops again to find another up-link. I guess your series would also help in that case, wouldn't it ? Christophe
> FWIW when thinking about multiple PHY to a single MAC, what comes to my > mind is the SIS 900 board, and its driver net/ethernet/sis/sis900.c > > It has a function sis900_default_phy() that loops over all phys to find > one with up-link then to put all but that one in ISOLATE mode. Then when > the link goes down it loops again to find another up-link. > > I guess your series would also help in that case, wouldn't it ? Yes, it would. However, that driver would need its PHY handling re-written because it is using the old MII code, not phylib. Andrew