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
| ||
|
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