From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 473F8C02181 for ; Wed, 22 Jan 2025 14:11:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=u6A2D9Gp6FOhIbSWgb9j5UrKEP+ZhUZ+HlhkvNqPm+8=; b=Gn115ybCcjq0P2IZBaCKxrAnYN i53K2RBGz4M5OeAkuKzY06KTSzozNNbS3sJgpb3Fw/Sx9wNtyQcVq0Ba+KTsPMnQefMUT8PmbRPRl s5WYgMNttQVVqjhc1XMdx6uGkiRKLNOHpPIL0fzu22YEp8p9Wxwk65RCJLc+oMlEPKL5204Sy40YC WYEc4l1Y2Jl8cbNjs21uEMXkywNnEQeygLidIRw/YG8iUsQBNk16SykosWBbQwYhaFRr0RLLR6CPz BmJ0oL/Eb3KyghcuytR1UOIvgdTWXcLbqY7eOxtbv+xv4M1BziJkwzmo8TS2J1hX1z8LYiwrNtVyB 2n9EJNrw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tabRr-0000000ANt9-2cx2; Wed, 22 Jan 2025 14:11:15 +0000 Received: from relay8-d.mail.gandi.net ([2001:4b98:dc4:8::228]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tabMe-0000000AMzG-2C0c for linux-arm-kernel@lists.infradead.org; Wed, 22 Jan 2025 14:05:54 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 9D40F1BF208; Wed, 22 Jan 2025 14:05:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1737554747; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=u6A2D9Gp6FOhIbSWgb9j5UrKEP+ZhUZ+HlhkvNqPm+8=; b=j45+Wj0bkZUjkfE2K7uxrujT3U0CBiljadFY9MriVnVTIHNFfsdFA5xnU5ptdu/wlydT4b n2vJbfLP+TmM0g0MR4H0vd5fJviqvSdbh8lgC+59TU/F7Kg9mInq2xT1/fXyc8Tympc6pG SC1r2wzqeAOGO3MYoRZWhHoz94AxeCf6w7Sg90jqLyrtUdnL1bBgjkNRgxmFFzVSP+iS14 gMCgNt+ynhl7pYBKfOnoTLNBgl1YBVjuodqnbWHX3XtTAebrVCkdoAeIJFUCtV2Rus55TL 9HF2d9LlA3ulb67ms7LaA+aWcA3fGjTx4RxCyixqFvkjd/WiVeMYS9QNDhjXUQ== Date: Wed, 22 Jan 2025 15:05:42 +0100 From: Maxime Chevallier To: Andrew Lunn Cc: Ninad Palsule , Jacky Chou , "andrew+netdev@lunn.ch" , "andrew@codeconstruct.com.au" , "conor+dt@kernel.org" , "davem@davemloft.net" , "devicetree@vger.kernel.org" , "eajames@linux.ibm.com" , "edumazet@google.com" , "joel@jms.id.au" , "krzk+dt@kernel.org" , "kuba@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-aspeed@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , "minyard@acm.org" , "netdev@vger.kernel.org" , "openipmi-developer@lists.sourceforge.net" , "pabeni@redhat.com" , "ratbert@faraday-tech.com" , "robh@kernel.org" Subject: Re: =?UTF-8?B?5Zue6KaGOiDlm57opoY6?= [PATCH v2 05/10] ARM: dts: aspeed: system1: Add RGMII support Message-ID: <20250122150542.55d483e6@fedora.home> In-Reply-To: References: <59116067-0caa-4666-b8dc-9b3125a37e6f@lunn.ch> <8042c67c-04d3-41c0-9e88-8ce99839f70b@lunn.ch> <9fbc6f4c-7263-4783-8d41-ac2abe27ba95@lunn.ch> <81567190-a683-4542-a530-0fb419f5f9be@linux.ibm.com> <0ee94fd3-d099-4d82-9ba8-eb1939450cc3@lunn.ch> <20250122140719.5629ae57@fedora.home> Organization: Bootlin X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-GND-Sasl: maxime.chevallier@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250122_060552_863698_D045131C X-CRM114-Status: GOOD ( 36.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > > Can we consider an update in the kernel doc along these lines : > > > > --- > > Documentation/networking/phy.rst | 19 +++++++++++-------- > > 1 file changed, 11 insertions(+), 8 deletions(-) > > > > diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst > > index f64641417c54..7ab77f9867a0 100644 > > --- a/Documentation/networking/phy.rst > > +++ b/Documentation/networking/phy.rst > > @@ -106,14 +106,17 @@ Whenever possible, use the PHY side RGMII delay for these reasons: > > configure correctly a specified delay enables more designs with similar delay > > requirements to be operated correctly > > > > -For cases where the PHY is not capable of providing this delay, but the > > -Ethernet MAC driver is capable of doing so, the correct phy_interface_t value > > -should be PHY_INTERFACE_MODE_RGMII, and the Ethernet MAC driver should be > > -configured correctly in order to provide the required transmit and/or receive > > -side delay from the perspective of the PHY device. Conversely, if the Ethernet > > -MAC driver looks at the phy_interface_t value, for any other mode but > > -PHY_INTERFACE_MODE_RGMII, it should make sure that the MAC-level delays are > > -disabled. > > +The MAC driver may add delays if the PCB doesn't include any. This can be > > +detected based on firmware "rx-internal-delay-ps" and "tx-internal-delay-ps" > > +properties. > > + > > +When the MAC driver can insert the delays, it should always do so when these > > +properties are present and non-zero, regardless of the RGMII mode specified. > > + > > +However, the MAC driver must adjust the PHY_INTERFACE_MODE_RGMII_* mode it passes > > +to the connected PHY device (through phy_attach or phylink_create() for example) > > +to account for MAC-side delay insertion, so that the the PHY device knows > > +if any delays still needs insertion on either TX or RX paths. > > You dropped: > > For cases where the PHY is not capable of providing this delay... > > This is something i would like to keep, to strengthen that we really > do want the PHY to add the delays. Many MACs are capable of adding > delays, but we don't want them to, the PHY should do it, so we have > consistency. > > The language i've tried to use is that "rx-internal-delay-ps" and > "tx-internal-delay-ps" can be used to fine tune the delays, so i'm > expecting their values to be small, because the PHY is adding the 2ns, > and the MAC is just adding/removing 0-200ps etc. I've also used the > same terminology for PHY drivers, the PHY DT properties for delays are > used for fine tuning, but the basic 2ns on/off comes from the phy-mode > passed to phylib. > > If it is just fine tuning, and not adding the full 2ns, it should just > pass phy-mode straight through. > > So your text becomes something like: > > The MAC driver may fine tune the delays. This can be configured > based on firmware "rx-internal-delay-ps" and "tx-internal-delay-ps" > properties. These values are expected to be small, not the full 2ns > delay. > > A MAC driver inserting these fine tuning delays should always do so > when these properties are present and non-zero, regardless of the > RGMII mode specified. > > Then we can address when the MAC adds the full 2ns. > > For cases where the PHY is not capable of providing the 2ns delay, > the MAC must provide it, if the phy-mode indicates the PCB is not > providing the delays. The MAC driver must adjust the > PHY_INTERFACE_MODE_RGMII_* mode it passes to the connected PHY > device (through phy_attach or phylink_create() for example) to > account for MAC-side delay insertion, so that the the PHY device > does not add additional delays. > > I also think we need something near the beginning like: > > The device tree property phy-mode describes the hardware. When used > with RGMII, its value indicates if the hardware, i.e. the PCB, > provides the 2ns delay required for RGMII. A phy-mode of 'rgmii' > indicates the PCB is adding the 2ns delay. For other values, the > MAC/PHY pair must insert the needed 2ns delay, with the strong > preference the PHY adds the delay. Thanks Andrew for the suggestions, your wording is definitely better than mine :) I'll queue that for when net-next re-opens. Maxime