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]
Date:   Wed, 28 Jul 2021 14:29:50 -0400
From:   Peter Geis <pgwipeout@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Michael Riesch <michael.riesch@...fvision.net>,
        devicetree@...r.kernel.org,
        arm-mail-list <linux-arm-kernel@...ts.infradead.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Heiko Stuebner <heiko@...ech.de>,
        Liang Chen <cl@...k-chips.com>, Simon Xue <xxm@...k-chips.com>
Subject: Re: [PATCH 2/2] arm64: dts: rockchip: rk3568-evb1-v10: add ethernet support

On Wed, Jul 28, 2021 at 1:55 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> On Wed, Jul 28, 2021 at 06:10:20PM +0200, Michael Riesch wrote:
> > +&gmac0 {
> > +     phy-mode = "rgmii";
>
> ...
> > +
> > +     tx_delay = <0x3c>;
> > +     rx_delay = <0x2f>;
>
> Hi Michael
>
> In general, we try to have the PHY introduce the RGMII delays, not the
> MAC. Did you try
>
> phy-mode = "rgmii-id";
>
> and remove these delay values? It is hard for me to say if that will
> work because i've no idea what 0x3c and 0x2f means? Are they
> equivalent to 2ns?

Unfortunately the driver and TRM are both rather non-specific as to
how this works.
The driver sets the tx_delay to 0x30 and rx_delay to 0x10 if these
values are not defined, or sets them both to 0 in case of rgmii_id.

Generally all rockchip boards use this value instead of the rgmii_id,
I imagine because it's more consistent to tune here than the hit or
miss support of the phy drivers.
The usual course of action is to test to find the lowest and highest
working values and take the median value to plug in here.

>
>      Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ