From: Andrew Lunn <andrew@lunn.ch>
To: John Clark <inindev@gmail.com>
Cc: Jonas Karlman <jonas@kwiboo.se>,
heiko@sntech.de, robh@kernel.org, conor+dt@kernel.org,
detlev.casanova@collabora.com, linux-kernel@vger.kernel.org,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
krzk+dt@kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/3] arm64: dts: rockchip: Add Luckfox Omni3576 Board support
Date: Mon, 5 May 2025 14:38:51 +0200 [thread overview]
Message-ID: <bf734f63-d849-433b-abcb-37af8fd704e9@lunn.ch> (raw)
In-Reply-To: <1a403393-e317-4a1b-a151-fa668c6278f9@gmail.com>
> 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.
Device Tree describes the hardware. The hardware does not appear to
have the 2ns delay added by extra long clock lines, so your DT
description of the hardware using 'rgmii-rxid' is wrong.
If we where to accept this broken description now, it really will
break when the MAE0621A driver is merged and it correctly sets the
RGMII delays.
So sorry, no we cannot accept it.
For you own development work, you can merge the driver i pointed to
into your tree. It needs work, but it is not terrible. So it should
work for you.
> 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.
This is the first time i've heard of this device, so i have no idea if
anybody else is working on it. I would suggest you reach out to the
author of that patch.
Andrew
next prev parent reply other threads:[~2025-05-05 12:38 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-02 20:55 [PATCH v1 0/3] Add Luckfox Omni3576 Carrier Board support for RK3576 John Clark
2025-05-02 20:55 ` [PATCH v1 1/3] dt-bindings: vendor-prefixes: Add luckfox prefix John Clark
2025-05-02 20:55 ` [PATCH v1 2/3] dt-bindings: arm: rockchip: Add Luckfox Omni3576 board John Clark
2025-05-02 20:55 ` [PATCH v1 3/3] arm64: dts: rockchip: Add Luckfox Omni3576 Carrier Board with Core3576 Module John Clark
2025-05-02 21:51 ` Andrew Lunn
2025-05-03 23:39 ` [PATCH v1 0/3] Add Luckfox Omni3576 Carrier Board support for RK3576 Nicolas Frattaroli
2025-05-04 8:08 ` Heiko Stübner
2025-05-04 10:24 ` [PATCH v2 " John Clark
2025-05-04 10:24 ` [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add luckfox prefix John Clark
2025-05-04 17:53 ` Krzysztof Kozlowski
2025-05-04 10:24 ` [PATCH v2 2/3] dt-bindings: arm: rockchip: Add Luckfox Omni3576 board John Clark
2025-05-04 17:54 ` Krzysztof Kozlowski
2025-05-04 10:24 ` [PATCH v2 3/3] arm64: dts: rockchip: Add Luckfox Omni3576 Board support John Clark
2025-05-04 13:26 ` Jonas Karlman
2025-05-04 14:12 ` Andrew Lunn
2025-05-04 21:02 ` John Clark
2025-05-04 23:01 ` Andrew Lunn
2025-05-04 23:06 ` John Clark
2025-05-04 23:41 ` John Clark
2025-05-05 0:45 ` Andrew Lunn
2025-05-05 0:52 ` John Clark
2025-05-05 13:22 ` Diederik de Haas
2025-05-05 14:01 ` Andrew Lunn
2025-05-05 10:36 ` John Clark
2025-05-05 12:38 ` Andrew Lunn [this message]
2025-05-05 12:14 ` Jonas Karlman
2025-05-05 14:44 ` [PATCH v2 0/3] Add Luckfox Omni3576 Carrier Board support for RK3576 Rob Herring (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bf734f63-d849-433b-abcb-37af8fd704e9@lunn.ch \
--to=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=detlev.casanova@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=inindev@gmail.com \
--cc=jonas@kwiboo.se \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®