From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C077B2BF015 for ; Fri, 12 Dec 2025 23:50:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.67.36.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765583417; cv=none; b=P7SOOytkjTbExOD4wRoy38f0G3Bf9XDqNgJpPV8F3zx1+k91HmrQexRcokfrT/Z2jFcRdJTx6jKaQdRMFqLkXEChamoSUiALSpm0NTBFzE7xlWXpLuuu9Ao4JhsA4RKMv0uL3HZ7TJYiU0nACYFm1zaw/qfW7qNVpEpXVIeNM0c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765583417; c=relaxed/simple; bh=x45WV6B65y1LYkFFpwm5z3sjTt12/+FjgRk48u8KC4g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=t4R9LUcNJ+qOIzIaCcdjFnp+0CIaTfpOvnHoFQk+KFyxYaSdKEqGY3FBu30Z1XD2gf54OpipzcHVGuux4t5vhXiBfSO0/lhZpd7cpe1Kq3BW88MopL/E7BqwPPZuoaNeMGosUO237zuuM5n61aAHXVMZXzNkecAX8UYFy6WHV9s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=posteo.de; spf=pass smtp.mailfrom=posteo.de; dkim=pass (2048-bit key) header.d=posteo.de header.i=@posteo.de header.b=nZPdF2MW; arc=none smtp.client-ip=185.67.36.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=posteo.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=posteo.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=posteo.de header.i=@posteo.de header.b="nZPdF2MW" Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E7767240027 for ; Sat, 13 Dec 2025 00:50:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.de; s=2017; t=1765583413; bh=DhnIQJhYt6frMQDEzUl2UnGpUcZg2IdR59Af7tBLeXk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=nZPdF2MW6m9IOYyXzZtUd1r1ywjf1ar6h/Nu9iLH5p59ZV1kbnl+MCxCfolgg4V+c Ri9ZgYds/qMSG5/FdZzclRlpmwDCzQ1xwZOSICj9ijbJuSqJTrIM5rmSbz+Ffx3hZm 4k0sounVbQms84237dOVjJ5ATDv09wnsNSl7uwLFHu/WuFNpwjAbOu+hdz+UIWDBXl xwRAT8OByefuUaubsgl/b6CqGVnJ9sE1zrL+JcE9x2RWRFv8iyO7GjAR46XX3RBCPx Lyek3tNctnSBtKOV6Brs2ZBLm8SuP9jCy9Iun6uyK7iy1Ws+CWinefw878SFocQ0V0 S3Nfsw7Buw4BQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4dSmR85RRtz9rxD; Sat, 13 Dec 2025 00:50:12 +0100 (CET) From: Adrian Kossmann To: andrew@lunn.ch Cc: adrian.kossmann@posteo.de, conor+dt@kernel.org, devicetree@vger.kernel.org, heiko@sntech.de, krzk+dt@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, robh@kernel.org Subject: Re: [PATCH v2] arm64: dts: rockchip: Adjust RGMII TXD/RXD delays for the Rock Pi E Date: Fri, 12 Dec 2025 23:50:13 +0000 Message-ID: <20251212234957.591812-1-adrian.kossmann@posteo.de> In-Reply-To: <57e99fa1-0e59-4129-bcae-b94df46447e7@lunn.ch> References: <57e99fa1-0e59-4129-bcae-b94df46447e7@lunn.ch> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Andrew, > rgmii means the PCB provides the delay. I doubt that is the > case. Yes, however, to my understanding, there are two kinds of delays that influence RGMII timing: Delays that are added onto the clock signal (TXC/RXC) and delays added to the data signal (TXD/RXD) by the GMAC. The link provided by you describes delays that are either introduced by longer clock traces on the PCB (rgmii phy-mode) or by programmable clock delays (rgmii-id phy-mode). Delays for TXD timing and RXD timing are described in [1] and are implemented by the Rockchip Ethernet driver which is bound to node gmac2io according to [2]. The example DT binding in [1] as well as other mainline DTS of devices that use the RK3328 seem to adjust RGMII timing via TXD and RXD delays and setting phy-mode to rgmii, despite having programmable TXC/RXC delays, at least according to the technical manual of the RK3328. So, in this case this may be an exception from the usual convention that any RGMII phy mode other than 'rgmii-id' is probably wrong. Of course, I may have overlooked something or misunderstood, and I would appreciate further guidance in this case. [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/net/rockchip-dwmac.txt [2] https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/tree/arch/arm64/boot/dts/rockchip/rk3328.dtsi#n982 Adrian