linux-kernel - Re: DP83867 ethernet PHY regression

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: <ZG8PS/CSpHXIA6wt@francesco-nb.int.toradex.com>
Date:   Thu, 25 May 2023 09:33:31 +0200
From:   Francesco Dolcini <francesco@...cini.it>
To:     Johannes Pointner <h4nn35.work@...il.com>
Cc:     Francesco Dolcini <francesco@...cini.it>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Praneeth Bajjuri <praneeth@...com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Grygorii Strashko <grygorii.strashko@...com>,
        Dan Murphy <dmurphy@...com>
Subject: Re: DP83867 ethernet PHY regression

Hello Johannes,

On Thu, May 25, 2023 at 08:31:00AM +0200, Johannes Pointner wrote:
> On Wed, May 24, 2023 at 3:22 PM Bagas Sanjaya <bagasdotme@...il.com> wrote:
> >
> > On Mon, May 22, 2023 at 04:58:46PM +0200, Francesco Dolcini wrote:
> > > Hello all,
> > > commit da9ef50f545f ("net: phy: dp83867: perform soft reset and retain
> > > established link") introduces a regression on my TI AM62 based board.
> > >
> > > I have a working DTS with Linux TI 5.10 downstream kernel branch, while
> > > testing the DTS with v6.4-rc in preparation of sending it to the mailing
> > > list I noticed that ethernet is working only on a cold poweron.
> > >
> > > With da9ef50f545f reverted it always works.
> > >
> > > Here the DTS snippet for reference:
> > >
> > > &cpsw_port1 {
> > >       phy-handle = <&cpsw3g_phy0>;
> > >       phy-mode = "rgmii-rxid";
> > > };
> > >
> > > &cpsw3g_mdio {
> > >       assigned-clocks = <&k3_clks 157 20>;
> > >       assigned-clock-parents = <&k3_clks 157 22>;
> > >       assigned-clock-rates = <25000000>;
> > >
> > >       cpsw3g_phy0: ethernet-phy@0 {
> > >               compatible = "ethernet-phy-id2000.a231";
> > >               reg = <0>;
> > >               interrupt-parent = <&main_gpio0>;
> > >               interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> > >               reset-gpios = <&main_gpio0 17 GPIO_ACTIVE_LOW>;
> > >               reset-assert-us = <10>;
> > >               reset-deassert-us = <1000>;
> > >               ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
> > >               ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> > >       };
> > > };
> > >
> >
> > Thanks for the regression report. I'm adding it to regzbot:
> >
> > #regzbot ^introduced: da9ef50f545f86
> > #regzbot title: TI AM62 DTS regression due to dp83867 soft reset
> 
> Hello Francesco,
> 
> I had a similar issue with a patch like this, but in my case it was the DP83822.
> https://lore.kernel.org/netdev/CAHvQdo2yzJC89K74c_CZFjPydDQ5i22w36XPR5tKVv_W8a2vcg@mail.gmail.com/
> I also raised the question for the commit da9ef50f545f.
> https://lore.kernel.org/lkml/CAHvQdo1U_L=pETmTJXjdzO+k7vNTxMyujn99Y3Ot9xAyQu=atQ@mail.gmail.com/
> 
> The problem was/is for me that the phy gets the clock from the CPU and
> the phy is already initialized in the u-boot.
> During the Linux kernel boot up there is a short amount of time where
> no clock is delivered to the phy.
> The phy didn't like this and was most of the time not usable anymore.
> The only thing that brought the phy/link back was resetting the phy
> using the phytool.

I had a look and it seems that is a different issue here, but I cannot
exclude that this is related.

First the link up/down, negotiation and mdio and related communication
is perfectly fine, what it looks like is not working is that no data is
flowing over RGMII.

Second, also in our case the clock is coming from the SoC, however this
clock is enabled way earlier in the boot, and at that time the phy is
even in reset.

 phy reset asserted
 . SPL on TI AM62 R5
   . enable clock
 . SPL on TI AM62 A
 . U-Boot proper on TI AM62 A
   .release phy reset

The phy reset is also configured in the DTS and used by the Linux driver.

In addition to that, as I already clarified in my second email, the
issue is happening also on a cold poweron. It happens most of the time,
but not always.

Francesco