All of lore.kernel.org
 help / color / mirror / Atom feed
* broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
@ 2019-12-25  7:50 ` kernelci.org bot
  2020-01-03 13:30     ` Sriram Dash
  0 siblings, 1 reply; 14+ messages in thread
From: kernelci.org bot @ 2019-12-25  7:50 UTC (permalink / raw)
  To: tomeu.vizoso, khilman, David S. Miller, mgalka, guillaume.tucker,
	broonie, Jayati Sahu, Sriram Dash, Padmanabhan Rajanbabu,
	enric.balletbo
  Cc: Jose Abreu, Alexandre Torgue, netdev, linux-kernel,
	David S. Miller, Maxime Coquelin, Giuseppe Cavallaro,
	linux-stm32, linux-arm-kernel

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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://kernelci.org/boot/id/5e02ce65451524462f97314f
  Plain log:  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://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
-------------------------------------------------------------------------------

_______________________________________________
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] 14+ messages in thread

* RE: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
  2019-12-25  7:50 ` broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 kernelci.org bot
@ 2020-01-03 13:30     ` Sriram Dash
  0 siblings, 0 replies; 14+ 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] 14+ messages in thread

* RE: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
@ 2020-01-03 13:30     ` Sriram Dash
  0 siblings, 0 replies; 14+ 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: 'Jose Abreu', 'Alexandre Torgue',
	rcsekar, netdev, linux-kernel, 'David S. Miller',
	'Maxime Coquelin',
	pankaj.dubey, 'Giuseppe Cavallaro',
	linux-stm32, linux-arm-kernel

> 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>;
+       };
 };



_______________________________________________
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] 14+ messages in thread

* Re: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
  2020-01-03 13:30     ` Sriram Dash
@ 2020-01-03 17:46       ` Florian Fainelli
  -1 siblings, 0 replies; 14+ 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] 14+ messages in thread

* Re: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
@ 2020-01-03 17:46       ` Florian Fainelli
  0 siblings, 0 replies; 14+ 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

_______________________________________________
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] 14+ 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
  -1 siblings, 0 replies; 14+ 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] 14+ messages in thread

* RE: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
@ 2020-01-07  5:24         ` Sriram Dash
  0 siblings, 0 replies; 14+ 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


_______________________________________________
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] 14+ 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
  -1 siblings, 0 replies; 14+ 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] 14+ 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
  -1 siblings, 0 replies; 14+ 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] 14+ messages in thread

* Re: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
@ 2020-01-07  5:50           ` Florian Fainelli
  0 siblings, 0 replies; 14+ 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

_______________________________________________
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] 14+ messages in thread

* Re: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
@ 2020-01-07  5:50           ` Florian Fainelli
  0 siblings, 0 replies; 14+ 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

_______________________________________________
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] 14+ 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
  -1 siblings, 0 replies; 14+ 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] 14+ messages in thread

* RE: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
@ 2020-01-07  7:19             ` Sriram Dash
  0 siblings, 0 replies; 14+ 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



_______________________________________________
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] 14+ messages in thread

* RE: broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
  2020-01-07  7:19             ` Sriram Dash
  (?)
@ 2020-01-07  9:01             ` Jose Abreu
  -1 siblings, 0 replies; 14+ messages in thread
From: Jose Abreu @ 2020-01-07  9:01 UTC (permalink / raw)
  To: Sriram Dash, '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: 'Alexandre Torgue',
	rcsekar, netdev, linux-kernel, 'Maxime Coquelin',
	pankaj.dubey, 'Giuseppe Cavallaro',
	linux-stm32, linux-arm-kernel

Sriram, Florian, Heiko,

Thank you a lot for looking into this! Unfortunately I was FTO and then 
sick which caused my mails to pile up. I'll try to take a look at this 
during the week. Please cc' me in the follow-up patches and sorry for my 
delayed answer.

---
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] 14+ messages in thread

end of thread, other threads:[~2020-01-07  9:01 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CGME20191225075056epcas4p2ab51fc6ff1642705a61f906189bb29f0@epcas4p2.samsung.com>
2019-12-25  7:50 ` broonie-regmap/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 kernelci.org bot
2020-01-03 13:30   ` Sriram Dash
2020-01-03 13:30     ` Sriram Dash
2020-01-03 17:46     ` Florian Fainelli
2020-01-03 17:46       ` Florian Fainelli
2020-01-07  5:24       ` Sriram Dash
2020-01-07  5:24         ` Sriram Dash
2020-01-07  5:50         ` Florian Fainelli
2020-01-07  5:50           ` Florian Fainelli
2020-01-07  5:50         ` Florian Fainelli
2020-01-07  5:50           ` Florian Fainelli
2020-01-07  7:19           ` Sriram Dash
2020-01-07  7:19             ` Sriram Dash
2020-01-07  9:01             ` Jose Abreu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.