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: <1f927944-30aa-4298-9bd0-d9d3ace3fc78@kernel.org>
Date: Wed, 30 Oct 2024 14:58:20 +0200
From: Roger Quadros <rogerq@...nel.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>,
 ext Tony Lindgren <tony@...mide.com>,
 Siddharth Vadapalli <s-vadapalli@...com>
Cc: "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

Hi Geert,

On 29/10/2024 19:18, Geert Uytterhoeven wrote:
> Hi all,
> 
> 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
>      davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00,
> driver SMSC LAN8710/LAN8720
>      soc_device_match(cpsw_soc_devices): no match
>      cpsw-switch 4a100000.switch: initialized cpsw ale version 1.4
>      ...
>      am335x-phy-driver 47401300.usb-phy: dummy supplies not allowed
> for exclusive requests (id=vbus)
>     +cpsw-125mhz-clkctrl:0014:0: failed to disable
>      am335x-phy-driver 47401b00.usb-phy: using DT
> '/ocp/target-module@...00000/usb-phy@...0' for 'reset' GPIO lookup
>      ...
>      cpsw-switch 4a100000.switch: starting ndev. mode: dual_mac
>     -SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver
> (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)
>     -cpsw-switch 4a100000.switch eth0: Link is Up - 100Mbps/Full -
> flow control off
>     -Sending DHCP requests ., OK
>     -IP-Config: Complete:
>     -[...]
>     +cpsw-switch 4a100000.switch: phy
> "/ocp/interconnect@...00000/segment@...arget-module@...000/switch@...dio@...0/ethernet-phy@0"
> not found on slave 0
>     +[HANG]
> 
> Adding debug prints to smsc_phy_probe() makes the issue go away, so it
> must be timing related.
> 
> Adding specific debug prints in the failure case gives:
> 
>     SMSC LAN8710/LAN8720 4a101000.mdio:00: genphy_read_abilities:2859:
> phy_read(MII_BMSR) failed -EIO
>     SMSC LAN8710/LAN8720 4a101000.mdio:00: phy_probe:3613:
> genphy_read_abilities() failed -EIO
>     SMSC LAN8710/LAN8720 4a101000.mdio:00: probe with driver SMSC
> LAN8710/LAN8720 failed with error -5
> 
> and later:
> 
>     Generic PHY 4a101000.mdio:00: genphy_read_abilities:2859:
> phy_read(MII_BMSR) failed -EIO
>     Generic PHY 4a101000.mdio:00: phy_probe:3609:
> genphy_read_abilities failed -EIO
>     cpsw-switch 4a100000.switch: phy
> "/ocp/interconnect@...00000/segment@...arget-module@...000/switch@...dio@...0/ethernet-phy@0"
> not found on slave 0
> 
> Adding debug prints to __mdiobus_read() and davinci_mdio_read() gives:
> 
>     mdio_bus 4a101000.mdio: davinci_mdio_read:444:
> readl(&data->regs->user[0].access) = 0x3a0ffff
>     mdio_bus 4a101000.mdio: __mdiobus_read:900: davinci_mdio_read failed -EIO
> 
> but this is a different (and unimportant?) early failure from
> smsc_phy_config_intr(), and that debug print actually makes the issue go
> away, too.
> 
> Ignoring the early failure reveals that phy_read(MII_BMSR) failed due
> to:
> 
>     mdio_bus 4a101000.mdio: davinci_mdio_read:446:
> readl(&data->regs->user[0].access) = 0x20ffff
> 
> Anyone with a clue?

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?

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
 
> Thanks!
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

-- 
cheers,
-roger

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ