[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <681cc4ca-9fd7-9436-6c7d-d7da95026ce3@intel.com>
Date: Fri, 29 Sep 2023 10:48:47 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Ben Wolsieffer <ben.wolsieffer@...ring.com>,
<linux-stm32@...md-mailman.stormreply.com>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>
CC: Alexandre Torgue <alexandre.torgue@...s.st.com>,
Jose Abreu <joabreu@...opsys.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
"Christophe Roullier" <christophe.roullier@...com>
Subject: Re: [PATCH net] net: stmmac: dwmac-stm32: fix resume on STM32 MCU
On 9/27/2023 10:57 AM, Ben Wolsieffer wrote:
> The STM32MP1 keeps clk_rx enabled during suspend, and therefore the
> driver does not enable the clock in stm32_dwmac_init() if the device was
> suspended. The problem is that this same code runs on STM32 MCUs, which
> do disable clk_rx during suspend, causing the clock to never be
> re-enabled on resume.
>
> This patch adds a variant flag to indicate that clk_rx remains enabled
> during suspend, and uses this to decide whether to enable the clock in
> stm32_dwmac_init() if the device was suspended.
>
Why not just keep clk_rx enabled unconditionally or unconditionally stop
it during suspend? I guess that might be part of a larger cleanup and
has more side effects?
> This approach fixes this specific bug with limited opportunity for
> unintended side-effects, but I have a follow up patch that will refactor
> the clock configuration and hopefully make it less error prone.
>
I'd guess the follow-up refactor would target next?
> Fixes: 6528e02cc9ff ("net: ethernet: stmmac: add adaptation for stm32mp157c.")
> Signed-off-by: Ben Wolsieffer <ben.wolsieffer@...ring.com>
> ---
This seems pretty small and targeted so it does make sense to me as a
net fix, but it definitely feels like a workaround.
I look forward to reading the cleanup patch mentioned.
Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>
> drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
> index bdb4de59a672..28c8ca5fba6c 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
> @@ -105,6 +105,7 @@ struct stm32_ops {
> int (*parse_data)(struct stm32_dwmac *dwmac,
> struct device *dev);
> u32 syscfg_eth_mask;
> + bool clk_rx_enable_in_suspend;
> };
>
> static int stm32_dwmac_init(struct plat_stmmacenet_data *plat_dat)
> @@ -122,7 +123,8 @@ static int stm32_dwmac_init(struct plat_stmmacenet_data *plat_dat)
> if (ret)
> return ret;
>
> - if (!dwmac->dev->power.is_suspended) {
> + if (!dwmac->ops->clk_rx_enable_in_suspend ||
> + !dwmac->dev->power.is_suspended) {
> ret = clk_prepare_enable(dwmac->clk_rx);
> if (ret) {
> clk_disable_unprepare(dwmac->clk_tx);
> @@ -514,7 +516,8 @@ static struct stm32_ops stm32mp1_dwmac_data = {
> .suspend = stm32mp1_suspend,
> .resume = stm32mp1_resume,
> .parse_data = stm32mp1_parse_data,
> - .syscfg_eth_mask = SYSCFG_MP1_ETH_MASK
> + .syscfg_eth_mask = SYSCFG_MP1_ETH_MASK,
> + .clk_rx_enable_in_suspend = true
> };
>
> static const struct of_device_id stm32_dwmac_match[] = {
Powered by blists - more mailing lists