netdev - Re: [PATCH/RFC 1/5] dt-bindings: net: renesas,ravb: Document internal clock delay properties

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: <CAMuHMdWFA9YoeMgHGbhvW7Mqv6tBgcpqyYvWdNc1Vdn23KebLg@mail.gmail.com>
Date:   Sun, 21 Jun 2020 10:23:00 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Oleksij Rempel <linux@...pel-privat.de>
Cc:     Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Philippe Schenker <philippe.schenker@...adex.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Kazuya Mizuguchi <kazuya.mizuguchi.ks@...esas.com>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        netdev <netdev@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH/RFC 1/5] dt-bindings: net: renesas,ravb: Document internal
 clock delay properties

Hi Oleksij,

On Sat, Jun 20, 2020 at 7:47 AM Oleksij Rempel <linux@...pel-privat.de> wrote:
> Am 19.06.20 um 21:15 schrieb Geert Uytterhoeven:
> > Some EtherAVB variants support internal clock delay configuration, which
> > can add larger delays than the delays that are typically supported by
> > the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps"
> > properties).
> >
> > Add properties for configuring the internal MAC delays.
> > These properties are mandatory, even when specified as zero, to
> > distinguish between old and new DTBs.
> >
> > Update the example accordingly.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>

> > --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt

> > +                     This property is mandatory and valid only on R-Car Gen3
> > +                     and RZ/G2 SoCs.
> > +                     Valid values are 0 and 1800.
> > +                     A non-zero value is allowed only if phy-mode = "rgmii".
> > +                     Zero is not supported on R-Car D3.
> > +- renesas,txc-delay-ps: Internal TX clock delay.
> > +                     This property is mandatory and valid only on R-Car H3,
> > +                     M3-W, M3-W+, M3-N, V3M, and V3H, and RZ/G2M and RZ/G2N.
> > +                     Valid values are 0 and 2000.
>
> In the driver i didn't found sanity check for valid values.

As EtherAVB supports only zero and a single non-zero value, I didn't
bother validating the actual non-zero value in the driver.

However, I did implement full validation in the json-schema version of
the DT bindings, cfr. "[PATCH/RFC] dt-bindings: net: renesas,etheravb:
Convert to json-schema"
(https://lore.kernel.org/r/20200621081710.10245-1-geert+renesas@glider.be)
(In hindsight, I should not have postponed posting that patch)

> > @@ -105,8 +117,10 @@ Example:
> >                                 "ch24";
> >               clocks = <&cpg CPG_MOD 812>;
> >               power-domains = <&cpg>;
> > -             phy-mode = "rgmii-id";
> > +             phy-mode = "rgmii";
> >               phy-handle = <&phy0>;
> > +             renesas,rxc-delay-ps = <0>;
> > +             renesas,txc-delay-ps = <2000>;
> >
> >               pinctrl-0 = <&ether_pins>;
> >               pinctrl-names = "default";
> > @@ -115,18 +129,7 @@ Example:
> >               #size-cells = <0>;
> >
> >               phy0: ethernet-phy@0 {
> > -                     rxc-skew-ps = <900>;
> > -                     rxdv-skew-ps = <0>;
> > -                     rxd0-skew-ps = <0>;
> > -                     rxd1-skew-ps = <0>;
> > -                     rxd2-skew-ps = <0>;
> > -                     rxd3-skew-ps = <0>;
> > -                     txc-skew-ps = <900>;
> > -                     txen-skew-ps = <0>;
> > -                     txd0-skew-ps = <0>;
> > -                     txd1-skew-ps = <0>;
> > -                     txd2-skew-ps = <0>;
> > -                     txd3-skew-ps = <0>;
> > +                     rxc-skew-ps = <1500>;
>
>
> I'm curios, how this numbers ware taken?
> Old configurations was:
> TX delay:
> (txd*-skew-ps = 0) == -420ns
> (txc-skew-ps = 900) == 0ns
> resulting delays 0.420ns

Please ignore the actual contents of the old example.  It was based on a
very old DTS, which has received several fixes in the mean time.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds