NC-SI driver: probing doesn't happen or fails when enabling RMII board mux after driver load

[GHF]

On Zaius, two TS3L110RGYR parts mux the NC-SI signals for the BMC between the LAN-on-MB, mezz card, and an HDMI connector. If I enable the mux after booting the BMC to interactive console, the ftgmac100 driver doesn't seem to probe NC-SI correctly.

To reproduce:

1. Boot Zaius board to login prompt
2. gpioutil -p P0 -d out -v 0 to assert RMII_SW_EN_N. RMII_SW1_SEL_N and RMII_SW2_SEL_N are pulled low by the BMC, so this selects the BCM5719 LOM for NC-SI.
3. ifconfig eth0 up

in ifconfig, eth0 never shows any RX packets. I've tested NC-SI to work if I add static GPIO hogs to the device tree, however:

diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
index d1efe6e6e57e..2cd4effbb05c 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
@@ -285,6 +285,20 @@
 };

 &gpio {
+       rmii_sw1_sel_n {
+               gpio-hog;
+               gpios = <ASPEED_GPIO(A, 0) GPIO_ACTIVE_HIGH>;
+               output-low;
+               line-name = "rmii_sw1_sel_n";
+       };
+
+       rmii_sw2_sel_n {
+               gpio-hog;
+               gpios = <ASPEED_GPIO(A, 2) GPIO_ACTIVE_HIGH>;
+               output-low;
+               line-name = "rmii_sw2_sel_n";
+       };
+
        line_iso_u146_en {
                gpio-hog;
                gpios = <ASPEED_GPIO(O, 4) GPIO_ACTIVE_HIGH>;
@@ -292,6 +306,13 @@
                line-name = "iso_u164_en";
        };

+       ncsi_mux_en_n {
+               gpio-hog;
+               gpios = <ASPEED_GPIO(P, 0) GPIO_ACTIVE_HIGH>;
+               output-low;
+               line-name = "ncsi_mux_en_n";
+       };
+
        line_bmc_i2c2_sw_rst_n {
                gpio-hog;
                gpios = <ASPEED_GPIO(P, 1) GPIO_ACTIVE_HIGH>;

This seems like a driver issue.

[vishwabmc]

@amboar , Is that something you could help with ?

[williamspatrick]

@GHF, @yuennancy - What is the expectation here? Is this something your team is just reporting but still investigating or is there an expectation that we are actively working on this issue?

[GHF]

I'm reporting the probing issue but I don't know the ftgmac100 driver well enough to suggest a solution.

[rlippert]

This quick patch to ftgmac100 driver atleast allows it to unbind / rebind from the device which seems to allow it to (re)establish a NC-SI connection after twiddling the mux GPIOs:

diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index f40fa92cd041..87db7fe44fc7 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -1446,7 +1446,7 @@ err_register_netdev:
 err_setup_mdio:
        iounmap(priv->base);
 err_ioremap:
-       release_resource(priv->res);
+       release_mem_region(priv->res->start, resource_size(priv->res));
 err_req_mem:
        netif_napi_del(&priv->napi);
        free_netdev(netdev);
@@ -1454,7 +1454,7 @@ err_alloc_etherdev:
        return err;
 }

-static int __exit ftgmac100_remove(struct platform_device *pdev)
+static int ftgmac100_remove(struct platform_device *pdev)
 {
        struct net_device *netdev;
        struct ftgmac100 *priv;
@@ -1462,11 +1462,14 @@ static int __exit ftgmac100_remove(struct platform_device *pdev)
        netdev = platform_get_drvdata(pdev);
        priv = netdev_priv(netdev);

+       if (priv->use_ncsi)
+               ncsi_unregister_dev(priv->ndev);
+
        unregister_netdev(netdev);
        ftgmac100_destroy_mdio(netdev);

        iounmap(priv->base);
-       release_resource(priv->res);
+       release_mem_region(priv->res->start, resource_size(priv->res));

        netif_napi_del(&priv->napi);
        free_netdev(netdev);
@@ -1481,7 +1484,7 @@ MODULE_DEVICE_TABLE(of, ftgmac100_of_match);

 static struct platform_driver ftgmac100_driver = {
        .probe  = ftgmac100_probe,
-       .remove = __exit_p(ftgmac100_remove),
+       .remove = ftgmac100_remove,
        .driver = {
                .name           = DRV_NAME,
                .of_match_table = ftgmac100_of_match,

[gtmills]

@GHF @yuennancy Still a problem or can this be closed?

[rlippert]

Possibly obsolete, or atleast no longer needed for our purposes as we have just hardcoded the mux selection in the devtree.

[gtmills]

Closing based on above comment.