Le 07/09/2023 à 11:23, Maxime Chevallier a écrit :
> [Vous ne recevez pas souvent de courriers de [email protected]. 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