Re: Heads up: phylink changes for next merge window - Russell King

From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, Florian Fainelli <f.fainelli@gmail.com>,
	Sean Wang <sean.wang@mediatek.com>,
	John Crispin <john@phrozen.org>,
	Mark Lee <Mark-MC.Lee@mediatek.com>,
	Giuseppe Cavallaro <peppe.cavallaro@st.com>,
	Alexandre Torgue <alexandre.torgue@st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Ioana Ciornei <ioana.ciornei@nxp.com>
Subject: Re: Heads up: phylink changes for next merge window
Date: Fri, 14 Feb 2020 20:42:41 +0000	[thread overview]
Message-ID: <20200214204241.GQ25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <20200214150826.GF15299@lunn.ch>

On Fri, Feb 14, 2020 at 04:08:26PM +0100, Andrew Lunn wrote:
> > The reasoning is, if the PHY detect bit is set, the PPU should be
> > polling the attached PHY and automatically updating the MAC to reflect
> > the PHY status.  This seems great...
> > 
> > On the ZII dev rev C, we have the following port status values:
> > - port 0 = 0xe04
> > - port 1 through 8 = 0x100f
> > - port 9 = 0x49
> > - port 10 = 0xcf4c
> > 
> > On the ZII dev rev B, port 4 (which is one of the optical ports) has a
> > value of 0xde09, despite being linked to the on-board serdes.  It seems
> > that the PPU on the 88e6352 automatically propagates the status from the
> > serdes there.
> > 
> > So, it looks to me like using the PHY detect bit is the right solution,
> > we just need access to it at this mid-layer...
> 
> Hi Russell
> 
> We need to be careful of the PPU. I'm assuming it uses MDIO to access
> the PHY registers. We have code which allows the PHY page to the
> changed, e.g. hwmon to get the temperature sensors, and i will soon
> have code for cable diagnostics. We don't want the PPU reading some
> temperature sensor registers and configuring the MAC based on that.
> 
> For cases not using a PHY, e.g. the SERDES on the 6352, it might be
> safe to use the PPU.

Bear in mind that the PPU has been used for some time.

However, what I read in some of the functional specs is the built-in
PHYs use a more "direct" method to communicate their negotiated results
to the MAC.  Whether that also applies to the 6352 Serdes or not, I
don't know, but as port 4 will automatically switch between the
built-in copper PHY and Serdes depending on which link comes up first.

It's interesting, however, reading some of the functional specs, where
some say that the PPU must be globally disabled before access is
allowed to the MDIO bus, others the bit for globally disabling the PPU
is "reserved".

That all said, using the PPU PHY_DETECT bit seems to me to be the right
solution - if the chip is polling the PHYs itself, we want to unforce
the speed, duplex and pause, otherwise we need to force them to the
link parameters.  If we need to disable the PPU for a port, then
disabling PHY_DETECT seems like the right answer.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up