Thread (35 messages) 35 messages, 6 authors, 2023-10-03

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help