RE: [PATCH net-next V2 4/5] net: lan743x: Implement phylink pcs

[Ronnie.Kunin]

> > - Furthermore, I need to check with the HW architect, but I suspect
> >   that the block that was not selected is shutdown to save power as
> >   well.
> 
> I would also expect that when the PCS device is probed, it is left in a lower power state. For an external
> PHY, you don't need the PCS running until the PHY has link, autoneg has completed, and phylink will tell
> you to configure the PCS to SGMII or 2500BaseX. For an SFP, you need to read out the contents of the SFP
> EEPROM, look for LOS to indicate there is link, and then phylink will determine SGMII, 1000BaseX or
> 2500BaseX and tell you how to configure it. It is only at that point do you need to take the PCS out of low
> power mode.
> 
> Independent of RGMII vs SGMII/BASEX, the MDIO bus always exists. Both modes need it. And Linux just
> considers it an MDIO, not necessarily an MDIO bus for this MAC. So i would expect to always see a fully
> functioning MDIO bus.
> 
> One of the weird and wonderful use cases: There are lots of ComExpress boards with Intel 10G Ethernet
> interfaces. There are developers who create base boards for them with Ethernet switches. They connect
> the 10G interface to one port of the switch. But to manage the switch they need MDIO. The Intel 10G
> drivers bury the MDIO in firmware, Linux cannot access is. So they are forced to use three GPIOs and
> bitbang MDIO. It is slow. Now imaging i put your device on the baseboard. I use its MAC connected to a
> 1G/2.5G PHY, on the MDIO bus, which i uses as the management interface for the box. Additional i
> connect the MDIO bus to the switch, to manage the switch. Linux has no problems with this, MDIO is just
> a bus with devices on it. But phylink will want access to the PCS to switch it between SGMII and
> 2500BaseX depending on what the PHY negotiates. Plus we need C45 to talk to the switch.
> 
> The proposed hijacking for C45 from the MDIO bus to talk to the PCS when there is an SFP breaks this, and
> as far as i can see, for no real reason other than being too lazy to put the PCS on its own Linux MDIO bus.

Ok, I see I probably misunderstood what had to "always exists" (assumed everything) as you mentioned in your previous email for Linux to make use of the frameworks. Interesting use cases, thanks.  

As I have mentioned before I am not (and will likely never be) a Linux expert. I have just been advising Raju from the perspective of how the chip hardware works, the drivers I have written for it for a different OS, and what our customers have been requiring from us. I wasn't advocating against instantiating a second MDIO bus or whatever else makes sense in the Linux frameworks/environment, specially if the overhead to implement it is low and allows for richer or alternative use cases. I was just pointing out potential problems based on my knowledge of our hardware and the information I was told (now obviously misunderstood and/or incomplete) about these newer Linux frameworks (phylink, xpcs, sfp) by Raju / was understanding from your email. Unfortunately today was Raju's last day with Microchip, so I guess this discussions will probably pause for a while until a new developer is allocated to continue/complete this patch set.