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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Jun 2024 07:27:21 +0200
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Vladimir Oltean <olteanv@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>, Andrew Lunn <andrew@...n.ch>,
	Eric Dumazet <edumazet@...gle.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Woojung Huh <woojung.huh@...rochip.com>,
	Arun Ramadoss <arun.ramadoss@...rochip.com>,
	Lucas Stach <l.stach@...gutronix.de>, kernel@...gutronix.de,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net-next v1 3/3] net: dsa: microchip: lan937x: disable
 VPHY output

On Fri, Jun 28, 2024 at 01:38:18AM +0300, Vladimir Oltean wrote:
> On Thu, Jun 27, 2024 at 02:39:11PM +0200, Oleksij Rempel wrote:
> > The VPHY is a compatibility functionality to be able to attach network
> > drivers without fixed-link support to the switch, which generally
> > should not be needed with linux network drivers.
> 
> Sorry, I don't have much to base my judgement upon. I did search for the
> "VPHY" string and found it to be accessed in the dev_ops->r_phy() and
> dev_ops->w_phy() implementations, suggesting that it is more than just
> that? These methods are used for accessing the registers of the embedded
> PHYs for user ports. I don't see what is the connection with RGMII on
> the CPU port.

My understanding of the VPHY concept in the LAN937x switches is as
follows:

The VPHY in the LAN937x series provides an emulated MII management
interface (MDIO) per IEEE 802.3, allowing a MAC with an unmodified
driver to interact with the switch as if it is attached to a single port
PHY. This emulation includes a full bank of registers that comply with
IEEE 802.3 and supports auto-negotiation to configure link parameters.
At the same time, this functionality seems to be used to handle clock
crossings for integrated PHYs. To avoid a degradation of SPI_CLK, an
indirect mechanism has been added to the VPHY for accessing the PHY
registers.

However, when VPHY mode is enabled, it defaults to a 100Mbit link speed
during auto-negotiation, particularly affecting RGMII links. This
behavior overrides the MAC configuration set via the P_XMII_CTRL_1
register, which should allow for choosing between 10, 100, and 1000Mbit
speeds, as done similarly in the KSZ9477 variants.

The problem arises because, with VPHY enabled, the MAC configuration on
the CPU port is ignored, and the system is stuck at the default 100Mbit
speed. Disabling the VPHY output ensures that the MAC configuration set
via the P_XMII_CTRL_1 register is respected, allowing the CPU port to
operate at the desired speed (10, 100, or 1000Mbit).

I tried to configure the CPU MAC by using the VPHY interface but had no
luck with it (maybe I handled it wrong). This change was tested on my
system, and I do not see a visible degradation in the functionality of
the integrated PHYs. This might still work because the SPI clock on my
board is limited to 5MHz.

The following article seems to confirm the behavior I observed and
supports the proposed solution:
https://microchip.my.site.com/s/article/LAN937X-The-required-configuration-for-the-external-MAC-port-to-operate-at-RGMII-to-RGMII-1Gbps-link-speed

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ