netdev - Re: [PATCH net v2] dt-bindings: net: ethernet-controller: Add informative text about RGMII delays

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <40fc8f3fec4da0ed2b59e8d2612345fb42b1fdd3.camel@icenowy.me>
Date: Fri, 13 Jun 2025 16:01:37 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Andrew Lunn <andrew@...n.ch>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, Rob Herring
 <robh@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
 <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Chaoyi Chen
 <chaoyi.chen@...k-chips.com>, Matthias Schiffer
 <matthias.schiffer@...tq-group.com>, Heiner Kallweit
 <hkallweit1@...il.com>,  netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v2] dt-bindings: net: ethernet-controller: Add
 informative text about RGMII delays

在 2025-06-11星期三的 17:28 +0200，Andrew Lunn写道：
> > Well in fact I have an additional question: when the MAC has any
> > extra
> > [tr]x-internal-delay-ps property, what's the threshold of MAC
> > triggering patching phy mode? (The property might be only used for
> > a
> > slight a few hundred ps delay for tweak instead of the full 2ns
> > one)
> 
> Maybe you should read the text.
> 
> The text says:
> 
>   In the MAC node, the Device Tree properties 'rx-internal-delay-ps'
>   and 'tx-internal-delay-ps' should be used to indicate fine tuning
>   performed by the MAC. The values expected here are small. A value
> of
>   2000ps, i.e 2ns, and a phy-mode of 'rgmii' will not be accepted by
>   Reviewers.
> 
> So a few hundred ps delay is fine. The MAC is not providing the 2ns
> delay, the PHY needs to do that, so you don't mask the value.

Thus if the MAC delay is set to 1xxx ps (e.g. 1800ps), should the MAC
do the masking?

What should be the threshold? 1ns?

> 
> > > > Well I can't find the reason of phy-mode being so designed
> > > > except
> > > > for
> > > > leaky abstraction from phylib.
> > > 
> > > I have no idea what that sentence means, sorry.
> > 
> > Well, I mean the existence of rgmii-* modes is coupled with the
> > internal of phylib, did I get it right?
> 
> This is the external API of phylib, it has nothing to do with the
> internals of phylib.
> 
> /**
>  * phy_attach - attach a network device to a particular PHY device
>  * @dev: network device to attach
>  * @bus_id: Bus ID of PHY device to attach
>  * @interface: PHY device's interface
>  *
>  * Description: Same as phy_attach_direct() except that a PHY bus_id
>  *     string is passed instead of a pointer to a struct phy_device.
>  */
> struct phy_device *phy_attach(struct net_device *dev, const char
> *bus_id,
>                               phy_interface_t interface)
> 
> interface tells the PHY how it should configure its interface.
> 
> If you follow the guidelines, the PHY adds the delay if needed, you
> get interface == phy-mode. However, interface and phy-mode are
> different things. phy-mode describes the hardware, the PCB. interface
> tells the PHY what to do. There are legitimate cases where
> interface != phy-mode.
> 
>         Andrew