From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fllvem-ot03.ext.ti.com (fllvem-ot03.ext.ti.com [198.47.19.245]) (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 B27FE1CEAA3; Tue, 15 Apr 2025 10:36:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.47.19.245 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744713421; cv=none; b=XdBy9D4ahPnW4kAktUYee3b9SzSoXrgQaxN/Ru5799uyTAsJSWOr3G2V1sZWalcRICHetme0mQVw0QQiBO1xiEz5KJCqM9iDYILBAfMdlKqYDKBSrC9Iz1PSRktQQBDSJYOSFN+dGuX/m/ote7Zw09CzpGeAzVc27NSN+JY2zNk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744713421; c=relaxed/simple; bh=wx4mo1LEKkoBZxLsIQ9KT/z2lr/0ddIEgTR9LY19wIY=; h=Date:From:To:CC:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OPjRDmrTr7v35UqjJ9j3V8mK/e1zBA2jS1ITfS1fN2zg3+vlk5orN97KgRPfWXrSEs1r3GkNhnyYcu+G8rzwJPF2A57IbJ6zf+5ZOiU6huI/jz+KMQg/yRaTyaLY219oQjQYB9fKzHxGX7gVtw6Eo1FgC21N0ydfoLZx4qN0GJQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com; spf=pass smtp.mailfrom=ti.com; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b=ons7m0hO; arc=none smtp.client-ip=198.47.19.245 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ti.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="ons7m0hO" Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllvem-ot03.ext.ti.com (8.15.2/8.15.2) with ESMTPS id 53FAaXB32330796 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Apr 2025 05:36:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1744713394; bh=CM1FfPxfT6qnGQR4NUV0eAkHxH46NNtG6XNVqSWakkc=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ons7m0hOXmjdWeM8ngfIhGEh25WQ/OKmnzeqD8KBWTVxgFA6gcDtM3AkeT+k5TfFa rm40vZh6RA3UuZ2YVaFCkPVmtG3G+0Aeb6e2N9jqQB5EoK8DKCXkgwIiVc9v5dzOeQ zpxFFM6SC3gQk4ObqM05Q5ERQP1VlvidXZnpqbv8= Received: from DLEE113.ent.ti.com (dlee113.ent.ti.com [157.170.170.24]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 53FAaXrB008560 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 15 Apr 2025 05:36:33 -0500 Received: from DLEE107.ent.ti.com (157.170.170.37) by DLEE113.ent.ti.com (157.170.170.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Tue, 15 Apr 2025 05:36:33 -0500 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DLEE107.ent.ti.com (157.170.170.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Tue, 15 Apr 2025 05:36:33 -0500 Received: from localhost (uda0492258.dhcp.ti.com [10.24.72.113]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 53FAaWR6017032; Tue, 15 Apr 2025 05:36:32 -0500 Date: Tue, 15 Apr 2025 16:06:31 +0530 From: Siddharth Vadapalli To: Matthias Schiffer CC: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Andy Whitcroft , Dwaipayan Ray , Lukas Bulwahn , Joe Perches , Jonathan Corbet , Nishanth Menon , Vignesh Raghavendra , Siddharth Vadapalli , Roger Quadros , Tero Kristo , , , , , , Subject: Re: [PATCH net-next 1/4] dt-bindings: net: ethernet-controller: update descriptions of RGMII modes Message-ID: <6be3bdbe-e87e-4e83-9847-54e52984c645@ti.com> References: <218a27ae2b2ef2db53fdb3573b58229659db65f9.1744710099.git.matthias.schiffer@ew.tq-group.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <218a27ae2b2ef2db53fdb3573b58229659db65f9.1744710099.git.matthias.schiffer@ew.tq-group.com> X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea On Tue, Apr 15, 2025 at 12:18:01PM +0200, Matthias Schiffer wrote: > As discussed [1], the comments for the different rgmii(-*id) modes do not > accurately describe what these values mean. > > As the Device Tree is primarily supposed to describe the hardware and not > its configuration, the different modes need to distinguish board designs If the Ethernet-Controller (MAC) is integrated in an SoC (as is the case with CPSW Ethernet Switch), and, given that "phy-mode" is a property added within the device-tree node of the MAC, I fail to understand how the device-tree can continue "describing" hardware for different board designs using the same SoC (unchanged MAC HW). How do we handle situations where a given MAC supports various "phy-modes" in HW? Shouldn't "phy-modes" then be a "list" to technically descibe the HW? Even if we set aside the "rgmii" variants that this series is attempting to address, the CPSW MAC supports "sgmii", "qsgmii" and "usxgmii/xfi" as well. > (if a delay is built into the PCB using different trace lengths); whether > a delay is added on the MAC or the PHY side when needed should not matter. > > Unfortunately, implementation in MAC drivers is somewhat inconsistent > where a delay is fixed or configurable on the MAC side. As a first step > towards sorting this out, improve the documentation. > > Link: https://lore.kernel.org/lkml/d25b1447-c28b-4998-b238-92672434dc28@lunn.ch/ [1] > Signed-off-by: Matthias Schiffer > --- > .../bindings/net/ethernet-controller.yaml | 16 +++++++++------- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml > index 45819b2358002..2ddc1ce2439a6 100644 > --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml > +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml > @@ -74,19 +74,21 @@ properties: > - rev-rmii > - moca > > - # RX and TX delays are added by the MAC when required > + # RX and TX delays are part of the board design (through PCB traces). MAC > + # and PHY must not add delays. > - rgmii > > - # RGMII with internal RX and TX delays provided by the PHY, > - # the MAC should not add the RX or TX delays in this case > + # RGMII with internal RX and TX delays provided by the MAC or PHY. No > + # delays are included in the board design; this is the most common case > + # in modern designs. > - rgmii-id > > - # RGMII with internal RX delay provided by the PHY, the MAC > - # should not add an RX delay in this case > + # RGMII with internal RX delay provided by the MAC or PHY. TX delay is > + # part of the board design. > - rgmii-rxid > > - # RGMII with internal TX delay provided by the PHY, the MAC > - # should not add an TX delay in this case > + # RGMII with internal TX delay provided by the MAC or PHY. RX delay is > + # part of the board design. Since all of the above is documented in "ethernet-controller.yaml" and not "ethernet-phy.yaml", describing what the "MAC" should or shouldn't do seems accurate, and modifying it to describe what the "PHY" should or shouldn't do seems wrong. > - rgmii-txid > - rtbi > - smii Regards, Siddharth.