[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e4603452-efe9-4a56-b33d-4872a19a05b5@lunn.ch>
Date: Fri, 25 Apr 2025 18:04:43 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Marek Behún <kabel@...nel.org>
Cc: netdev@...r.kernel.org, Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
"Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
"Rob Herring (Arm)" <robh@...nel.org>,
Javier Carrasco <javier.carrasco.cruz@...il.com>,
Wojciech Drewek <wojciech.drewek@...el.com>,
Matthias Schiffer <mschiffer@...verse-factory.net>,
Christian Marangi <ansuelsmth@...il.com>,
Marek Mojík <marek.mojik@....cz>
Subject: Re: [PATCH net] net: dsa: qca8k: forbid management frames access to
internal PHYs if another device is on the MDIO bus
On Fri, Apr 25, 2025 at 05:13:09PM +0200, Marek Behún wrote:
> Completely forbid access to the internal switch PHYs via management
> frames if there is another MDIO device on the MDIO bus besides the QCA8K
> switch.
>
> It seems that when internal PHYs are accessed via management frames,
> internally the switch core translates these requests to MDIO accesses
> and communicates with the internal PHYs via the MDIO bus. This
> communication leaks outside on the MDC and MDIO pins. If there is
> another PHY device connected on the MDIO bus besides the QCA8K switch,
> and the kernel tries to communicate with the PHY at the same time, the
> communication gets corrupted.
>
> This makes the WAN PHY break on the Turris 1.x device.
Let me see if i understand the architecture correctly...
You have a host MDIO bus, which has both the QCA8K and a PHY on it.
Within the QCA8K there are a number of PHYs. Looking at qca8k-8xxx.c,
there is qca8k_mdio_write() and qca8k_mdio_read() which use a register
within the switch to access an MDIO bus for the internal PHYs. The
assumption is that the internal MDIO is isolated from the host MDIO
bus. That should be easy to prove, just read register 2 and 3 from all
32 addresses of the host MDIO bus, and make sure you don't find the
internal PHYs.
The issue is that when you use MDIO over Ethernet frames, both the
internal and external bus see the bus transaction. This happens
asynchronously to whatever the host MDIO bus driver is doing, and you
sometimes get collisions. This in theory should affect both the PHY
and the switch on the bus, but maybe because of the address being
accessed, you don't notice any issue with the switch?
The assumption is that the switch hardware interpreting the MDIO over
Ethernet is driving both the internal and external MDIO bus. Again,
this should be easy to prove, read ID registers 2 and 3 from the
address the external PHY is on, and see what you get.
I guess the real question here is, has it been proven that there are
actually two MDIO busses, not one bus with two masters? I could
theoretically see an architecture where the switch is not managed over
MDIO at all. It has an EEPROM to do sufficient configuration that you
can do all the management using Ethernet frames. The MDIO over
Ethernet then allow you to manage any external PHYs.
Andrew
Powered by blists - more mailing lists