linux-kernel - Re: [PATCH v3 1/2] dt-bindings: net: Add ICSSG Ethernet Driver bindings

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: <Y7cFUW6dFRaI+nPV@lunn.ch>
Date:   Thu, 5 Jan 2023 18:13:53 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Roger Quadros <rogerq@...nel.org>
Cc:     Md Danish Anwar <danishanwar@...com>,
        "Andrew F. Davis" <afd@...com>, Tero Kristo <t-kristo@...com>,
        Suman Anna <s-anna@...com>, YueHaibing <yuehaibing@...wei.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        "David S. Miller" <davem@...emloft.net>, nm@...com,
        ssantosh@...nel.org, srk@...com, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, netdev@...r.kernel.org,
        linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 1/2] dt-bindings: net: Add ICSSG Ethernet Driver
 bindings

> >> On 23/12/2022 16:28, Andrew Lunn wrote:
> >>>> +        ethernet-ports {
> >>>> +            #address-cells = <1>;
> >>>> +            #size-cells = <0>;
> >>>> +            pruss2_emac0: port@0 {
> >>>> +                reg = <0>;
> >>>> +                phy-handle = <&pruss2_eth0_phy>;
> >>>> +                phy-mode = "rgmii-rxid";
> >>>
> >>> That is unusual. Where are the TX delays coming from?
> >>
> >> >From the below property
> >>
> >> +                ti,syscon-rgmii-delay = <&scm_conf 0x4120>;
> >>
> >> The TX delay can be enabled/disabled from within the ICSSG block.
> >>
> >> If this property exists and PHY mode is neither PHY_INTERFACE_MODE_RGMII_ID
> >> nor PHY_INTERFACE_MODE_RGMII_TXID then the internal delay is enabled.
> >>
> >> This logic is in prueth_config_rgmiidelay() function in the introduced driver.
> > 
> > What nearly every other MAC driver does is pass the phy-mode to the
> > PHY and lets the PHY add the delays. I would recommend you do that,
> > rather than be special and different.
> 
> 
> If I remember right we couldn't disable MAC TX delay on some earlier silicon
> so had to take this route. I don't remember why we couldn't disable it though.
> 
> In more recent Silicon Manuals I do see that MAC TX delay can be enabled/disabled.
> If this really is the case then we should change to
> 
>  phy-mode = "rgmii-id";
> 
> And let PHY handle the TX+RX delays.

DT describes the board. PHY mode indicates what delays the board
requires, because the board itself is not performing the delays by
using extra long lines. So typically, phy-mode is rgmii-id, indicating
delays need to be added somewhere in both directions.

Who adds the delays is then between the MAC and the PHY. In most
cases, the MAC does nothing, and passes phy-mode to the PHY and the
PHY does it.

But it is also possible for the MAC to do the delay. So if you cannot
actually disable the TX delay in the MAC, that is O.K. But you need to
modify phy-mode you pass to the PHY to indicate the MAC is doing the
delay, otherwise the PHY will additionally do the delay. So your DT
will contain rgmii-id, because that is what the board requires, but
the MAC will pass rmgii-rxid to the PHY, since that is what the PHY
needs to add.

	Andrew