lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 24 Mar 2022 15:08:08 +0530 From: Bhupesh Sharma <bhupesh.sharma@...aro.org> To: Bjorn Andersson <bjorn.andersson@...aro.org> Cc: Vinod Koul <vkoul@...nel.org>, Giuseppe Cavallaro <peppe.cavallaro@...com>, Alexandre Torgue <alexandre.torgue@...s.st.com>, Jose Abreu <joabreu@...opsys.com>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Maxime Coquelin <mcoquelin.stm32@...il.com>, netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com, linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org, stable <stable@...r.kernel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org> Subject: Re: [PATCH] net: stmmac: dwmac-qcom-ethqos: Enable RGMII functional clock on resume +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@...aro.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@...aro.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(ðqos->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@...aro.org> Regards.
Powered by blists - more mailing lists