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: <cd120c6b-e469-46d9-95b5-71a8cc6513cf@kernel.org>
Date: Thu, 31 Oct 2024 11:06:50 +0200
From: Roger Quadros <rogerq@...nel.org>
To: Geert Uytterhoeven <geert@...ux-m68k.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 30/10/2024 17:08, Geert Uytterhoeven wrote:
> Hi Roger,
> 
> 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!

-- 
cheers,
-roger

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ