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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c25fbdb3-0e60-6e54-d58a-b05e8b805a58@gmail.com>
Date:   Sun, 5 Jan 2020 14:22:00 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Heiko Stübner <heiko@...ech.de>,
        linux-arm-kernel@...ts.infradead.org,
        David Miller <davem@...emloft.net>, sriram.dash@...sung.com,
        p.rajanbabu@...sung.com, pankaj.dubey@...sung.com
Cc:     Jose.Abreu@...opsys.com, jayati.sahu@...sung.com,
        alexandre.torgue@...com, rcsekar@...sung.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, peppe.cavallaro@...com,
        linux-stm32@...md-mailman.stormreply.com
Subject: Re: [PATCH] net: stmmac: platform: Fix MDIO init for platforms
 without PHY

Hi Heiko,

On 1/5/2020 12:43 PM, Heiko Stübner wrote:
> Hi,
> 
> Am Samstag, 21. Dezember 2019, 06:29:18 CET schrieb David Miller:
>> From: Padmanabhan Rajanbabu <p.rajanbabu@...sung.com>
>> Date: Thu, 19 Dec 2019 15:47:01 +0530
>>
>>> The current implementation of "stmmac_dt_phy" function initializes
>>> the MDIO platform bus data, even in the absence of PHY. This fix
>>> will skip MDIO initialization if there is no PHY present.
>>>
>>> Fixes: 7437127 ("net: stmmac: Convert to phylink and remove phylib logic")
>>> Acked-by: Jayati Sahu <jayati.sahu@...sung.com>
>>> Signed-off-by: Sriram Dash <sriram.dash@...sung.com>
>>> Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@...sung.com>
>>
>> Applied and queued up for -stable, thanks.
> 
> with this patch applied I now run into issues on multiple rockchip
> platforms using a gmac interface.

Do you have a list of DTS files that are affected by any chance? For the
32-bit platforms that I looked it, it seems like:

arch/arm/boot/dts/rk3228-evb.dts is OK because it has a MDIO bus node
arch/arm/boot/dts/rk3229-xms6.dts is also OK

arch/arm/boot/dts/rk3229-evb.dts is probably broken, there is no
phy-handle property or MDIO bus node, so it must be relying on
auto-scanning of the bus somehow that this patch broke.

And likewise for most 64-bit platforms except a1 and nanopi4.

> 
> When probing the driver and trying to establish a connection for a nfsroot
> it always runs into a null pointer in mdiobus_get_phy():
> 
> [   26.878839] rk_gmac-dwmac ff360000.ethernet: IRQ eth_wake_irq not found
> [   26.886322] rk_gmac-dwmac ff360000.ethernet: IRQ eth_lpi not found
> [   26.894505] rk_gmac-dwmac ff360000.ethernet: PTP uses main clock
> [   26.908209] rk_gmac-dwmac ff360000.ethernet: clock input or output? (output).
> [   26.916269] rk_gmac-dwmac ff360000.ethernet: Can not read property: tx_delay.
> [   26.924297] rk_gmac-dwmac ff360000.ethernet: set tx_delay to 0x30
> [   26.931150] rk_gmac-dwmac ff360000.ethernet: Can not read property: rx_delay.
> [   26.939166] rk_gmac-dwmac ff360000.ethernet: set rx_delay to 0x10
> [   26.946021] rk_gmac-dwmac ff360000.ethernet: integrated PHY? (no).
> [   26.953032] rk_gmac-dwmac ff360000.ethernet: cannot get clock clk_mac_refout
> [   26.966161] rk_gmac-dwmac ff360000.ethernet: init for RMII
> [   26.972633] rk_gmac-dwmac ff360000.ethernet: User ID: 0x10, Synopsys ID: 0x35
> [   26.980830] rk_gmac-dwmac ff360000.ethernet:         DWMAC1000
> [   26.986735] rk_gmac-dwmac ff360000.ethernet: DMA HW capability register supported
> [   26.995145] rk_gmac-dwmac ff360000.ethernet: RX Checksum Offload Engine supported
> [   27.003540] rk_gmac-dwmac ff360000.ethernet: COE Type 2
> [   27.009408] rk_gmac-dwmac ff360000.ethernet: TX Checksum insertion supported
> [   27.017320] rk_gmac-dwmac ff360000.ethernet: Wake-Up On Lan supported
> [   27.024577] rk_gmac-dwmac ff360000.ethernet: Normal descriptors
> [   27.031211] rk_gmac-dwmac ff360000.ethernet: Ring mode enabled
> [   27.037743] rk_gmac-dwmac ff360000.ethernet: Enable RX Mitigation via HW Watchdog Timer
> [   27.209823] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000398
>  2IP-Config: eth0 hardware address  66:e4:9b:b1:30:c3 mtu 1500 DHCP
> 7.219681] Mem abort info:
> [   27.229322]   ESR = 0x96000006
> [   27.229328]   EC = 0x25: DABT (current EL), IL = 32 bits
> [   27.229330]   SET = 0, FnV = 0
> [   27.229332]   EA = 0, S1PTW = 0
> [   27.229334] Data abort info:
> [   27.229336]   ISV = 0, ISS = 0x00000006
> [   27.229338]   CM = 0, WnR = 0
> [   27.229342] user pgtable: 4k pages, 48-bit VAs, pgdp=000000003e7d4000
> [   27.229345] [0000000000000398] pgd=0000000036739003, pud=0000000035894003, pmd=0000000000000000
> [   27.273398] Internal error: Oops: 96000006 [#1] SMP
> [   27.273403] Modules linked in: smsc95xx smsc75xx ax88179_178a asix usbnet panel_leadtek_ltk500hd1829 dwmac_rk stmmac_platform stmmac rockchipdrm phy_rockchip_inno_dsidphy analogix_dp dw_hdmi cec r
> c_core dw_mipi_dsi drm_kms_helper rtc_rk808 drm drm_panel_orientation_quirks
> [   27.305785] CPU: 3 PID: 1388 Comm: ipconfig Not tainted 5.5.0-rc4-00934-gd57e566e6874 #1463
> [   27.305790] Hardware name: Theobroma Systems Cobra with Leadtek Display (DT)
> [   27.323006] pstate: 40000005 (nZcv daif -PAN -UAO)
> [   27.323020] pc : mdiobus_get_phy+0x4/0x20
> [   27.332867] lr : stmmac_open+0x780/0xa78 [stmmac]
> [   27.332872] sp : ffff80001113b9a0
> [   27.341823] x29: ffff80001113b9a0 x28: 0000000000401003
> [   27.347761] x27: ffff00003d5cf200 x26: 0000000000000000
> [   27.353699] x25: 0000000000000001 x24: 0000000000000000
> [   27.359636] x23: 0000000000001002 x22: ffff800008b790a0
> [   27.365575] x21: ffff000035f84000 x20: 00000000ffffffff
> [   27.371513] x19: ffff000035f84800 x18: 0000000000000000
> [   27.377451] x17: 0000000000000000 x16: 0000000000000000
> [   27.383389] x15: 0000000000000000 x14: ffffffffffffffff
> [   27.389328] x13: 0000000000000020 x12: 0101010101010101
> [   27.395266] x11: 0000000000000003 x10: 0101010101010101
> [   27.401203] x9 : fffffffffffffffd x8 : 7f7f7f7f7f7f7f7f
> [   27.407143] x7 : fefefeff646c606d x6 : 1e091448e4e5f6e9
> [   27.413074] x5 : 697665644814091e x4 : 8080808000000000
> [   27.419013] x3 : 8343c96b232bb348 x2 : ffff00003d63f880
> [   27.424953] x1 : fffffffffffffff8 x0 : 0000000000000000
> [   27.430882] Call trace:
> [   27.433620]  mdiobus_get_phy+0x4/0x20
> [   27.437715]  __dev_open+0xe4/0x160
> [   27.441515]  __dev_change_flags+0x160/0x1b8
> [   27.446191]  dev_change_flags+0x20/0x60
> [   27.450478]  devinet_ioctl+0x66c/0x738
> [   27.454666]  inet_ioctl+0x2f4/0x360
> [   27.458565]  sock_do_ioctl+0x44/0x2b0
> [   27.462657]  sock_ioctl+0x1c8/0x508
> [   27.466556]  do_vfs_ioctl+0x604/0xbd0
> [   27.470646]  ksys_ioctl+0x78/0xa8
> [   27.474351]  __arm64_sys_ioctl+0x1c/0x28
> [   27.478737]  el0_svc_common.constprop.0+0x68/0x160
> [   27.484083]  el0_svc_handler+0x20/0x80
> [   27.488273]  el0_sync_handler+0x10c/0x180
> [   27.492753]  el0_sync+0x140/0x180
> [   27.496462] Code: 97ffffb0 a8c17bfd d65f03c0 8b21cc01 (f941d020)
> [   27.503275] ---[ end trace 6f6ca54e66af6d48 ]---
> 
> With the expected output being normally at this point:
> [   18.575321] rk_gmac-dwmac ff360000.ethernet eth0: PHY [stmmac-0:00] driver [RTL8201F Fast Ethernet]
> [   18.602975] rk_gmac-dwmac ff360000.ethernet eth0: No Safety Features support found
> [   18.611505] rk_gmac-dwmac ff360000.ethernet eth0: PTP not supported by HW
> [   18.619117] rk_gmac-dwmac ff360000.ethernet eth0: configuring for phy/rmii link mode
> [   22.719478] rk_gmac-dwmac ff360000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> 
> or
> 
> [   27.326984] rk_gmac-dwmac ff360000.ethernet eth0: PHY [stmmac-0:00] driver [Generic PHY]
> [   27.353543] rk_gmac-dwmac ff360000.ethernet eth0: No Safety Features support found
> [   27.362055] rk_gmac-dwmac ff360000.ethernet eth0: PTP not supported by HW
> [   27.369663] rk_gmac-dwmac ff360000.ethernet eth0: configuring for phy/rmii link mode
> [   29.406784] rk_gmac-dwmac ff360000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> 
> 
> This is torvalds git head and it was still working at -rc1 and all kernels
> before that. When I just revert this commit, things also start working
> again, so I guess something must be wrong here?

Yes, this was also identified to be problematic by the kernelci boot
farms on another platform, see [1].

[1]:
https://lore.kernel.org/linux-arm-kernel/5e0314da.1c69fb81.a7d63.29c1@mx.google.com/

Do you mind trying this patch and letting me know if it works for you.
Sriram, please also try it on your platforms and let me know if solves
the problem you were after. Thanks

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index cc8d7e7bf9ac..e192b8e0809e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -320,7 +320,7 @@ static int stmmac_mtl_setup(struct platform_device
*pdev,
 static int stmmac_dt_phy(struct plat_stmmacenet_data *plat,
                         struct device_node *np, struct device *dev)
 {
-       bool mdio = false;
+       bool mdio = true;
        static const struct of_device_id need_mdio_ids[] = {
                { .compatible = "snps,dwc-qos-ethernet-4.10" },
                {},
@@ -341,8 +341,9 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data
*plat,
        }

        if (plat->mdio_node) {
-               dev_dbg(dev, "Found MDIO subnode\n");
-               mdio = true;
+               mdio = of_device_is_available(plat->mdio_node);
+               dev_dbg(dev, "Found MDIO subnode, status: %sabled\n",
+                       mdio ? "en" : "dis");
        }

        if (mdio) {
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ