Message-ID:
 <PH8PR11MB7965B1A0ABAF1AAD42C57F1A95652@PH8PR11MB7965.namprd11.prod.outlook.com>
Date: Fri, 13 Sep 2024 14:23:03 +0000
From: <Ronnie.Kunin@...rochip.com>
To: <andrew@...n.ch>, <Raju.Lakkaraju@...rochip.com>
CC: <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

> > It's my mistake. We don't need 2 MDIO buses.
> > If SFP present, XPC's MDIO bus can use, If not sfp, LAN743x MDIO bus
> > can use.
> 
> I still think this is wrong. Don't focus on 'sfp present'.
> 
> Other MAC drivers don't even know there is an SFP cage connected vs a PHY. They just tell phylink the list
> of link modes they support, and phylink tells it which one to use when the media has link.
> 
> You have a set of hardware building blocks, A MAC, a PCS, an MDIO bus.
> Use the given abstractions in Linux to export them to the core, and then let Linux combine them as
> needed.
> 
> Back to my question about EEPROM vs fuses. I assume it is an EEPROM, ...

How RGMII vs "SGMII-BASEX"  is controlled ?
The hardware default is RGMII. That can be overwritten by OTP (similar functionality to EFuse, inside the PCI11010), which also can be further overwritten by EEPROM (outside the PCI11010). That will setup the initial value the device will have by the time the software first sees it. But it is a live bit in a register, so it can be changed at runtime if it was desired.

> ... and the PCS always exists. So
> always instantiate an MDIO bus and instantiate the PCS. The MDIO bus always exists, so instantiate an
> MDIO bus.

No, you can't do that with this device because:
- There are shared pins in the chip between RGMII and SGMII/BASEX (and before you comment that it is a shame/bad hw design/etc: this chip has a lot of other functionality besides ethernet which results in physical constraints, so tradeoffs had to be done). The selection of which functionality is the active one on the pins is done by that SGMII_EN control we have been talking about. Most of our customer designs have one type interface only which is hardwired on the PCB design, and the setting in OTP/EEPROM informs our chip what it is (as I said if you wanted to flip it later either for something fairly static coming from elsewhere - i.e. BIOS settings, DT, etc -, or even runtime fully dynamic you also can, but with the restriction that only one of them can be used at a time).
- 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.

> 
> The driver itself should not really need to take any notice of the EEPROM contents. All the EEPROM is
> used for is to indicate what swnodes to create. It is a replacement of DT. Look at other drivers, they don't
> parse DT to see if there is an SFP and so instantiate different blocks.
> 
> As a silicon vendor, you want to export all the capabilities of the device, and then sit back and watch all
> the weird and wonderful ways you never even imagined it could be used come to life.
> 
> One such use case: What you can express in the EEPROM is very limited. I would not be too surprised if
> somebody comes along and adds DT overlay support. Look at what is going on with MikrotekBus and the
> RPI add on chip RP1. Even microchip itself is using DT overlays with some of its switch chips.
> 
>         Andrew

Powered by blists - more mailing lists