netdev - Re: [PATCH net] net: stmmac: dwmac-stm32: fix resume on STM32 MCU

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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[] = {