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
| ||
|
Message-ID: <651e94ab.0c0a0220.2c147.1299@mx.google.com> Date: Thu, 5 Oct 2023 12:49:13 +0200 From: Christian Marangi <ansuelsmth@...il.com> To: Marek Behún <kabel@...nel.org> Cc: "David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org Subject: Re: [PATCH net v2 2/2] net: dsa: qca8k: fix potential MDIO bus conflict when accessing internal PHYs via management frames On Wed, Oct 04, 2023 at 11:19:04AM +0200, Marek Behún wrote: > Besides the QCA8337 switch the Turris 1.x device has on it's MDIO bus > also Micron ethernet PHY (dedicated to the WAN port). > > We've been experiencing a strange behavior of the WAN ethernet > interface, wherein the WAN PHY started timing out the MDIO accesses, for > example when the interface was brought down and then back up. > > Bisecting led to commit 2cd548566384 ("net: dsa: qca8k: add support for > phy read/write with mgmt Ethernet"), which added support to access the > QCA8337 switch's internal PHYs via management ethernet frames. > > Connecting the MDIO bus pins onto an oscilloscope, I was able to see > that the MDIO bus was active whenever a request to read/write an > internal PHY register was done via an management ethernet frame. > > My theory is that when the switch core always communicates with the > internal PHYs via the MDIO bus, even when externally we request the > access via ethernet. This MDIO bus is the same one via which the switch > and internal PHYs are accessible to the board, and the board may have > other devices connected on this bus. An ASCII illustration may give more > insight: > > +---------+ > +----| | > | | WAN PHY | > | +--| | > | | +---------+ > | | > | | +----------------------------------+ > | | | QCA8337 | > MDC | | | +-------+ | > ------o-+--|--------o------------o--| | | > MDIO | | | | | PHY 1 |-|--to RJ45 > --------o--|---o----+---------o--+--| | | > | | | | | +-------+ | > | +-------------+ | o--| | | > | | MDIO MDC | | | | PHY 2 |-|--to RJ45 > eth1 | | | o--+--| | | > -----------|-|port0 | | | +-------+ | > | | | | o--| | | > | | switch core | | | | PHY 3 |-|--to RJ45 > | +-------------+ o--+--| | | > | | | +-------+ | > | | o--| ... | | > +----------------------------------+ > > When we send a request to read an internal PHY register via an ethernet > management frame via eth1, the switch core receives the ethernet frame > on port 0 and then communicates with the internal PHY via MDIO. At this > time, other potential devices, such as the WAN PHY on Turris 1.x, cannot > use the MDIO bus, since it may cause a bus conflict. > > Fix this issue by locking the MDIO bus even when we are accessing the > PHY registers via ethernet management frames. > > Fixes: 2cd548566384 ("net: dsa: qca8k: add support for phy read/write with mgmt Ethernet") > Signed-off-by: Marek Behún <kabel@...nel.org> Reviewed-by: Christian Marangi <ansuelsmth@...il.com> -- Ansuel
Powered by blists - more mailing lists