Re: [PATCH net-next v2 0/2] net: phy: Add Maxio MAE0621A support

[Andrew Lunn]

On Sun, Sep 27, 2026 at 04:21:50PM +0000, 刘 昌杰 wrote:
> Hi Andrew,
> 
> I checked the schematics and tested the broadcast control on an LCKFB Taishan Pi 3M (which has an MAE0621A-Q3C at PHY address 1, ID 0x7b744412).

Thanks for this testing.

> For the RGMII delays, pin 24 (RXD1/TXDLY) is pulled down (4.7k) and
> pin 25 (RXD0/RXDLY) is pulled up (4.7k). So the hardware straps are
> TXDLY=0 and RXDLY=1. Per Table 7-3 in the datasheet, this disables
> the TX delay and enables a 2ns RX delay. This matches the DT using
> `phy-mode="rgmii-rxid"` and the RK3576 GMAC `tx_delay=<0x24>`.

Unfortunately, this works, but is wrong.

https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287

phy-mode="rgmii-rxid" means the PCB is adding the delay, which is not
true. The PHY is. What would normally happen is that the DT would
contain rgmii-id, indicating the PCB has no delays.
PHY_INTERFACE_MODE_RGMII_ID would be passed to the PHY driver, and it
would then reconfigure the PHY to insert both RX and TX delays. The
strapping is ignored.

At the moment, we don't have the ability to override the strapping. We
also cannot verify what the PHY is actually doing against what the MAC
would like it to do. So we can get into situations where it is wrong.

> For the broadcast test: initially, PHYCR1 (page 0xa43, reg 0x18) was
> 0x2118 (bit 13 set). Reading the PHY ID from both addr 0 and 1
> returned 0x7b744412. After clearing bit 13 on addr 1, addr 0 stopped
> responding (returned 0xffff), while addr 1 kept working. I didn't
> send any writes to addr 0.

Cool. Having the PHY respond on two addresses is bad. Linux can think
there are two PHYs. It can suspend and resume it twice etc. 

	Andrew