Re: [PATCH net-next v3 2/5] net: phy: Add support for the Maxio MAE0621A
From: Andrew Lunn <andrew@lunn.ch>
Date: 2026-09-27 17:23:31
Also in:
linux-devicetree, lkml
On Sun, Sep 27, 2026 at 12:56:22AM +0200, Andre Przywara wrote:
From: Liu Changjie <redacted> Add exact PHY ID matching and optional 125 MHz CLKOUT configuration for the Maxio MAE0621A Gigabit Ethernet PHY. Preserve the existing hardware configuration when the firmware property is absent. Signed-off-by: Liu Changjie <redacted> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
I sent a follow up email saying i was withdrawing this
Reviewed-by. Please ensure it has been dropped for the moment.
pw-bot: cr
This is an RGMII PHY. However it totally ignores phydev->interface.
There are four values which we require the PHY driver to act on:
PHY_INTERFACE_MODE_RGMII,
PHY_INTERFACE_MODE_RGMII_ID,
PHY_INTERFACE_MODE_RGMII_RXID,
PHY_INTERFACE_MODE_RGMII_TXID,
Every other RGMII PHY in linux will configure the delays based on
these values. If these values are ignored, bad things will happen.
From what i understand, the delays are currently configured by
strapping. We are going to get into situations where the strapping and
what the MAC requests are different but no errors are reported. DT
developers are already bad with RGMII delays, and this is just going
to make it worse.
So you have some choices:
1) Implement configuring the delays in the PHY driver
2) Find out how the delays are currently configured and return
EOPNOTSUPP if the requested configuration is different to the
current configuration.
3) Always return EOPNOTSUPP for all the RGMII values, and only accept
PHY_INTERFACE_MODE_NA, which means configuration has been performed
using some other mechanism, the PHY driver should not change it.
Additionally, my understanding is this PHY will respond to address 0
as a broadcast address. This is not part of 802.3, and always causes
issues. Please ensure this is turned off.
Andrew