linux-kernel - Re: [PATCH 2/2] arm64: dts: allwinner: h6: Add OrangePi 3 LTS DTS

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: <CAGb2v66dF8hMmjjJMnpVxM+092q=ZYZ+kT316roZuty6i+rcXQ@mail.gmail.com>
Date: Tue, 29 Apr 2025 23:52:52 +0800
From: Chen-Yu Tsai <wens@...e.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Jernej Škrabec <jernej.skrabec@...il.com>, 
	Andre Przywara <andre.przywara@....com>, robh@...nel.org, krzk+dt@...nel.org, 
	conor+dt@...nel.org, samuel@...lland.org, devicetree@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] arm64: dts: allwinner: h6: Add OrangePi 3 LTS DTS

On Tue, Apr 29, 2025 at 11:45 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > I just to be clear, I tested various combinations, including rgmii-id, and it
> > didn't work, except rgmii-rxid, which matches strapping. Of course Motorcomm
> > PHY driver took that into account and set registers accordingly.
>
> So we have:
>
> &emac {
>         pinctrl-names = "default";
>         pinctrl-0 = <&ext_rgmii_pins>;
>         phy-mode = "rgmii-rxid";
>         phy-handle = <&ext_rgmii_phy>;
>         phy-supply = <&reg_gmac_3v3>;
>         allwinner,rx-delay-ps = <0>;
>         allwinner,tx-delay-ps = <700>;
>         status = "okay";
> };
>
> and
>
> &mdio {
>         ext_rgmii_phy: ethernet-phy@1 {
>                 compatible = "ethernet-phy-ieee802.3-c22";
>                 reg = <1>;
>
>                 motorcomm,clk-out-frequency-hz = <125000000>;
>
>                 reset-gpios = <&pio 3 14 GPIO_ACTIVE_LOW>; /* PD14 */
>                 reset-assert-us = <15000>;
>                 reset-deassert-us = <100000>;
>         };
> };
>
> The RX path looks O.K. RGMII-RXID means the PHY should be adding the
> 2ns delay. The allwinner,rx-delay-ps = <0> should be redundant, that
> should be the driver default. And there are no properties in the PHY
> node about RX. All good.

The default action when the property is missing is to leave the hardware
settings alone. I admit this doesn't match the bindings.

> TX is the problem. The allwinner,tx-delay-ps = <700> causes the MAC to
> add 700ps delay, and 'rgmii-rxid' means the PHY should not add any
> delay. But 700ps is too low. It should be around 2000ps. So something
> else is adding a delay, or the 700ps is not really 700ps.

Anything is possible. As was raised in a previous reply, it's possible
instead of extending the delay range, the decreased the step size and
added more steps. The problem is we don't really know.

> You say the PHY is a YT8531C. These PHYs also accept
> rx-internal-delay-ps and tx-internal-delay-ps properties in their DT
> node.
>
> Try setting 'rgmii-id', allwinner,tx-delay-ps = <0>, and both
> rx-internal-delay-ps and tx-internal-delay-ps in the PHY node to 1950.
> If that does not work, try other values in the PHY node.

I don't get why we should ignore the strappings instead of using them
as reference or even truth. If the strappings worked correctly w/ the
generic PHY driver (that doesn't know how to configure the delay mode
on the PHY side), isn't it working as intended?


ChenYu