[PATCH v2 3/3] arm64: dts: rockchip: Add Luckfox Omni3576 Board support
John Clark
inindev at gmail.com
Mon May 5 03:36:16 PDT 2025
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
More information about the linux-arm-kernel
mailing list