* RE: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 [not found] ` <5e0314da.1c69fb81.a7d63.29c1@mx.google.com> @ 2020-01-03 13:30 ` Sriram Dash 2020-01-03 17:46 ` Florian Fainelli 0 siblings, 1 reply; 6+ messages in thread From: Sriram Dash @ 2020-01-03 13:30 UTC (permalink / raw) To: 'kernelci.org bot', tomeu.vizoso, khilman, 'David S. Miller', mgalka, guillaume.tucker, broonie, 'Jayati Sahu', 'Padmanabhan Rajanbabu', enric.balletbo, narmstrong Cc: linux-arm-kernel, netdev, 'David S. Miller', 'Maxime Coquelin', linux-kernel, linux-stm32, 'Jose Abreu', 'Giuseppe Cavallaro', 'Alexandre Torgue', pankaj.dubey, rcsekar > From: kernelci.org bot <bot@kernelci.org> > Subject: broonie-regmap/for-next bisection: boot on ox820-cloudengines- > pogoplug-series-3 > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * This automated bisection report was sent to you on the basis * > * that you may be involved with the breaking commit it has * > * found. No manual investigation has been done to verify it, * > * and the root cause of the problem may be somewhere else. * > * * > * If you do send a fix, please include this trailer: * > * Reported-by: "kernelci.org bot" <bot@kernelci.org> * > * * > * Hope this helps! * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug- > series-3 > > Summary: > Start: 46cf053efec6 Linux 5.5-rc3 > Details: https://protect2.fireeye.com/url?k=36fb52ed-6b2b5a21-36fad9a2- > 000babff3793- > f64e7c227e0a8b34&u=https://kernelci.org/boot/id/5e02ce65451524462f9731 > 4f > Plain log: https://protect2.fireeye.com/url?k=58f5fc3b-0525f4f7-58f47774- > 000babff3793-f96a18481add0d7f&u=https://storage.kernelci.org//broonie- > regmap/for-next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab- > baylibre/boot-ox820-cloudengines-pogoplug-series-3.txt > HTML log: https://protect2.fireeye.com/url?k=eaed2629-b73d2ee5- > eaecad66-000babff3793- > 84ba1e41025b4f73&u=https://storage.kernelci.org//broonie-regmap/for- > next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820- > cloudengines-pogoplug-series-3.html > Result: d3e014ec7d5e net: stmmac: platform: Fix MDIO init for platforms > without PHY > > Checks: > revert: PASS > verify: PASS > > Parameters: > Tree: broonie-regmap > URL: > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git > Branch: for-next > Target: ox820-cloudengines-pogoplug-series-3 > CPU arch: arm > Lab: lab-baylibre > Compiler: gcc-8 > Config: oxnas_v6_defconfig > Test suite: boot > > Breaking commit found: > > ------------------------------------------------------------------------------- > commit d3e014ec7d5ebe9644b5486bc530b91e62bbf624 > Author: Padmanabhan Rajanbabu <p.rajanbabu@samsung.com> > Date: Thu Dec 19 15:47:01 2019 +0530 > > net: stmmac: platform: Fix MDIO init for platforms without PHY > > 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> > Signed-off-by: David S. Miller <davem@davemloft.net> > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > index bedaff0c13bd..cc8d7e7bf9ac 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" }, > {}, > ------------------------------------------------------------------------------- > > > Git bisection log: > > ------------------------------------------------------------------------------- > git bisect start > # good: [e42617b825f8073569da76dc4510bfa019b1c35a] Linux 5.5-rc1 git > bisect good e42617b825f8073569da76dc4510bfa019b1c35a > # bad: [46cf053efec6a3a5f343fead837777efe8252a46] Linux 5.5-rc3 git bisect > bad 46cf053efec6a3a5f343fead837777efe8252a46 > # good: [2187f215ebaac73ddbd814696d7c7fa34f0c3de0] Merge tag 'for-5.5- > rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux > git bisect good 2187f215ebaac73ddbd814696d7c7fa34f0c3de0 > # good: [0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec] pipe: fix empty pipe > check in pipe_write() git bisect good > 0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec > # good: [040cda8a15210f19da7e29232c897ca6ca6cc950] Merge tag 'wireless- > drivers-2019-12-17' of > git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers > git bisect good 040cda8a15210f19da7e29232c897ca6ca6cc950 > # bad: [4bfeadfc0712bbc8a6556eef6d47cbae1099dea3] Merge branch 'sfc- > fix-bugs-introduced-by-XDP-patches' > git bisect bad 4bfeadfc0712bbc8a6556eef6d47cbae1099dea3 > # good: [0fd260056ef84ede8f444c66a3820811691fe884] Merge > git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf > git bisect good 0fd260056ef84ede8f444c66a3820811691fe884 > # good: [90b3b339364c76baa2436445401ea9ade040c216] net: hisilicon: Fix a > BUG trigered by wrong bytes_compl git bisect good > 90b3b339364c76baa2436445401ea9ade040c216 > # bad: [4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce] qede: Disable > hardware gro when xdp prog is installed git bisect bad > 4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce > # bad: [28a3b8408f70b646e78880a7eb0a97c22ace98d1] net/smc: unregister > ib devices in reboot_event git bisect bad > 28a3b8408f70b646e78880a7eb0a97c22ace98d1 > # bad: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: stmmac: > platform: Fix MDIO init for platforms without PHY git bisect bad > d3e014ec7d5ebe9644b5486bc530b91e62bbf624 > # good: [af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285] llc2: Fix return > statement of llc_stat_ev_rx_null_dsap_xid_c (and _test_c) git bisect good > af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285 > # first bad commit: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: > stmmac: platform: Fix MDIO init for platforms without PHY > ------------------------------------------------------------------------------- The mdio bus will be allocated in case of a phy transceiver is on board, but if fixed-link is configured, it will be NULL and of_mdiobus_register will not take effect. The commit d3e014ec7d5e fixes the code for fixed-link configuration. However, some platforms like oxnas820 which have phy transceivers (rgmii), fail. This is because the platforms expect the allocation of mdio_bus_data during stmmac_dt_phy. Proper solution to this is adding the mdio node in the device tree of the platform which can be fetched by stmmac_dt_phy. A rough addition to the Ethernet node can be as follows: pinctrl-names = "default"; pinctrl-0 = <&pinctrl_etha_mdio>; + mdio { + compatible = "snps,dwmac-mdio"; + #address-cells = <1>; + #size-cells = <0>; + }; }; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 2020-01-03 13:30 ` broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 Sriram Dash @ 2020-01-03 17:46 ` Florian Fainelli 2020-01-07 5:24 ` Sriram Dash 0 siblings, 1 reply; 6+ messages in thread From: Florian Fainelli @ 2020-01-03 17:46 UTC (permalink / raw) To: Sriram Dash, 'kernelci.org bot', tomeu.vizoso, khilman, 'David S. Miller', mgalka, guillaume.tucker, broonie, 'Jayati Sahu', 'Padmanabhan Rajanbabu', enric.balletbo, narmstrong Cc: 'Jose Abreu', 'Alexandre Torgue', rcsekar, netdev, linux-kernel, 'Maxime Coquelin', pankaj.dubey, 'Giuseppe Cavallaro', linux-stm32, linux-arm-kernel On 1/3/20 5:30 AM, Sriram Dash wrote: >> From: kernelci.org bot <bot@kernelci.org> >> Subject: broonie-regmap/for-next bisection: boot on ox820-cloudengines- >> pogoplug-series-3 >> >> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >> * This automated bisection report was sent to you on the basis * >> * that you may be involved with the breaking commit it has * >> * found. No manual investigation has been done to verify it, * >> * and the root cause of the problem may be somewhere else. * >> * * >> * If you do send a fix, please include this trailer: * >> * Reported-by: "kernelci.org bot" <bot@kernelci.org> * >> * * >> * Hope this helps! * >> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >> >> broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug- >> series-3 >> >> Summary: >> Start: 46cf053efec6 Linux 5.5-rc3 >> Details: https://protect2.fireeye.com/url?k=36fb52ed-6b2b5a21-36fad9a2- >> 000babff3793- >> f64e7c227e0a8b34&u=https://kernelci.org/boot/id/5e02ce65451524462f9731 >> 4f >> Plain log: https://protect2.fireeye.com/url?k=58f5fc3b-0525f4f7-58f47774- >> 000babff3793-f96a18481add0d7f&u=https://storage.kernelci.org//broonie- >> regmap/for-next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab- >> baylibre/boot-ox820-cloudengines-pogoplug-series-3.txt >> HTML log: https://protect2.fireeye.com/url?k=eaed2629-b73d2ee5- >> eaecad66-000babff3793- >> 84ba1e41025b4f73&u=https://storage.kernelci.org//broonie-regmap/for- >> next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820- >> cloudengines-pogoplug-series-3.html >> Result: d3e014ec7d5e net: stmmac: platform: Fix MDIO init for platforms >> without PHY >> >> Checks: >> revert: PASS >> verify: PASS >> >> Parameters: >> Tree: broonie-regmap >> URL: >> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git >> Branch: for-next >> Target: ox820-cloudengines-pogoplug-series-3 >> CPU arch: arm >> Lab: lab-baylibre >> Compiler: gcc-8 >> Config: oxnas_v6_defconfig >> Test suite: boot >> >> Breaking commit found: >> >> ------------------------------------------------------------------------------- >> commit d3e014ec7d5ebe9644b5486bc530b91e62bbf624 >> Author: Padmanabhan Rajanbabu <p.rajanbabu@samsung.com> >> Date: Thu Dec 19 15:47:01 2019 +0530 >> >> net: stmmac: platform: Fix MDIO init for platforms without PHY >> >> 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> >> Signed-off-by: David S. Miller <davem@davemloft.net> >> >> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >> index bedaff0c13bd..cc8d7e7bf9ac 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" }, >> {}, >> ------------------------------------------------------------------------------- >> >> >> Git bisection log: >> >> ------------------------------------------------------------------------------- >> git bisect start >> # good: [e42617b825f8073569da76dc4510bfa019b1c35a] Linux 5.5-rc1 git >> bisect good e42617b825f8073569da76dc4510bfa019b1c35a >> # bad: [46cf053efec6a3a5f343fead837777efe8252a46] Linux 5.5-rc3 git bisect >> bad 46cf053efec6a3a5f343fead837777efe8252a46 >> # good: [2187f215ebaac73ddbd814696d7c7fa34f0c3de0] Merge tag 'for-5.5- >> rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux >> git bisect good 2187f215ebaac73ddbd814696d7c7fa34f0c3de0 >> # good: [0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec] pipe: fix empty pipe >> check in pipe_write() git bisect good >> 0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec >> # good: [040cda8a15210f19da7e29232c897ca6ca6cc950] Merge tag 'wireless- >> drivers-2019-12-17' of >> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers >> git bisect good 040cda8a15210f19da7e29232c897ca6ca6cc950 >> # bad: [4bfeadfc0712bbc8a6556eef6d47cbae1099dea3] Merge branch 'sfc- >> fix-bugs-introduced-by-XDP-patches' >> git bisect bad 4bfeadfc0712bbc8a6556eef6d47cbae1099dea3 >> # good: [0fd260056ef84ede8f444c66a3820811691fe884] Merge >> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf >> git bisect good 0fd260056ef84ede8f444c66a3820811691fe884 >> # good: [90b3b339364c76baa2436445401ea9ade040c216] net: hisilicon: Fix a >> BUG trigered by wrong bytes_compl git bisect good >> 90b3b339364c76baa2436445401ea9ade040c216 >> # bad: [4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce] qede: Disable >> hardware gro when xdp prog is installed git bisect bad >> 4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce >> # bad: [28a3b8408f70b646e78880a7eb0a97c22ace98d1] net/smc: unregister >> ib devices in reboot_event git bisect bad >> 28a3b8408f70b646e78880a7eb0a97c22ace98d1 >> # bad: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: stmmac: >> platform: Fix MDIO init for platforms without PHY git bisect bad >> d3e014ec7d5ebe9644b5486bc530b91e62bbf624 >> # good: [af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285] llc2: Fix return >> statement of llc_stat_ev_rx_null_dsap_xid_c (and _test_c) git bisect good >> af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285 >> # first bad commit: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: >> stmmac: platform: Fix MDIO init for platforms without PHY >> ------------------------------------------------------------------------------- > > > The mdio bus will be allocated in case of a phy transceiver is on board, but if > fixed-link is configured, it will be NULL and of_mdiobus_register will > not take effect. There appears to be another possible flaw in the code here: for_each_child_of_node(np, plat->mdio_node) { if (of_device_is_compatible(plat->mdio_node, "snps,dwmac-mdio")) break; } the loop should use for_each_available_child_of_node() such that if a platform has a Device Tree definition where the MDIO bus node was provided but it was not disabled by default (a mistake, it should be disabled by default), and a "fixed-link" property ended up being used at the board level, we should not end-up with an invalid plat->mdio_node reference. Then the code could possibly eliminate the use of 'mdio' as a boolean and rely exclusively on plat->mdio_node. What do you think? And an alternative to your fix would be to scan even further the MDIO bus node for available child nodes, if there are none, do not perform the MDIO initialization at all since we have no MDIO devices beneath. > The commit d3e014ec7d5e fixes the code for fixed-link configuration. > However, some platforms like oxnas820 which have phy > transceivers (rgmii), fail. This is because the platforms expect the allocation > of mdio_bus_data during stmmac_dt_phy. > > Proper solution to this is adding the mdio node in the device tree of the > platform which can be fetched by stmmac_dt_phy. That sounds reasonable, but we should also not break existing platforms with existing Device Trees out there, as much as possible. -- Florian ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 2020-01-03 17:46 ` Florian Fainelli @ 2020-01-07 5:24 ` Sriram Dash 2020-01-07 5:50 ` Florian Fainelli 2020-01-07 5:50 ` Florian Fainelli 0 siblings, 2 replies; 6+ messages in thread From: Sriram Dash @ 2020-01-07 5:24 UTC (permalink / raw) To: 'David S. Miller', 'Florian Fainelli', 'kernelci.org bot', tomeu.vizoso, khilman, mgalka, guillaume.tucker, broonie, 'Jayati Sahu', 'Padmanabhan Rajanbabu', enric.balletbo, narmstrong Cc: 'Jose Abreu', 'Alexandre Torgue', rcsekar, netdev, linux-kernel, 'Maxime Coquelin', pankaj.dubey, 'Giuseppe Cavallaro', linux-stm32, linux-arm-kernel > From: Florian Fainelli <f.fainelli@gmail.com> > Subject: Re: broonie-regmap/for-next bisection: boot on ox820-cloudengines- > pogoplug-series-3 > > On 1/3/20 5:30 AM, Sriram Dash wrote: > >> From: kernelci.org bot <bot@kernelci.org> > >> Subject: broonie-regmap/for-next bisection: boot on > >> ox820-cloudengines- > >> pogoplug-series-3 > >> > >> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > >> * This automated bisection report was sent to you on the basis * > >> * that you may be involved with the breaking commit it has * > >> * found. No manual investigation has been done to verify it, * > >> * and the root cause of the problem may be somewhere else. * > >> * * > >> * If you do send a fix, please include this trailer: * > >> * Reported-by: "kernelci.org bot" <bot@kernelci.org> * > >> * * > >> * Hope this helps! * > >> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > >> > >> broonie-regmap/for-next bisection: boot on > >> ox820-cloudengines-pogoplug- > >> series-3 > >> > >> Summary: > >> Start: 46cf053efec6 Linux 5.5-rc3 > >> Details: https://protect2.fireeye.com/url?k=36fb52ed-6b2b5a21- > 36fad9a2- > >> 000babff3793- > >> f64e7c227e0a8b34&u=https://protect2.fireeye.com/url?k=2379492a-7ee2b5 > >> 49-2378c265-0cc47a31cdbc- > 914c67c9400b5bae&u=https://kernelci.org/boot > >> /id/5e02ce65451524462f9731 > >> 4f > >> Plain log: > >> https://protect2.fireeye.com/url?k=58f5fc3b-0525f4f7-58f47774- > >> 000babff3793-f96a18481add0d7f&u=https://protect2.fireeye.com/url?k=3c > >> 793260-61e2ce03-3c78b92f-0cc47a31cdbc- > c77f49890593c376&u=https://stor > >> age.kernelci.org//broonie- > >> regmap/for-next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab- > >> baylibre/boot-ox820-cloudengines-pogoplug-series-3.txt > >> HTML log: https://protect2.fireeye.com/url?k=eaed2629-b73d2ee5- > >> eaecad66-000babff3793- > >> 84ba1e41025b4f73&u=https://protect2.fireeye.com/url?k=8e80051e-d31bf9 > >> 7d-8e818e51-0cc47a31cdbc-dd2d5f3d7e3c3cd2&u=https://storage.kernelci. > >> org//broonie-regmap/for- > >> next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820- > >> cloudengines-pogoplug-series-3.html > >> Result: d3e014ec7d5e net: stmmac: platform: Fix MDIO init for platforms > >> without PHY > >> > >> Checks: > >> revert: PASS > >> verify: PASS > >> > >> Parameters: > >> Tree: broonie-regmap > >> URL: > >> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git > >> Branch: for-next > >> Target: ox820-cloudengines-pogoplug-series-3 > >> CPU arch: arm > >> Lab: lab-baylibre > >> Compiler: gcc-8 > >> Config: oxnas_v6_defconfig > >> Test suite: boot > >> > >> Breaking commit found: > >> > >> --------------------------------------------------------------------- > >> ---------- commit d3e014ec7d5ebe9644b5486bc530b91e62bbf624 > >> Author: Padmanabhan Rajanbabu <p.rajanbabu@samsung.com> > >> Date: Thu Dec 19 15:47:01 2019 +0530 > >> > >> net: stmmac: platform: Fix MDIO init for platforms without PHY > >> > >> 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> > >> Signed-off-by: David S. Miller <davem@davemloft.net> > >> > >> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > >> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > >> index bedaff0c13bd..cc8d7e7bf9ac 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" }, > >> {}, > >> --------------------------------------------------------------------- > >> ---------- > >> > >> > >> Git bisection log: > >> > >> --------------------------------------------------------------------- > >> ---------- > >> git bisect start > >> # good: [e42617b825f8073569da76dc4510bfa019b1c35a] Linux 5.5-rc1 git > >> bisect good e42617b825f8073569da76dc4510bfa019b1c35a > >> # bad: [46cf053efec6a3a5f343fead837777efe8252a46] Linux 5.5-rc3 git > >> bisect bad 46cf053efec6a3a5f343fead837777efe8252a46 > >> # good: [2187f215ebaac73ddbd814696d7c7fa34f0c3de0] Merge tag > >> 'for-5.5- rc2-tag' of > >> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux > >> git bisect good 2187f215ebaac73ddbd814696d7c7fa34f0c3de0 > >> # good: [0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec] pipe: fix empty > >> pipe check in pipe_write() git bisect good > >> 0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec > >> # good: [040cda8a15210f19da7e29232c897ca6ca6cc950] Merge tag > >> 'wireless- drivers-2019-12-17' of > >> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers > >> git bisect good 040cda8a15210f19da7e29232c897ca6ca6cc950 > >> # bad: [4bfeadfc0712bbc8a6556eef6d47cbae1099dea3] Merge branch 'sfc- > >> fix-bugs-introduced-by-XDP-patches' > >> git bisect bad 4bfeadfc0712bbc8a6556eef6d47cbae1099dea3 > >> # good: [0fd260056ef84ede8f444c66a3820811691fe884] Merge > >> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf > >> git bisect good 0fd260056ef84ede8f444c66a3820811691fe884 > >> # good: [90b3b339364c76baa2436445401ea9ade040c216] net: hisilicon: > >> Fix a BUG trigered by wrong bytes_compl git bisect good > >> 90b3b339364c76baa2436445401ea9ade040c216 > >> # bad: [4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce] qede: Disable > >> hardware gro when xdp prog is installed git bisect bad > >> 4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce > >> # bad: [28a3b8408f70b646e78880a7eb0a97c22ace98d1] net/smc: unregister > >> ib devices in reboot_event git bisect bad > >> 28a3b8408f70b646e78880a7eb0a97c22ace98d1 > >> # bad: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: stmmac: > >> platform: Fix MDIO init for platforms without PHY git bisect bad > >> d3e014ec7d5ebe9644b5486bc530b91e62bbf624 > >> # good: [af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285] llc2: Fix return > >> statement of llc_stat_ev_rx_null_dsap_xid_c (and _test_c) git bisect > >> good > >> af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285 > >> # first bad commit: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: > >> stmmac: platform: Fix MDIO init for platforms without PHY > >> --------------------------------------------------------------------- > >> ---------- > > > > > > The mdio bus will be allocated in case of a phy transceiver is on > > board, but if fixed-link is configured, it will be NULL and > > of_mdiobus_register will not take effect. > > There appears to be another possible flaw in the code here: > > for_each_child_of_node(np, plat->mdio_node) { > if (of_device_is_compatible(plat->mdio_node, > "snps,dwmac-mdio")) > break; > } > > the loop should use for_each_available_child_of_node() such that if a platform > has a Device Tree definition where the MDIO bus node was provided but it was > not disabled by default (a mistake, it should be disabled by default), and a "fixed- > link" property ended up being used at the board level, we should not end-up with > an invalid plat->mdio_node reference. Then the code could possibly eliminate > the use of 'mdio' as a boolean and rely exclusively on plat->mdio_node. What do > you think? > Hello Florian, Thanks for the review. We definitely see a problem here. For the platforms which have the snps,dwmac-mdio and they have made it disabled, it will fail. Also, We can completely remove the mdio variable from the function stmmac_dt_phy as what we essentially do is to check the plat->mdio_node. Something like this will help: diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c index 1f230bd..15c342e 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c @@ -320,7 +320,6 @@ 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; static const struct of_device_id need_mdio_ids[] = { { .compatible = "snps,dwc-qos-ethernet-4.10" }, {}, @@ -334,18 +333,13 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat, * the MDIO */ for_each_child_of_node(np, plat->mdio_node) { - if (of_device_is_compatible(plat->mdio_node, + if (for_each_available_child_of_node(plat->mdio_node, "snps,dwmac-mdio")) break; } } if (plat->mdio_node) { - dev_dbg(dev, "Found MDIO subnode\n"); - mdio = true; - } - - if (mdio) { plat->mdio_bus_data = devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data), GFP_KERNEL); Are you preparing a patch to address this, or we shall take it up? > And an alternative to your fix would be to scan even further the MDIO bus node > for available child nodes, if there are none, do not perform the MDIO > initialization at all since we have no MDIO devices beneath. > > > > The commit d3e014ec7d5e fixes the code for fixed-link configuration. > > However, some platforms like oxnas820 which have phy transceivers > > (rgmii), fail. This is because the platforms expect the allocation of > > mdio_bus_data during stmmac_dt_phy. > > > > Proper solution to this is adding the mdio node in the device tree of > > the platform which can be fetched by stmmac_dt_phy. > > That sounds reasonable, but we should also not break existing platforms with > existing Device Trees out there, as much as possible. I understand your point. Changing DT should be the last thing we should do. But, the code is broken for some platforms. Without the patch, the platforms with fixed-link will not work. For example, stih418-b2199.dts, will fail without the commit d3e014ec7d5e. With the patch, platforms with mdio and not declaring the dt parameters will fail. For that , we have some proposal: For the newer platforms , Make it mandatory to have the mdio or snps,dwmac-mdio property. There is no point of checking the device tree for mdio or snps,dwmac-mdio property and populating the plat->mdio_node, if the platforms are not having them in the device tree and expect mdio bus memory allocation. For the existing platforms, which do not have the mdio or snps,dwmac-mdio property and still have the phy, if they can, they must modify the dt and include the mdio or snps,dwmac-mdio property in their dts. For those platforms, which cannot modify the dt due to some reason or other, the platform should have a quirk in the platform glue layers, and use it in the stmmac_platform driver stmmac_dt_phy function to enable the mdio. > -- > Florian ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 2020-01-07 5:24 ` Sriram Dash @ 2020-01-07 5:50 ` Florian Fainelli 2020-01-07 5:50 ` Florian Fainelli 1 sibling, 0 replies; 6+ messages in thread From: Florian Fainelli @ 2020-01-07 5:50 UTC (permalink / raw) To: Sriram Dash, 'David S. Miller', 'kernelci.org bot', tomeu.vizoso, khilman, mgalka, guillaume.tucker, broonie, 'Jayati Sahu', 'Padmanabhan Rajanbabu', enric.balletbo, narmstrong, Heiko Stuebner Cc: 'Jose Abreu', 'Alexandre Torgue', rcsekar, netdev, linux-kernel, 'Maxime Coquelin', pankaj.dubey, 'Giuseppe Cavallaro', linux-stm32, linux-arm-kernel On 1/6/2020 9:24 PM, Sriram Dash wrote: >> From: Florian Fainelli <f.fainelli@gmail.com> >> Subject: Re: broonie-regmap/for-next bisection: boot on ox820-cloudengines- >> pogoplug-series-3 >> >> On 1/3/20 5:30 AM, Sriram Dash wrote: >>>> From: kernelci.org bot <bot@kernelci.org> >>>> Subject: broonie-regmap/for-next bisection: boot on >>>> ox820-cloudengines- >>>> pogoplug-series-3 >>>> >>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >>>> * This automated bisection report was sent to you on the basis * >>>> * that you may be involved with the breaking commit it has * >>>> * found. No manual investigation has been done to verify it, * >>>> * and the root cause of the problem may be somewhere else. * >>>> * * >>>> * If you do send a fix, please include this trailer: * >>>> * Reported-by: "kernelci.org bot" <bot@kernelci.org> * >>>> * * >>>> * Hope this helps! * >>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >>>> >>>> broonie-regmap/for-next bisection: boot on >>>> ox820-cloudengines-pogoplug- >>>> series-3 >>>> >>>> Summary: >>>> Start: 46cf053efec6 Linux 5.5-rc3 >>>> Details: https://protect2.fireeye.com/url?k=36fb52ed-6b2b5a21- >> 36fad9a2- >>>> 000babff3793- >>>> f64e7c227e0a8b34&u=https://protect2.fireeye.com/url?k=2379492a-7ee2b5 >>>> 49-2378c265-0cc47a31cdbc- >> 914c67c9400b5bae&u=https://kernelci.org/boot >>>> /id/5e02ce65451524462f9731 >>>> 4f >>>> Plain log: >>>> https://protect2.fireeye.com/url?k=58f5fc3b-0525f4f7-58f47774- >>>> 000babff3793-f96a18481add0d7f&u=https://protect2.fireeye.com/url?k=3c >>>> 793260-61e2ce03-3c78b92f-0cc47a31cdbc- >> c77f49890593c376&u=https://stor >>>> age.kernelci.org//broonie- >>>> regmap/for-next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab- >>>> baylibre/boot-ox820-cloudengines-pogoplug-series-3.txt >>>> HTML log: https://protect2.fireeye.com/url?k=eaed2629-b73d2ee5- >>>> eaecad66-000babff3793- >>>> 84ba1e41025b4f73&u=https://protect2.fireeye.com/url?k=8e80051e-d31bf9 >>>> 7d-8e818e51-0cc47a31cdbc-dd2d5f3d7e3c3cd2&u=https://storage.kernelci. >>>> org//broonie-regmap/for- >>>> next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820- >>>> cloudengines-pogoplug-series-3.html >>>> Result: d3e014ec7d5e net: stmmac: platform: Fix MDIO init for platforms >>>> without PHY >>>> >>>> Checks: >>>> revert: PASS >>>> verify: PASS >>>> >>>> Parameters: >>>> Tree: broonie-regmap >>>> URL: >>>> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git >>>> Branch: for-next >>>> Target: ox820-cloudengines-pogoplug-series-3 >>>> CPU arch: arm >>>> Lab: lab-baylibre >>>> Compiler: gcc-8 >>>> Config: oxnas_v6_defconfig >>>> Test suite: boot >>>> >>>> Breaking commit found: >>>> >>>> --------------------------------------------------------------------- >>>> ---------- commit d3e014ec7d5ebe9644b5486bc530b91e62bbf624 >>>> Author: Padmanabhan Rajanbabu <p.rajanbabu@samsung.com> >>>> Date: Thu Dec 19 15:47:01 2019 +0530 >>>> >>>> net: stmmac: platform: Fix MDIO init for platforms without PHY >>>> >>>> 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> >>>> Signed-off-by: David S. Miller <davem@davemloft.net> >>>> >>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >>>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >>>> index bedaff0c13bd..cc8d7e7bf9ac 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" }, >>>> {}, >>>> --------------------------------------------------------------------- >>>> ---------- >>>> >>>> >>>> Git bisection log: >>>> >>>> --------------------------------------------------------------------- >>>> ---------- >>>> git bisect start >>>> # good: [e42617b825f8073569da76dc4510bfa019b1c35a] Linux 5.5-rc1 git >>>> bisect good e42617b825f8073569da76dc4510bfa019b1c35a >>>> # bad: [46cf053efec6a3a5f343fead837777efe8252a46] Linux 5.5-rc3 git >>>> bisect bad 46cf053efec6a3a5f343fead837777efe8252a46 >>>> # good: [2187f215ebaac73ddbd814696d7c7fa34f0c3de0] Merge tag >>>> 'for-5.5- rc2-tag' of >>>> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux >>>> git bisect good 2187f215ebaac73ddbd814696d7c7fa34f0c3de0 >>>> # good: [0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec] pipe: fix empty >>>> pipe check in pipe_write() git bisect good >>>> 0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec >>>> # good: [040cda8a15210f19da7e29232c897ca6ca6cc950] Merge tag >>>> 'wireless- drivers-2019-12-17' of >>>> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers >>>> git bisect good 040cda8a15210f19da7e29232c897ca6ca6cc950 >>>> # bad: [4bfeadfc0712bbc8a6556eef6d47cbae1099dea3] Merge branch 'sfc- >>>> fix-bugs-introduced-by-XDP-patches' >>>> git bisect bad 4bfeadfc0712bbc8a6556eef6d47cbae1099dea3 >>>> # good: [0fd260056ef84ede8f444c66a3820811691fe884] Merge >>>> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf >>>> git bisect good 0fd260056ef84ede8f444c66a3820811691fe884 >>>> # good: [90b3b339364c76baa2436445401ea9ade040c216] net: hisilicon: >>>> Fix a BUG trigered by wrong bytes_compl git bisect good >>>> 90b3b339364c76baa2436445401ea9ade040c216 >>>> # bad: [4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce] qede: Disable >>>> hardware gro when xdp prog is installed git bisect bad >>>> 4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce >>>> # bad: [28a3b8408f70b646e78880a7eb0a97c22ace98d1] net/smc: unregister >>>> ib devices in reboot_event git bisect bad >>>> 28a3b8408f70b646e78880a7eb0a97c22ace98d1 >>>> # bad: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: stmmac: >>>> platform: Fix MDIO init for platforms without PHY git bisect bad >>>> d3e014ec7d5ebe9644b5486bc530b91e62bbf624 >>>> # good: [af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285] llc2: Fix return >>>> statement of llc_stat_ev_rx_null_dsap_xid_c (and _test_c) git bisect >>>> good >>>> af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285 >>>> # first bad commit: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: >>>> stmmac: platform: Fix MDIO init for platforms without PHY >>>> --------------------------------------------------------------------- >>>> ---------- >>> >>> >>> The mdio bus will be allocated in case of a phy transceiver is on >>> board, but if fixed-link is configured, it will be NULL and >>> of_mdiobus_register will not take effect. >> >> There appears to be another possible flaw in the code here: >> >> for_each_child_of_node(np, plat->mdio_node) { >> if (of_device_is_compatible(plat->mdio_node, >> "snps,dwmac-mdio")) >> break; >> } >> >> the loop should use for_each_available_child_of_node() such that if a platform >> has a Device Tree definition where the MDIO bus node was provided but it was >> not disabled by default (a mistake, it should be disabled by default), and a "fixed- >> link" property ended up being used at the board level, we should not end-up with >> an invalid plat->mdio_node reference. Then the code could possibly eliminate >> the use of 'mdio' as a boolean and rely exclusively on plat->mdio_node. What do >> you think? >> > > Hello Florian, > > Thanks for the review. We definitely see a problem here. For the platforms which have the snps,dwmac-mdio and they have made it disabled, it will fail. > Also, We can completely remove the mdio variable from the function stmmac_dt_phy as what we essentially do is to check the plat->mdio_node. > > Something like this will help: > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > index 1f230bd..15c342e 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > @@ -320,7 +320,6 @@ 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; > static const struct of_device_id need_mdio_ids[] = { > { .compatible = "snps,dwc-qos-ethernet-4.10" }, > {}, > @@ -334,18 +333,13 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat, > * the MDIO > */ > for_each_child_of_node(np, plat->mdio_node) { > - if (of_device_is_compatible(plat->mdio_node, > + if (for_each_available_child_of_node(plat->mdio_node, > "snps,dwmac-mdio")) > break; > } > } > > if (plat->mdio_node) { > - dev_dbg(dev, "Found MDIO subnode\n"); > - mdio = true; > - } > - > - if (mdio) { > plat->mdio_bus_data = > devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data), > GFP_KERNEL); > > > Are you preparing a patch to address this, or we shall take it up? I do not think your patch is going to fix the problem that Heiko reported because it would try to scan the MDIO bus node which is non-existent. Also not sure what the return value of for_each_* is supposed to be given it is a loop construct. > >> And an alternative to your fix would be to scan even further the MDIO bus node >> for available child nodes, if there are none, do not perform the MDIO >> initialization at all since we have no MDIO devices beneath. >> >> >>> The commit d3e014ec7d5e fixes the code for fixed-link configuration. >>> However, some platforms like oxnas820 which have phy transceivers >>> (rgmii), fail. This is because the platforms expect the allocation of >>> mdio_bus_data during stmmac_dt_phy. >>> >>> Proper solution to this is adding the mdio node in the device tree of >>> the platform which can be fetched by stmmac_dt_phy. >> >> That sounds reasonable, but we should also not break existing platforms with >> existing Device Trees out there, as much as possible. > > I understand your point. Changing DT should be the last thing we should do. > But, the code is broken for some platforms. Without the patch, the platforms with fixed-link will not work. > For example, stih418-b2199.dts, will fail without the commit d3e014ec7d5e. Humm then we should change the code to explicitly look for a fixed-link node with the use of of_phy_is_fixed_link() (which would work on the old style fixed-link that stih418-b2199.dts uses) instead of relying on some implicit or explicit MDIO bus registration behavior. The good thing is that I use arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts on a nearly daily basis so I can test if that works/does not work with a fixed-link plus a mdio bus node. > With the patch, platforms with mdio and not declaring the dt parameters will fail. > For that , we have some proposal: > For the newer platforms , Make it mandatory to have the mdio or snps,dwmac-mdio property. > There is no point of checking the device tree for mdio or snps,dwmac-mdio property and populating the plat->mdio_node, if the platforms are not having them in the device tree and expect mdio bus memory allocation. Yet that is what broke exactly here, the platforms that Heiko reported the breakage on, albeit doing something arguably fragile, are not making use of a phy-handle property nor a MDIO node to indicate where and how to connect to a PHY, ended up broken. They use implicit bus scanning going on by of_mdiobus_register(). > > For the existing platforms, which do not have the mdio or snps,dwmac-mdio property and still have the phy, if they can, they must modify the dt and include the mdio or snps,dwmac-mdio property in their dts. This should be done, but I doubt it is going to be because those Device Tree files are ABI and may be baked into firmware/boot loaders. > For those platforms, which cannot modify the dt due to some reason or other, the platform should have a quirk in the platform glue layers, and use it in the stmmac_platform driver stmmac_dt_phy function to enable the mdio. > Again, I do not think this is practical to do at all, not would it scale particularly well, given that the same compatible string for Rockchip gmac has been used with both the correct way and the incorrect way of specifying the connection to the PHY device node. -- Florian ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 2020-01-07 5:24 ` Sriram Dash 2020-01-07 5:50 ` Florian Fainelli @ 2020-01-07 5:50 ` Florian Fainelli 2020-01-07 7:19 ` Sriram Dash 1 sibling, 1 reply; 6+ messages in thread From: Florian Fainelli @ 2020-01-07 5:50 UTC (permalink / raw) To: Sriram Dash, 'David S. Miller', 'kernelci.org bot', tomeu.vizoso, khilman, mgalka, guillaume.tucker, broonie, 'Jayati Sahu', 'Padmanabhan Rajanbabu', enric.balletbo, narmstrong, Heiko Stuebner Cc: 'Jose Abreu', 'Alexandre Torgue', rcsekar, netdev, linux-kernel, 'Maxime Coquelin', pankaj.dubey, 'Giuseppe Cavallaro', linux-stm32, linux-arm-kernel On 1/6/2020 9:24 PM, Sriram Dash wrote: >> From: Florian Fainelli <f.fainelli@gmail.com> >> Subject: Re: broonie-regmap/for-next bisection: boot on ox820-cloudengines- >> pogoplug-series-3 >> >> On 1/3/20 5:30 AM, Sriram Dash wrote: >>>> From: kernelci.org bot <bot@kernelci.org> >>>> Subject: broonie-regmap/for-next bisection: boot on >>>> ox820-cloudengines- >>>> pogoplug-series-3 >>>> >>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >>>> * This automated bisection report was sent to you on the basis * >>>> * that you may be involved with the breaking commit it has * >>>> * found. No manual investigation has been done to verify it, * >>>> * and the root cause of the problem may be somewhere else. * >>>> * * >>>> * If you do send a fix, please include this trailer: * >>>> * Reported-by: "kernelci.org bot" <bot@kernelci.org> * >>>> * * >>>> * Hope this helps! * >>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * >>>> >>>> broonie-regmap/for-next bisection: boot on >>>> ox820-cloudengines-pogoplug- >>>> series-3 >>>> >>>> Summary: >>>> Start: 46cf053efec6 Linux 5.5-rc3 >>>> Details: https://protect2.fireeye.com/url?k=36fb52ed-6b2b5a21- >> 36fad9a2- >>>> 000babff3793- >>>> f64e7c227e0a8b34&u=https://protect2.fireeye.com/url?k=2379492a-7ee2b5 >>>> 49-2378c265-0cc47a31cdbc- >> 914c67c9400b5bae&u=https://kernelci.org/boot >>>> /id/5e02ce65451524462f9731 >>>> 4f >>>> Plain log: >>>> https://protect2.fireeye.com/url?k=58f5fc3b-0525f4f7-58f47774- >>>> 000babff3793-f96a18481add0d7f&u=https://protect2.fireeye.com/url?k=3c >>>> 793260-61e2ce03-3c78b92f-0cc47a31cdbc- >> c77f49890593c376&u=https://stor >>>> age.kernelci.org//broonie- >>>> regmap/for-next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab- >>>> baylibre/boot-ox820-cloudengines-pogoplug-series-3.txt >>>> HTML log: https://protect2.fireeye.com/url?k=eaed2629-b73d2ee5- >>>> eaecad66-000babff3793- >>>> 84ba1e41025b4f73&u=https://protect2.fireeye.com/url?k=8e80051e-d31bf9 >>>> 7d-8e818e51-0cc47a31cdbc-dd2d5f3d7e3c3cd2&u=https://storage.kernelci. >>>> org//broonie-regmap/for- >>>> next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820- >>>> cloudengines-pogoplug-series-3.html >>>> Result: d3e014ec7d5e net: stmmac: platform: Fix MDIO init for platforms >>>> without PHY >>>> >>>> Checks: >>>> revert: PASS >>>> verify: PASS >>>> >>>> Parameters: >>>> Tree: broonie-regmap >>>> URL: >>>> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git >>>> Branch: for-next >>>> Target: ox820-cloudengines-pogoplug-series-3 >>>> CPU arch: arm >>>> Lab: lab-baylibre >>>> Compiler: gcc-8 >>>> Config: oxnas_v6_defconfig >>>> Test suite: boot >>>> >>>> Breaking commit found: >>>> >>>> --------------------------------------------------------------------- >>>> ---------- commit d3e014ec7d5ebe9644b5486bc530b91e62bbf624 >>>> Author: Padmanabhan Rajanbabu <p.rajanbabu@samsung.com> >>>> Date: Thu Dec 19 15:47:01 2019 +0530 >>>> >>>> net: stmmac: platform: Fix MDIO init for platforms without PHY >>>> >>>> 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> >>>> Signed-off-by: David S. Miller <davem@davemloft.net> >>>> >>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >>>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c >>>> index bedaff0c13bd..cc8d7e7bf9ac 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" }, >>>> {}, >>>> --------------------------------------------------------------------- >>>> ---------- >>>> >>>> >>>> Git bisection log: >>>> >>>> --------------------------------------------------------------------- >>>> ---------- >>>> git bisect start >>>> # good: [e42617b825f8073569da76dc4510bfa019b1c35a] Linux 5.5-rc1 git >>>> bisect good e42617b825f8073569da76dc4510bfa019b1c35a >>>> # bad: [46cf053efec6a3a5f343fead837777efe8252a46] Linux 5.5-rc3 git >>>> bisect bad 46cf053efec6a3a5f343fead837777efe8252a46 >>>> # good: [2187f215ebaac73ddbd814696d7c7fa34f0c3de0] Merge tag >>>> 'for-5.5- rc2-tag' of >>>> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux >>>> git bisect good 2187f215ebaac73ddbd814696d7c7fa34f0c3de0 >>>> # good: [0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec] pipe: fix empty >>>> pipe check in pipe_write() git bisect good >>>> 0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec >>>> # good: [040cda8a15210f19da7e29232c897ca6ca6cc950] Merge tag >>>> 'wireless- drivers-2019-12-17' of >>>> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers >>>> git bisect good 040cda8a15210f19da7e29232c897ca6ca6cc950 >>>> # bad: [4bfeadfc0712bbc8a6556eef6d47cbae1099dea3] Merge branch 'sfc- >>>> fix-bugs-introduced-by-XDP-patches' >>>> git bisect bad 4bfeadfc0712bbc8a6556eef6d47cbae1099dea3 >>>> # good: [0fd260056ef84ede8f444c66a3820811691fe884] Merge >>>> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf >>>> git bisect good 0fd260056ef84ede8f444c66a3820811691fe884 >>>> # good: [90b3b339364c76baa2436445401ea9ade040c216] net: hisilicon: >>>> Fix a BUG trigered by wrong bytes_compl git bisect good >>>> 90b3b339364c76baa2436445401ea9ade040c216 >>>> # bad: [4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce] qede: Disable >>>> hardware gro when xdp prog is installed git bisect bad >>>> 4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce >>>> # bad: [28a3b8408f70b646e78880a7eb0a97c22ace98d1] net/smc: unregister >>>> ib devices in reboot_event git bisect bad >>>> 28a3b8408f70b646e78880a7eb0a97c22ace98d1 >>>> # bad: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: stmmac: >>>> platform: Fix MDIO init for platforms without PHY git bisect bad >>>> d3e014ec7d5ebe9644b5486bc530b91e62bbf624 >>>> # good: [af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285] llc2: Fix return >>>> statement of llc_stat_ev_rx_null_dsap_xid_c (and _test_c) git bisect >>>> good >>>> af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285 >>>> # first bad commit: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: >>>> stmmac: platform: Fix MDIO init for platforms without PHY >>>> --------------------------------------------------------------------- >>>> ---------- >>> >>> >>> The mdio bus will be allocated in case of a phy transceiver is on >>> board, but if fixed-link is configured, it will be NULL and >>> of_mdiobus_register will not take effect. >> >> There appears to be another possible flaw in the code here: >> >> for_each_child_of_node(np, plat->mdio_node) { >> if (of_device_is_compatible(plat->mdio_node, >> "snps,dwmac-mdio")) >> break; >> } >> >> the loop should use for_each_available_child_of_node() such that if a platform >> has a Device Tree definition where the MDIO bus node was provided but it was >> not disabled by default (a mistake, it should be disabled by default), and a "fixed- >> link" property ended up being used at the board level, we should not end-up with >> an invalid plat->mdio_node reference. Then the code could possibly eliminate >> the use of 'mdio' as a boolean and rely exclusively on plat->mdio_node. What do >> you think? >> > > Hello Florian, > > Thanks for the review. We definitely see a problem here. For the platforms which have the snps,dwmac-mdio and they have made it disabled, it will fail. > Also, We can completely remove the mdio variable from the function stmmac_dt_phy as what we essentially do is to check the plat->mdio_node. > > Something like this will help: > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > index 1f230bd..15c342e 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > @@ -320,7 +320,6 @@ 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; > static const struct of_device_id need_mdio_ids[] = { > { .compatible = "snps,dwc-qos-ethernet-4.10" }, > {}, > @@ -334,18 +333,13 @@ static int stmmac_dt_phy(struct plat_stmmacenet_data *plat, > * the MDIO > */ > for_each_child_of_node(np, plat->mdio_node) { > - if (of_device_is_compatible(plat->mdio_node, > + if (for_each_available_child_of_node(plat->mdio_node, > "snps,dwmac-mdio")) > break; > } > } > > if (plat->mdio_node) { > - dev_dbg(dev, "Found MDIO subnode\n"); > - mdio = true; > - } > - > - if (mdio) { > plat->mdio_bus_data = > devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data), > GFP_KERNEL); > > > Are you preparing a patch to address this, or we shall take it up? I do not think your patch is going to fix the problem that Heiko reported because it would try to scan the MDIO bus node which is non-existent. Also not sure what the return value of for_each_* is supposed to be given it is a loop construct. > >> And an alternative to your fix would be to scan even further the MDIO bus node >> for available child nodes, if there are none, do not perform the MDIO >> initialization at all since we have no MDIO devices beneath. >> >> >>> The commit d3e014ec7d5e fixes the code for fixed-link configuration. >>> However, some platforms like oxnas820 which have phy transceivers >>> (rgmii), fail. This is because the platforms expect the allocation of >>> mdio_bus_data during stmmac_dt_phy. >>> >>> Proper solution to this is adding the mdio node in the device tree of >>> the platform which can be fetched by stmmac_dt_phy. >> >> That sounds reasonable, but we should also not break existing platforms with >> existing Device Trees out there, as much as possible. > > I understand your point. Changing DT should be the last thing we should do. > But, the code is broken for some platforms. Without the patch, the platforms with fixed-link will not work. > For example, stih418-b2199.dts, will fail without the commit d3e014ec7d5e. Humm then we should change the code to explicitly look for a fixed-link node with the use of of_phy_is_fixed_link() (which would work on the old style fixed-link that stih418-b2199.dts uses) instead of relying on some implicit or explicit MDIO bus registration behavior. The good thing is that I use arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts on a nearly daily basis so I can test if that works/does not work with a fixed-link plus a mdio bus node. > With the patch, platforms with mdio and not declaring the dt parameters will fail. > For that , we have some proposal: > For the newer platforms , Make it mandatory to have the mdio or snps,dwmac-mdio property. > There is no point of checking the device tree for mdio or snps,dwmac-mdio property and populating the plat->mdio_node, if the platforms are not having them in the device tree and expect mdio bus memory allocation. Yet that is what broke exactly here, the platforms that Heiko reported the breakage on, albeit doing something arguably fragile, are not making use of a phy-handle property nor a MDIO node to indicate where and how to connect to a PHY, ended up broken. They use implicit bus scanning going on by of_mdiobus_register(). > > For the existing platforms, which do not have the mdio or snps,dwmac-mdio property and still have the phy, if they can, they must modify the dt and include the mdio or snps,dwmac-mdio property in their dts. This should be done, but I doubt it is going to be because those Device Tree files are ABI and may be baked into firmware/boot loaders. > For those platforms, which cannot modify the dt due to some reason or other, the platform should have a quirk in the platform glue layers, and use it in the stmmac_platform driver stmmac_dt_phy function to enable the mdio. > Again, I do not think this is practical to do at all, not would it scale particularly well, given that the same compatible string for Rockchip gmac has been used with both the correct way and the incorrect way of specifying the connection to the PHY device node. -- Florian ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 2020-01-07 5:50 ` Florian Fainelli @ 2020-01-07 7:19 ` Sriram Dash 0 siblings, 0 replies; 6+ messages in thread From: Sriram Dash @ 2020-01-07 7:19 UTC (permalink / raw) To: 'Florian Fainelli', 'David S. Miller', 'kernelci.org bot', tomeu.vizoso, khilman, mgalka, guillaume.tucker, broonie, 'Jayati Sahu', 'Padmanabhan Rajanbabu', enric.balletbo, narmstrong, 'Heiko Stuebner' Cc: 'Jose Abreu', 'Alexandre Torgue', rcsekar, netdev, linux-kernel, 'Maxime Coquelin', pankaj.dubey, 'Giuseppe Cavallaro', linux-stm32, linux-arm-kernel > From: Florian Fainelli <f.fainelli@gmail.com> > Sent: 07 January 2020 11:21 > Subject: Re: broonie-regmap/for-next bisection: boot on ox820-cloudengines- > pogoplug-series-3 > > > > On 1/6/2020 9:24 PM, Sriram Dash wrote: > >> From: Florian Fainelli <f.fainelli@gmail.com> > >> Subject: Re: broonie-regmap/for-next bisection: boot on > >> ox820-cloudengines- > >> pogoplug-series-3 > >> > >> On 1/3/20 5:30 AM, Sriram Dash wrote: > >>>> From: kernelci.org bot <bot@kernelci.org> > >>>> Subject: broonie-regmap/for-next bisection: boot on > >>>> ox820-cloudengines- > >>>> pogoplug-series-3 > >>>> > >>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > >>>> * This automated bisection report was sent to you on the basis * > >>>> * that you may be involved with the breaking commit it has * > >>>> * found. No manual investigation has been done to verify it, * > >>>> * and the root cause of the problem may be somewhere else. * > >>>> * * > >>>> * If you do send a fix, please include this trailer: * > >>>> * Reported-by: "kernelci.org bot" <bot@kernelci.org> * > >>>> * * > >>>> * Hope this helps! * > >>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > >>>> > >>>> broonie-regmap/for-next bisection: boot on > >>>> ox820-cloudengines-pogoplug- > >>>> series-3 > >>>> > >>>> Summary: > >>>> Start: 46cf053efec6 Linux 5.5-rc3 > >>>> Details: https://protect2.fireeye.com/url?k=36fb52ed-6b2b5a21- > >> 36fad9a2- > >>>> 000babff3793- > >>>> f64e7c227e0a8b34&u=https://protect2.fireeye.com/url?k=2379492a-7ee2 > >>>> b5 > >>>> 49-2378c265-0cc47a31cdbc- > >> 914c67c9400b5bae&u=https://protect2.fireeye.com/url?k=340b13ed- > 699712 > >> 8d-340a98a2-0cc47a31307c- > 743b42a2202bdce9&u=https://kernelci.org/boot > >>>> /id/5e02ce65451524462f9731 > >>>> 4f > >>>> Plain log: > >>>> https://protect2.fireeye.com/url?k=58f5fc3b-0525f4f7-58f47774- > >>>> 000babff3793-f96a18481add0d7f&u=https://protect2.fireeye.com/url?k= > >>>> 3c > >>>> 793260-61e2ce03-3c78b92f-0cc47a31cdbc- > >> c77f49890593c376&u=https://stor > >>>> age.kernelci.org//broonie- > >>>> regmap/for-next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab- > >>>> baylibre/boot-ox820-cloudengines-pogoplug-series-3.txt > >>>> HTML log: https://protect2.fireeye.com/url?k=eaed2629-b73d2ee5- > >>>> eaecad66-000babff3793- > >>>> 84ba1e41025b4f73&u=https://protect2.fireeye.com/url?k=8e80051e-d31b > >>>> f9 > >>>> 7d-8e818e51-0cc47a31cdbc- > dd2d5f3d7e3c3cd2&u=https://protect2.fireeye.com/url?k=b2fc89d0-ef6088b0- > b2fd029f-0cc47a31307c-30e2364c4b1f1a98&u=https://storage.kernelci/. > >>>> org//broonie-regmap/for- > >>>> next/v5.5-rc3/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820- > >>>> cloudengines-pogoplug-series-3.html > >>>> Result: d3e014ec7d5e net: stmmac: platform: Fix MDIO init for > platforms > >>>> without PHY > >>>> > >>>> Checks: > >>>> revert: PASS > >>>> verify: PASS > >>>> > >>>> Parameters: > >>>> Tree: broonie-regmap > >>>> URL: > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git > >>>> Branch: for-next > >>>> Target: ox820-cloudengines-pogoplug-series-3 > >>>> CPU arch: arm > >>>> Lab: lab-baylibre > >>>> Compiler: gcc-8 > >>>> Config: oxnas_v6_defconfig > >>>> Test suite: boot > >>>> > >>>> Breaking commit found: > >>>> > >>>> ------------------------------------------------------------------- > >>>> -- > >>>> ---------- commit d3e014ec7d5ebe9644b5486bc530b91e62bbf624 > >>>> Author: Padmanabhan Rajanbabu <p.rajanbabu@samsung.com> > >>>> Date: Thu Dec 19 15:47:01 2019 +0530 > >>>> > >>>> net: stmmac: platform: Fix MDIO init for platforms without PHY > >>>> > >>>> 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> > >>>> Signed-off-by: David S. Miller <davem@davemloft.net> > >>>> > >>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > >>>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > >>>> index bedaff0c13bd..cc8d7e7bf9ac 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" }, > >>>> {}, > >>>> ------------------------------------------------------------------- > >>>> -- > >>>> ---------- > >>>> > >>>> > >>>> Git bisection log: > >>>> > >>>> ------------------------------------------------------------------- > >>>> -- > >>>> ---------- > >>>> git bisect start > >>>> # good: [e42617b825f8073569da76dc4510bfa019b1c35a] Linux 5.5-rc1 > >>>> git bisect good e42617b825f8073569da76dc4510bfa019b1c35a > >>>> # bad: [46cf053efec6a3a5f343fead837777efe8252a46] Linux 5.5-rc3 git > >>>> bisect bad 46cf053efec6a3a5f343fead837777efe8252a46 > >>>> # good: [2187f215ebaac73ddbd814696d7c7fa34f0c3de0] Merge tag > >>>> 'for-5.5- rc2-tag' of > >>>> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux > >>>> git bisect good 2187f215ebaac73ddbd814696d7c7fa34f0c3de0 > >>>> # good: [0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec] pipe: fix empty > >>>> pipe check in pipe_write() git bisect good > >>>> 0dd1e3773ae8afc4bfdce782bdeffc10f9cae6ec > >>>> # good: [040cda8a15210f19da7e29232c897ca6ca6cc950] Merge tag > >>>> 'wireless- drivers-2019-12-17' of > >>>> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-driver > >>>> s git bisect good 040cda8a15210f19da7e29232c897ca6ca6cc950 > >>>> # bad: [4bfeadfc0712bbc8a6556eef6d47cbae1099dea3] Merge branch > >>>> 'sfc- fix-bugs-introduced-by-XDP-patches' > >>>> git bisect bad 4bfeadfc0712bbc8a6556eef6d47cbae1099dea3 > >>>> # good: [0fd260056ef84ede8f444c66a3820811691fe884] Merge > >>>> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf > >>>> git bisect good 0fd260056ef84ede8f444c66a3820811691fe884 > >>>> # good: [90b3b339364c76baa2436445401ea9ade040c216] net: hisilicon: > >>>> Fix a BUG trigered by wrong bytes_compl git bisect good > >>>> 90b3b339364c76baa2436445401ea9ade040c216 > >>>> # bad: [4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce] qede: Disable > >>>> hardware gro when xdp prog is installed git bisect bad > >>>> 4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce > >>>> # bad: [28a3b8408f70b646e78880a7eb0a97c22ace98d1] net/smc: > >>>> unregister ib devices in reboot_event git bisect bad > >>>> 28a3b8408f70b646e78880a7eb0a97c22ace98d1 > >>>> # bad: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: stmmac: > >>>> platform: Fix MDIO init for platforms without PHY git bisect bad > >>>> d3e014ec7d5ebe9644b5486bc530b91e62bbf624 > >>>> # good: [af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285] llc2: Fix return > >>>> statement of llc_stat_ev_rx_null_dsap_xid_c (and _test_c) git > >>>> bisect good > >>>> af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285 > >>>> # first bad commit: [d3e014ec7d5ebe9644b5486bc530b91e62bbf624] net: > >>>> stmmac: platform: Fix MDIO init for platforms without PHY > >>>> ------------------------------------------------------------------- > >>>> -- > >>>> ---------- > >>> > >>> > >>> The mdio bus will be allocated in case of a phy transceiver is on > >>> board, but if fixed-link is configured, it will be NULL and > >>> of_mdiobus_register will not take effect. > >> > >> There appears to be another possible flaw in the code here: > >> > >> for_each_child_of_node(np, plat->mdio_node) { > >> if (of_device_is_compatible(plat->mdio_node, > >> "snps,dwmac-mdio")) > >> break; > >> } > >> > >> the loop should use for_each_available_child_of_node() such that if a > >> platform has a Device Tree definition where the MDIO bus node was > >> provided but it was not disabled by default (a mistake, it should be > >> disabled by default), and a "fixed- link" property ended up being > >> used at the board level, we should not end-up with an invalid > >> plat->mdio_node reference. Then the code could possibly eliminate the > >> use of 'mdio' as a boolean and rely exclusively on plat->mdio_node. What do > you think? > >> > > > > Hello Florian, > > > > Thanks for the review. We definitely see a problem here. For the platforms > which have the snps,dwmac-mdio and they have made it disabled, it will fail. > > Also, We can completely remove the mdio variable from the function > stmmac_dt_phy as what we essentially do is to check the plat->mdio_node. > > > > Something like this will help: > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > > b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > > index 1f230bd..15c342e 100644 > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c > > @@ -320,7 +320,6 @@ 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; > > static const struct of_device_id need_mdio_ids[] = { > > { .compatible = "snps,dwc-qos-ethernet-4.10" }, > > {}, > > @@ -334,18 +333,13 @@ static int stmmac_dt_phy(struct > plat_stmmacenet_data *plat, > > * the MDIO > > */ > > for_each_child_of_node(np, plat->mdio_node) { > > - if (of_device_is_compatible(plat->mdio_node, > > + if > > + (for_each_available_child_of_node(plat->mdio_node, > > "snps,dwmac-mdio")) > > break; > > } > > } > > > > if (plat->mdio_node) { > > - dev_dbg(dev, "Found MDIO subnode\n"); > > - mdio = true; > > - } > > - > > - if (mdio) { > > plat->mdio_bus_data = > > devm_kzalloc(dev, sizeof(struct stmmac_mdio_bus_data), > > GFP_KERNEL); > > > > > > Are you preparing a patch to address this, or we shall take it up? > > I do not think your patch is going to fix the problem that Heiko reported because > it would try to scan the MDIO bus node which is non-existent. Also not sure what > the return value of for_each_* is supposed to be given it is a loop construct. > This diff will not solve Heiko's problem. This diff is addressing a different issue. What it intends to do is : 1. as we decide the value mdio valriable on the basis of plat->mdio_node And then use it to decide the mdio_bus_data allocation, we can remove the mdio variable altogether from the picture. 2. This was addressing another problem you figured. If some platforms which have the property snps,dwmac-mdio present in dt, but it is disabled, this diff will correct the behaviour. Minor correction in the diff for_each_child_of_node -> for_each_available_child_of_node > > > >> And an alternative to your fix would be to scan even further the MDIO > >> bus node for available child nodes, if there are none, do not perform > >> the MDIO initialization at all since we have no MDIO devices beneath. > >> > >> > >>> The commit d3e014ec7d5e fixes the code for fixed-link configuration. > >>> However, some platforms like oxnas820 which have phy transceivers > >>> (rgmii), fail. This is because the platforms expect the allocation > >>> of mdio_bus_data during stmmac_dt_phy. > >>> > >>> Proper solution to this is adding the mdio node in the device tree > >>> of the platform which can be fetched by stmmac_dt_phy. > >> > >> That sounds reasonable, but we should also not break existing > >> platforms with existing Device Trees out there, as much as possible. > > > > I understand your point. Changing DT should be the last thing we should do. > > But, the code is broken for some platforms. Without the patch, the platforms > with fixed-link will not work. > > For example, stih418-b2199.dts, will fail without the commit d3e014ec7d5e. > Humm then we should change the code to explicitly look for a fixed-link node > with the use of of_phy_is_fixed_link() (which would work on the old style fixed- > link that stih418-b2199.dts uses) instead of relying on some implicit or explicit > MDIO bus registration behavior. > This can be a possible solution. But rather that a proper fix, IMO, this looks more like a hotfix for the platforms that do not include the snps,dwmac-mdio / mdio in the device tree. This is not targeting the actual issue here. By bypassing the issue, we may give rise to bigger problems in future, and it will be difficult to maintain the code. > The good thing is that I use arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts > on a nearly daily basis so I can test if that works/does not work with a fixed-link > plus a mdio bus node. > This is good indeed. :) > > With the patch, platforms with mdio and not declaring the dt parameters will > fail. > > For that , we have some proposal: > > For the newer platforms , Make it mandatory to have the mdio or > snps,dwmac-mdio property. > > There is no point of checking the device tree for mdio or snps,dwmac-mdio > property and populating the plat->mdio_node, if the platforms are not having > them in the device tree and expect mdio bus memory allocation. > > Yet that is what broke exactly here, the platforms that Heiko reported the > breakage on, albeit doing something arguably fragile, are not making use of a > phy-handle property nor a MDIO node to indicate where and how to connect to > a PHY, ended up broken. They use implicit bus scanning going on by > of_mdiobus_register(). > > > > > For the existing platforms, which do not have the mdio or snps,dwmac-mdio > property and still have the phy, if they can, they must modify the dt and include > the mdio or snps,dwmac-mdio property in their dts. > > This should be done, but I doubt it is going to be because those Device Tree files > are ABI and may be baked into firmware/boot loaders. > > > For those platforms, which cannot modify the dt due to some reason or other, > the platform should have a quirk in the platform glue layers, and use it in the > stmmac_platform driver stmmac_dt_phy function to enable the mdio. > > > > Again, I do not think this is practical to do at all, not would it scale particularly > well, given that the same compatible string for Rockchip gmac has been used > with both the correct way and the incorrect way of specifying the connection to > the PHY device node. I know it’s a pain. It will be difficult to maintain for the 8 broken platforms which was listed in https://lkml.org/lkml/2020/1/7/22. But eventually, we will make the code better. I went through the Rockchip code and I found rockchip,px30-gmac is used for the broken platform. In the dwmac-rk.c glue file, it also has the platform data, where rk_gmac_ops can hold the fix for the mdio, and can update a new private data member of stmmac_platform driver, which can hold the data passed from glue layer of the broken platforms. This in turn can leverage and make amends to the mdio bool variable for the stmmac_platform stmmac_dt_phy function. Similar modification can be done for other broken platforms. > -- > Florian ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-07 7:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CGME20191225075056epcas4p2ab51fc6ff1642705a61f906189bb29f0@epcas4p2.samsung.com>
[not found] ` <5e0314da.1c69fb81.a7d63.29c1@mx.google.com>
2020-01-03 13:30 ` broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 Sriram Dash
2020-01-03 17:46 ` Florian Fainelli
2020-01-07 5:24 ` Sriram Dash
2020-01-07 5:50 ` Florian Fainelli
2020-01-07 5:50 ` Florian Fainelli
2020-01-07 7:19 ` Sriram Dash
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox