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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PH8PR11MB7965462BB26287CB056A5EEB95652@PH8PR11MB7965.namprd11.prod.outlook.com>
Date: Fri, 13 Sep 2024 22:53:04 +0000
From: <Ronnie.Kunin@...rochip.com>
To: <andrew@...n.ch>
CC: <Raju.Lakkaraju@...rochip.com>, <netdev@...r.kernel.org>,
	<davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<pabeni@...hat.com>, <Bryan.Whitehead@...rochip.com>,
	<UNGLinuxDriver@...rochip.com>, <linux@...linux.org.uk>,
	<maxime.chevallier@...tlin.com>, <rdunlap@...radead.org>,
	<Steen.Hegelund@...rochip.com>, <Daniel.Machon@...rochip.com>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH net-next V2 4/5] net: lan743x: Implement phylink pcs


> > - 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.