netdev - Re: BeagleBone Black Ethernet PHY issues

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] [day] [month] [year] [list]

Message-ID: <CAMuHMdWfq4+gZcq6PzU=n0d2tTGEG3MV5c2tTQKLDysmj-g=kg@mail.gmail.com>
Date: Thu, 31 Oct 2024 10:30:52 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Roger Quadros <rogerq@...nel.org>
Cc: ext Tony Lindgren <tony@...mide.com>, Siddharth Vadapalli <s-vadapalli@...com>, 
	"open list:TI ETHERNET SWITCH DRIVER (CPSW)" <linux-omap@...r.kernel.org>, netdev <netdev@...r.kernel.org>, 
	Matti Vaittinen <mazziesaccount@...il.com>, Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: BeagleBone Black Ethernet PHY issues

On Thu, Oct 31, 2024 at 10:06 AM Roger Quadros <rogerq@...nel.org> wrote:
> On 30/10/2024 17:08, Geert Uytterhoeven wrote:
> > On Wed, Oct 30, 2024 at 1:58 PM Roger Quadros <rogerq@...nel.org> wrote:
> >> On 29/10/2024 19:18, Geert Uytterhoeven wrote:
> >>> During the last few months, booting kernels on BeagleBone Black
> >>> sometimes fails with:
> >>>
> >>>     +SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
> >>> LAN8710/LAN8720 failed with error -5
> >
> > [...]
> >
> >> Just wondering if the Reset is happening correctly and it has settled
> >> before PHY access.
> >>
> >> From arch/arm/boot/dts/ti/omap/am335x-bone-common.dtsi
> >>
> >> &davinci_mdio_sw {
> >>         pinctrl-names = "default", "sleep";
> >>         pinctrl-0 = <&davinci_mdio_default>;
> >>         pinctrl-1 = <&davinci_mdio_sleep>;
> >>
> >>         ethphy0: ethernet-phy@0 {
> >>                 reg = <0>;
> >>                 /* Support GPIO reset on revision C3 boards */
> >>                 reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
> >>                 reset-assert-us = <300>;
> >>                 reset-deassert-us = <13000>;
> >>         };
> >> };
> >>
> >> Do we need to increase reset-deassert-us for some reason?
> >
> > Thanks for the hint!
> >
> > This is indeed on Rev. C3 (my other boards are Rev. A5C or C, but
> > I don't test boot recent kernels on them, as they are in active use).
> >
> > Multiplying reset-deassert-us by 10 gives me a booting board.
> > More experiments reveal that I need a delay of 14 ms to boot
> > successfully, and 15 ms to avoid the early __mdiobus_read()
> > failure, too.
> >
> >> I couldn't find MII ready time after reset de-assert information form the
> >> PHY datasheet. except the following line [1].
> >> "For the first 16us after coming out of reset, the MII/RMII interface will run at 2.5 MHz. After this time, it will
> >> switch to 25 MHz if auto-negotiation is enabled"
> >>
> >> [1] 3.8.5 RESETS
> >> https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/LAN8710A-LAN8710Ai-Data-Sheet-DS00002164.pdf
> >
> > 3.8.5.1 Hardware Reset
> > "A Hardware reset is asserted by driving the nRST input pin low. When
> >  driven, nRST should be held low for the minimum time detailed in
> >  Section 5.6.3, "Power-On nRST & Configuration Strap Timing," on page
> >  60 to ensure a proper transceiver reset."
> >
> > 5.6.3 POWER-ON NRST & CONFIGURATION STRAP TIMING
> > "For proper operation, nRST must be asserted for no less than trstia."
> >
> > TABLE 5-8: POWER-ON NRST & CONFIGURATION STRAP TIMING VALUES
> > "trstia nRST input assertion time min. 100 µS"
> >
> > On Rev. C3, ETH_RESETn is controlled by an open-drain AND gate.
> > It is pulled high by a 10K resistor, and has a 4.7µF capacitor to
> > ground.  That gives an RC constant of 47ms.  As you need 0.7RC to charge
> > the capacitor above the threshold voltage of a CMOS input (VDD/2),
> > reset-deassert-us should be at least 33ms. Considering the typical
> > tolerance of 20% on capacitors, 40ms would be safer. Or perhaps
> > even 50ms?
>
> Super! Yes, I agree 50ms would be a good setting.

> > If you agree, I can send a patch.
> > Thanks!
>
> Much appreciated, thanks!

https://lore.kernel.org/9002a58daa1b2983f39815b748ee9d2f8dcc4829.1730366936.git.geert+renesas@glider.be

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