From: Siddharth Vadapalli <s-vadapalli@ti.com>
To: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Andy Whitcroft <apw@canonical.com>,
Dwaipayan Ray <dwaipayanray1@gmail.com>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Joe Perches <joe@perches.com>, Jonathan Corbet <corbet@lwn.net>,
Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>,
Siddharth Vadapalli <s-vadapalli@ti.com>,
Roger Quadros <rogerq@kernel.org>,
Tero Kristo <kristo@kernel.org>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
<devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <linux@ew.tq-group.com>
Subject: Re: [PATCH net-next 1/4] dt-bindings: net: ethernet-controller: update descriptions of RGMII modes
Date: Tue, 15 Apr 2025 16:06:31 +0530 [thread overview]
Message-ID: <6be3bdbe-e87e-4e83-9847-54e52984c645@ti.com> (raw)
In-Reply-To: <218a27ae2b2ef2db53fdb3573b58229659db65f9.1744710099.git.matthias.schiffer@ew.tq-group.com>
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 <matthias.schiffer@ew.tq-group.com>
> ---
> .../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.
next prev parent reply other threads:[~2025-04-15 10:36 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 10:18 [PATCH net-next 0/4] RGMII mode clarification + am65-cpsw fix Matthias Schiffer
2025-04-15 10:18 ` [PATCH net-next 1/4] dt-bindings: net: ethernet-controller: update descriptions of RGMII modes Matthias Schiffer
2025-04-15 10:36 ` Siddharth Vadapalli [this message]
2025-04-15 11:28 ` Matthias Schiffer
2025-04-15 11:55 ` Siddharth Vadapalli
2025-04-16 7:41 ` Matthias Schiffer
2025-04-22 8:56 ` Russell King (Oracle)
2025-04-22 14:40 ` Andrew Lunn
2025-04-22 8:41 ` Russell King (Oracle)
2025-04-18 20:40 ` Andrew Lunn
2025-04-22 8:37 ` Russell King (Oracle)
2025-04-15 10:54 ` Maxime Chevallier
2025-04-18 20:26 ` Andrew Lunn
2025-04-21 18:42 ` Rob Herring (Arm)
2025-04-21 19:20 ` Russell King (Oracle)
2025-04-22 15:00 ` Andrew Lunn
2025-04-22 15:31 ` Russell King (Oracle)
2025-04-28 11:29 ` Matthias Schiffer
2025-04-28 14:08 ` Andrew Lunn
2025-04-28 14:28 ` Siddharth Vadapalli
2025-04-28 14:45 ` Andrew Lunn
2025-04-29 7:24 ` Matthias Schiffer
2025-04-29 12:08 ` Andrew Lunn
2025-04-30 7:33 ` Matthias Schiffer
2025-04-15 10:18 ` [PATCH net-next 2/4] dt-bindings: net: ti: k3-am654-cpsw-nuss: update phy-mode in example Matthias Schiffer
2025-04-15 10:58 ` Maxime Chevallier
2025-04-18 20:48 ` Andrew Lunn
2025-04-21 18:44 ` Rob Herring (Arm)
2025-04-30 14:22 ` Roger Quadros
2025-05-07 9:51 ` Matthias Schiffer
2025-04-15 10:18 ` [PATCH net-next 3/4] net: ethernet: ti: am65-cpsw: fixup PHY mode for fixed RGMII TX delay Matthias Schiffer
2025-04-15 11:06 ` Maxime Chevallier
2025-04-18 20:50 ` Andrew Lunn
2025-04-30 14:56 ` Roger Quadros
2025-04-30 16:15 ` Andrew Lunn
2025-04-15 10:18 ` [PATCH net-next 4/4] checkpatch: check for comment explaining rgmii(|-rxid|-txid) PHY modes Matthias Schiffer
2025-04-15 11:15 ` Maxime Chevallier
2025-04-15 11:21 ` Matthias Schiffer
2025-04-15 12:46 ` Maxime Chevallier
2025-04-15 13:12 ` Andrew Lunn
2025-06-24 9:50 ` Matthias Schiffer
2025-04-15 13:20 ` Andrew Lunn
2025-04-15 13:36 ` Matthias Schiffer
2025-04-15 13:37 ` Matthias Schiffer
2025-04-17 10:28 ` Paolo Abeni
2025-04-15 16:11 ` Joe Perches
2025-04-16 7:48 ` Matthias Schiffer
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=6be3bdbe-e87e-4e83-9847-54e52984c645@ti.com \
--to=s-vadapalli@ti.com \
--cc=andrew+netdev@lunn.ch \
--cc=apw@canonical.com \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=dwaipayanray1@gmail.com \
--cc=edumazet@google.com \
--cc=joe@perches.com \
--cc=kristo@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@ew.tq-group.com \
--cc=lukas.bulwahn@gmail.com \
--cc=matthias.schiffer@ew.tq-group.com \
--cc=netdev@vger.kernel.org \
--cc=nm@ti.com \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=rogerq@kernel.org \
--cc=vigneshr@ti.com \
/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;
as well as URLs for NNTP newsgroup(s).