On Thu, Oct 31, 2024 at 10:06 AM Roger Quadros <rogerq@xxxxxxxxxx> wrote: > On 30/10/2024 17:08, Geert Uytterhoeven wrote: > > On Wed, Oct 30, 2024 at 1:58 PM Roger Quadros <rogerq@xxxxxxxxxx> 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@xxxxxxxxx Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx 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