[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200214150826.GF15299@lunn.ch>
Date: Fri, 14 Feb 2020 16:08:26 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc: netdev@...r.kernel.org, Florian Fainelli <f.fainelli@...il.com>,
Sean Wang <sean.wang@...iatek.com>,
John Crispin <john@...ozen.org>,
Mark Lee <Mark-MC.Lee@...iatek.com>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...com>,
Jose Abreu <joabreu@...opsys.com>,
Vladimir Oltean <olteanv@...il.com>,
Radhey Shyam Pandey <radhey.shyam.pandey@...inx.com>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Ioana Ciornei <ioana.ciornei@....com>
Subject: Re: Heads up: phylink changes for next merge window
> 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.
Andrew
Powered by blists - more mailing lists