* [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY [not found] <CGME20191219102407epcas5p103b26e6fb191f7135d870a3449115c89@epcas5p1.samsung.com> @ 2019-12-19 10:17 ` Padmanabhan Rajanbabu 2019-12-21 5:29 ` David Miller 0 siblings, 1 reply; 11+ messages in thread From: Padmanabhan Rajanbabu @ 2019-12-19 10:17 UTC (permalink / raw) To: netdev, linux-stm32, linux-arm-kernel, linux-kernel Cc: Jose.Abreu, jayati.sahu, alexandre.torgue, rcsekar, pankaj.dubey, Sriram Dash, stable, Padmanabhan Rajanbabu, peppe.cavallaro, davem 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@samsung.com> Signed-off-by: Sriram Dash <sriram.dash@samsung.com> Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@samsung.com> --- drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c index bedaff0..cc8d7e7 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 = true; + bool mdio = false; static const struct of_device_id need_mdio_ids[] = { { .compatible = "snps,dwc-qos-ethernet-4.10" }, {}, -- 2.7.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY 2019-12-19 10:17 ` [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY Padmanabhan Rajanbabu @ 2019-12-21 5:29 ` David Miller 2020-01-05 20:43 ` Heiko Stübner 0 siblings, 1 reply; 11+ messages in thread From: David Miller @ 2019-12-21 5:29 UTC (permalink / raw) To: p.rajanbabu Cc: Jose.Abreu, jayati.sahu, alexandre.torgue, rcsekar, netdev, sriram.dash, linux-kernel, stable, pankaj.dubey, peppe.cavallaro, linux-stm32, linux-arm-kernel From: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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@samsung.com> > Signed-off-by: Sriram Dash <sriram.dash@samsung.com> > Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@samsung.com> Applied and queued up for -stable, thanks. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY 2019-12-21 5:29 ` David Miller @ 2020-01-05 20:43 ` Heiko Stübner 2020-01-05 22:22 ` Florian Fainelli 0 siblings, 1 reply; 11+ messages in thread From: Heiko Stübner @ 2020-01-05 20:43 UTC (permalink / raw) To: linux-arm-kernel, David Miller Cc: Jose.Abreu, jayati.sahu, alexandre.torgue, rcsekar, netdev, sriram.dash, linux-kernel, p.rajanbabu, stable, pankaj.dubey, peppe.cavallaro, linux-stm32 Hi, Am Samstag, 21. Dezember 2019, 06:29:18 CET schrieb David Miller: > From: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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@samsung.com> > > Signed-off-by: Sriram Dash <sriram.dash@samsung.com> > > Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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. 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? Thanks Heiko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY 2020-01-05 20:43 ` Heiko Stübner @ 2020-01-05 22:22 ` Florian Fainelli 2020-01-05 23:05 ` Heiko Stübner 0 siblings, 1 reply; 11+ messages in thread From: Florian Fainelli @ 2020-01-05 22:22 UTC (permalink / raw) To: Heiko Stübner, linux-arm-kernel, David Miller, sriram.dash, p.rajanbabu, pankaj.dubey Cc: Jose.Abreu, jayati.sahu, alexandre.torgue, rcsekar, netdev, linux-kernel, stable, peppe.cavallaro, linux-stm32 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@samsung.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@samsung.com> >>> Signed-off-by: Sriram Dash <sriram.dash@samsung.com> >>> Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY 2020-01-05 22:22 ` Florian Fainelli @ 2020-01-05 23:05 ` Heiko Stübner 2020-01-06 20:50 ` Florian Fainelli 2020-01-07 5:34 ` Sriram Dash 0 siblings, 2 replies; 11+ messages in thread From: Heiko Stübner @ 2020-01-05 23:05 UTC (permalink / raw) To: Florian Fainelli Cc: Jose.Abreu, jayati.sahu, alexandre.torgue, rcsekar, pankaj.dubey, sriram.dash, linux-kernel, p.rajanbabu, linux-stm32, stable, netdev, peppe.cavallaro, David Miller, linux-arm-kernel Hi Florian, Am Sonntag, 5. Januar 2020, 23:22:00 CET schrieb Florian Fainelli: > On 1/5/2020 12:43 PM, Heiko Stübner wrote: > > Am Samstag, 21. Dezember 2019, 06:29:18 CET schrieb David Miller: > >> From: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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@samsung.com> > >>> Signed-off-by: Sriram Dash <sriram.dash@samsung.com> > >>> Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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. I primarily noticed that on the px30-evb.dts and the internal board I'm working on right now. Both don't have that mdio bus node right now. > > 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 Works on both boards I had that were affected, so Tested-by: Heiko Stuebner <heiko@sntech.de> Thanks Heiko > > 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) { > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY 2020-01-05 23:05 ` Heiko Stübner @ 2020-01-06 20:50 ` Florian Fainelli 2020-01-07 5:34 ` Sriram Dash 1 sibling, 0 replies; 11+ messages in thread From: Florian Fainelli @ 2020-01-06 20:50 UTC (permalink / raw) To: Heiko Stübner Cc: Jose.Abreu, jayati.sahu, alexandre.torgue, rcsekar, pankaj.dubey, sriram.dash, linux-kernel, p.rajanbabu, linux-stm32, stable, netdev, peppe.cavallaro, David Miller, linux-arm-kernel On 1/5/20 3:05 PM, Heiko Stübner wrote: > Hi Florian, > > Am Sonntag, 5. Januar 2020, 23:22:00 CET schrieb Florian Fainelli: >> On 1/5/2020 12:43 PM, Heiko Stübner wrote: >>> Am Samstag, 21. Dezember 2019, 06:29:18 CET schrieb David Miller: >>>> From: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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@samsung.com> >>>>> Signed-off-by: Sriram Dash <sriram.dash@samsung.com> >>>>> Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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. > > I primarily noticed that on the px30-evb.dts and the internal board I'm > working on right now. Both don't have that mdio bus node right now. > > >>> 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 > > Works on both boards I had that were affected, so > Tested-by: Heiko Stuebner <heiko@sntech.de> Thanks Heiko, I am keen on submitting the revert of the affected commit, submit the second part where we actually ensure that the MDIO bus controller node is available as net-next material, so hopefully the guys at Samsung can test and response whether it fixes the problem they were initially after. -- Florian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY 2020-01-05 23:05 ` Heiko Stübner 2020-01-06 20:50 ` Florian Fainelli @ 2020-01-07 5:34 ` Sriram Dash 2020-01-07 13:15 ` [Linux-stm32] " Patrice CHOTARD 1 sibling, 1 reply; 11+ messages in thread From: Sriram Dash @ 2020-01-07 5:34 UTC (permalink / raw) To: 'Heiko Stübner', 'Florian Fainelli' Cc: Jose.Abreu, jayati.sahu, alexandre.torgue, rcsekar, pankaj.dubey, linux-kernel, p.rajanbabu, linux-stm32, stable, netdev, peppe.cavallaro, 'David Miller', linux-arm-kernel > From: Heiko Stübner <heiko@sntech.de> > Subject: Re: [PATCH] net: stmmac: platform: Fix MDIO init for platforms without > PHY > > Hi Florian, > > Am Sonntag, 5. Januar 2020, 23:22:00 CET schrieb Florian Fainelli: > > On 1/5/2020 12:43 PM, Heiko Stübner wrote: > > > Am Samstag, 21. Dezember 2019, 06:29:18 CET schrieb David Miller: > > >> From: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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@samsung.com> > > >>> Signed-off-by: Sriram Dash <sriram.dash@samsung.com> > > >>> Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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: > > Hi Florian, We have listed down the platforms which will break for as they don’t have the mdio / snps,dwmac-mdio node. Arm32 spear* , Arm32 ox820*, arm32 rv1108, arc abilis* , arc axs10x*, arc vdk_axs10x*, mips pistachio, arm64 rockchip/px30* There might be more platforms. > > 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. > > I primarily noticed that on the px30-evb.dts and the internal board I'm working > on right now. Both don't have that mdio bus node right now. > > > > > 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). ... snip ... > > > > > > > > > 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 > > Works on both boards I had that were affected, so > Tested-by: Heiko Stuebner <heiko@sntech.de> Nacked-by : Sriram Dash <Sriram.dash@samsung.com> > > > Thanks > Heiko > > > > > 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) { For the platforms which neither have mdio nor snps,dwmac-mdio property in dt, they will not enter the block. plat->mdio_node will always be false for them. Which, essentially, preserves the mdio variable Boolean value defined at the start of the function. > > - 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) { > > > > > There is a proposal for this problem solution. You can refer it at : https://lkml.org/lkml/2020/1/7/14 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Linux-stm32] [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY 2020-01-07 5:34 ` Sriram Dash @ 2020-01-07 13:15 ` Patrice CHOTARD 2020-01-07 13:28 ` Patrice CHOTARD 0 siblings, 1 reply; 11+ messages in thread From: Patrice CHOTARD @ 2020-01-07 13:15 UTC (permalink / raw) To: Sriram Dash, 'Heiko Stübner', 'Florian Fainelli', 'David Miller' Cc: Jose.Abreu, jayati.sahu, rcsekar, pankaj.dubey, linux-kernel, p.rajanbabu, stable, netdev, Peppe CAVALLARO, linux-stm32, linux-arm-kernel Hi All On 1/7/20 6:34 AM, Sriram Dash wrote: >> From: Heiko Stübner <heiko@sntech.de> >> Subject: Re: [PATCH] net: stmmac: platform: Fix MDIO init for platforms > without >> PHY >> >> Hi Florian, >> >> Am Sonntag, 5. Januar 2020, 23:22:00 CET schrieb Florian Fainelli: >>> On 1/5/2020 12:43 PM, Heiko Stübner wrote: >>>> Am Samstag, 21. Dezember 2019, 06:29:18 CET schrieb David Miller: >>>>> From: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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@samsung.com> >>>>>> Signed-off-by: Sriram Dash <sriram.dash@samsung.com> >>>>>> Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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: >>> > Hi Florian, > We have listed down the platforms which will break for as they don't have > the mdio / snps,dwmac-mdio node. > Arm32 spear* , Arm32 ox820*, arm32 rv1108, arc abilis* , arc axs10x*, arc > vdk_axs10x*, mips pistachio, arm64 rockchip/px30* There might be more > platforms. STiH410-B2260 is affected by this patch, i proposed a fix for this board : https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=224639 David, will you applied this DT series in your tree ? Thanks Patrice > >>> 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. >> I primarily noticed that on the px30-evb.dts and the internal board I'm > working >> on right now. Both don't have that mdio bus node right now. >> >> >>>> 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). > ... snip ... > >>>> >>>> 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 >> Works on both boards I had that were affected, so >> Tested-by: Heiko Stuebner <heiko@sntech.de> > Nacked-by : Sriram Dash <Sriram.dash@samsung.com> > >> >> Thanks >> Heiko >> >>> 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) { > For the platforms which neither have mdio nor snps,dwmac-mdio property in > dt, they will not enter the block. > plat->mdio_node will always be false for them. Which, essentially, preserves > the mdio variable Boolean value defined at the start of the function. > >>> - 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) { >>> >> >> > There is a proposal for this problem solution. You can refer it at : > https://lkml.org/lkml/2020/1/7/14 > > > > _______________________________________________ > Linux-stm32 mailing list > Linux-stm32@st-md-mailman.stormreply.com > https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Linux-stm32] [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY 2020-01-07 13:15 ` [Linux-stm32] " Patrice CHOTARD @ 2020-01-07 13:28 ` Patrice CHOTARD 2020-01-13 13:19 ` Leonidas P. Papadakos 0 siblings, 1 reply; 11+ messages in thread From: Patrice CHOTARD @ 2020-01-07 13:28 UTC (permalink / raw) To: Sriram Dash, 'Heiko Stübner', 'Florian Fainelli', 'David Miller' Cc: Jose.Abreu, jayati.sahu, rcsekar, pankaj.dubey, linux-kernel, p.rajanbabu, stable, netdev, Peppe CAVALLARO, linux-stm32, linux-arm-kernel On 1/7/20 2:15 PM, Patrice CHOTARD wrote: > Hi All > > On 1/7/20 6:34 AM, Sriram Dash wrote: >>> From: Heiko Stübner <heiko@sntech.de> >>> Subject: Re: [PATCH] net: stmmac: platform: Fix MDIO init for platforms >> without >>> PHY >>> >>> Hi Florian, >>> >>> Am Sonntag, 5. Januar 2020, 23:22:00 CET schrieb Florian Fainelli: >>>> On 1/5/2020 12:43 PM, Heiko Stübner wrote: >>>>> Am Samstag, 21. Dezember 2019, 06:29:18 CET schrieb David Miller: >>>>>> From: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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@samsung.com> >>>>>>> Signed-off-by: Sriram Dash <sriram.dash@samsung.com> >>>>>>> Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@samsung.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: >>>> >> Hi Florian, >> We have listed down the platforms which will break for as they don't have >> the mdio / snps,dwmac-mdio node. >> Arm32 spear* , Arm32 ox820*, arm32 rv1108, arc abilis* , arc axs10x*, arc >> vdk_axs10x*, mips pistachio, arm64 rockchip/px30* There might be more >> platforms. > STiH410-B2260 is affected by this patch, i proposed a fix for this board : > > https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=224639 > > David, will you applied this DT series in your tree ? I just noticed that a fix has been proposed[1] and fixes the issue on STiH410-B2260 without the DT series i just proposed above. So don't take care of my previous email. Thanks Patrice [1] https://lkml.org/lkml/2020/1/7/405 > > Thanks > > Patrice > > >>>> 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. >>> I primarily noticed that on the px30-evb.dts and the internal board I'm >> working >>> on right now. Both don't have that mdio bus node right now. >>> >>> >>>>> 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). >> ... snip ... >> >>>>> 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 >>> Works on both boards I had that were affected, so >>> Tested-by: Heiko Stuebner <heiko@sntech.de> >> Nacked-by : Sriram Dash <Sriram.dash@samsung.com> >> >>> Thanks >>> Heiko >>> >>>> 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) { >> For the platforms which neither have mdio nor snps,dwmac-mdio property in >> dt, they will not enter the block. >> plat->mdio_node will always be false for them. Which, essentially, preserves >> the mdio variable Boolean value defined at the start of the function. >> >>>> - 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) { >>>> >>> >> There is a proposal for this problem solution. You can refer it at : >> https://lkml.org/lkml/2020/1/7/14 >> >> >> >> _______________________________________________ >> Linux-stm32 mailing list >> Linux-stm32@st-md-mailman.stormreply.com >> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Linux-stm32] [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY 2020-01-07 13:28 ` Patrice CHOTARD @ 2020-01-13 13:19 ` Leonidas P. Papadakos 2020-01-13 13:21 ` Jose Abreu 0 siblings, 1 reply; 11+ messages in thread From: Leonidas P. Papadakos @ 2020-01-13 13:19 UTC (permalink / raw) To: patrice.chotard Cc: Jose.Abreu, jayati.sahu, f.fainelli, heiko, rcsekar, netdev, sriram.dash, linux-kernel, p.rajanbabu, linux-stm32, stable, pankaj.dubey, peppe.cavallaro, davem, linux-arm-kernel This change affects my Renegade board (rockchip/rk3328-roc-cc.dtb), (and probably the very similar Rock64) preventing me from using any kernel after 5.4.6 in a meaningful way. I get the stacktrace mentioned before at boot. Predictably, a command like 'ip address show' will hang since it probes networking but 'sudo' also freezes... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [Linux-stm32] [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY 2020-01-13 13:19 ` Leonidas P. Papadakos @ 2020-01-13 13:21 ` Jose Abreu 0 siblings, 0 replies; 11+ messages in thread From: Jose Abreu @ 2020-01-13 13:21 UTC (permalink / raw) To: Leonidas P. Papadakos, patrice.chotard Cc: jayati.sahu, f.fainelli, heiko, rcsekar, netdev, sriram.dash, linux-kernel, p.rajanbabu, linux-stm32, stable, pankaj.dubey, peppe.cavallaro, davem, linux-arm-kernel From: Leonidas P. Papadakos <papadakospan@gmail.com> Date: Jan/13/2020, 13:19:20 (UTC+00:00) > This change affects my Renegade board (rockchip/rk3328-roc-cc.dtb), > (and probably the very similar Rock64) preventing me from using any kernel after > 5.4.6 in a meaningful way. Fixed in: - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=da29f2d84bd10234df570b7f07cbd0166e738230 --- Thanks, Jose Miguel Abreu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-01-13 13:21 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CGME20191219102407epcas5p103b26e6fb191f7135d870a3449115c89@epcas5p1.samsung.com>
2019-12-19 10:17 ` [PATCH] net: stmmac: platform: Fix MDIO init for platforms without PHY Padmanabhan Rajanbabu
2019-12-21 5:29 ` David Miller
2020-01-05 20:43 ` Heiko Stübner
2020-01-05 22:22 ` Florian Fainelli
2020-01-05 23:05 ` Heiko Stübner
2020-01-06 20:50 ` Florian Fainelli
2020-01-07 5:34 ` Sriram Dash
2020-01-07 13:15 ` [Linux-stm32] " Patrice CHOTARD
2020-01-07 13:28 ` Patrice CHOTARD
2020-01-13 13:19 ` Leonidas P. Papadakos
2020-01-13 13:21 ` Jose Abreu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).