Re: [PATCH v2 3/3] arm64: dts: rockchip: Add Luckfox Omni3576 Board support

[John Clark <inindev@gmail.com>]

On 5/4/25 8:45 PM, Andrew Lunn wrote:
>>> What PHY is it? Are you using the correct PHY driver for it, or
>>> genphy?
>>>
>> MAE0621A-Q3C
>> http://www.maxio-tech.com/product/12928/12929/12930/12931.html
> 
> Mainline does not have a PHY driver for this. So nothing is
> controlling the delays in the PHY. So what you have above works by
> luck, and is likely to break once there is a PHY driver. So i suggest
> you drop the Ethernet nodes for the moment.
> 
> There does appear to be a PHY driver here:
> 
> https://github.com/CoreELEC/linux-amlogic/blob/5.15.153_202501/drivers/net/phy/maxio.c
> 
> but it has a number of things wrong with it. You might want to search
> around and see if there are any cleaner versions around, or if anybody
> is working on upstreaming a driver for this PHY.
> 
> 	Andrew
 >

Hi Andrew,
Thank you for your valuable feedback and for pointing me toward 
investigating the PHY configuration further. After digging deeper into 
the MAE0621A-Q3C PHY (PHY ID 0x7b744412), I now understand why it 
performs reliably: the generic PHY driver relies on the GMAC to set 
RGMII delays (tx_delay=0x20, rx_delay=0x10), enabling a stable 1Gbps 
link for gmac0 in rgmii-rxid mode, while rgmii-id failed in my tests due 
to the driver’s lack of internal delay configuration. Given the critical 
role of networking for development, I’d like to retain the GMAC nodes in 
v3 using this setup, but I’d greatly appreciate your approval on whether 
the generic PHY driver is suitable in rgmii-rxid mode for now. I’m eager 
to explore a Maxio-specific driver for mainline compatibility and would 
be grateful for any guidance on existing upstreaming efforts for this PHY.

Best regards,
John