Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220323033255.2282930-1-bjorn.andersson@linaro.org>
In-Reply-To: <20220323033255.2282930-1-bjorn.andersson@linaro.org>
From:   Bhupesh Sharma <bhupesh.sharma@linaro.org>
Date:   Thu, 24 Mar 2022 15:08:08 +0530
Message-ID: <CAH=2NtyChidtrBVBL=RNjPaYYmtTuN0N4fbMx4DRBD6hXxHguQ@mail.gmail.com>
Subject: Re: [PATCH] net: stmmac: dwmac-qcom-ethqos: Enable RGMII functional
 clock on resume
To:     Bjorn Andersson <bjorn.andersson@linaro.org>
Cc:     Vinod Koul <vkoul@kernel.org>,
        Giuseppe Cavallaro <peppe.cavallaro@st.com>,
        Alexandre Torgue <alexandre.torgue@foss.st.com>,
        Jose Abreu <joabreu@synopsys.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Maxime Coquelin <mcoquelin.stm32@gmail.com>,
        netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
        linux-arm-kernel@lists.infradead.org,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        stable <stable@vger.kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

+Cc: stable tree as I think this is an important fix for stmmac
dwmac-qcom-ethernet driver and affects ethernet functionality on QCOM
boards which use this driver.

More below..

On Wed, 23 Mar 2022 at 09:01, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> When the Qualcomm ethqos driver is properly described in its associated
> GDSC power-domain, the hardware will be powered down and loose its state
> between qcom_ethqos_probe() and stmmac_init_dma_engine().
>
> The result of this is that the functional clock from the RGMII IO macro
> is no longer provides and the DMA software reset in dwmac4_dma_reset()
> will time out, due to lacking clock signal.
>
> Re-enable the functional clock, as part of the Qualcomm specific clock
> enablement sequence to avoid this problem.
>
> The final clock configuration will be adjusted by ethqos_fix_mac_speed()
> once the link is being brought up.
>
> Fixes: a7c30e62d4b8 ("net: stmmac: Add driver for Qualcomm ethqos")
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>  drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index 0cc28c79cc61..835caa15d55f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -487,6 +487,13 @@ static int ethqos_clks_config(void *priv, bool enabled)
>                         dev_err(&ethqos->pdev->dev, "rgmii_clk enable failed\n");
>                         return ret;
>                 }
> +
> +               /* Enable functional clock to prevent DMA reset to timeout due
> +                * to lacking PHY clock after the hardware block has been power
> +                * cycled. The actual configuration will be adjusted once
> +                * ethqos_fix_mac_speed() is invoked.
> +                */
> +               ethqos_set_func_clk_en(ethqos);
>         } else {
>                 clk_disable_unprepare(ethqos->rgmii_clk);
>         }
> --
> 2.33.1

Thanks for the catch, Bjorn. I tested this on the SA8155p-ADP board
and the eth interface can be moved from 'on' to 'off' state and
vice-versa properly after this change and we no longer need the EMAC
GDSC quirk, so:

Tested-and-Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>

Regards.