From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 37ABDE784B3 for ; Mon, 2 Oct 2023 13:55:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qXTi34VBYcW8XrqCje/bqu2uwH4wA1LdS4/ewUgwGGs=; b=1XhsznLgEy5lps W8hrkuPEga+xUemN1NUQDfMYh3kYSdIgm6v7vhd3NZnej9fJs4F/7y/fUhCgIdiqFLY6X/Mlvz9tz LdZKUAv1/s/w+ly9PWPaJyyg3OlS3Qx5EOdhNZbKh/E733gPz2fZd/9BkB2rqW3ny0WSGxVBWCtmE YVz7wButv6pVo2bYvHbtGqjkT3i2hJFGAe0ZYE1RMm0DBbsONc9fR2So/3R36Ty4SrTTlsovvBykO 3efVXke2mEMWYMoy5Hsv1pBrUYy9Pz8KSC9bVQuQbpXdyj8Ou4hSbMMw2wUfcIt74oZ0mGVAMJur2 VNG1bzCL2JrYZZG0lvkA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qnJNp-00Cp4R-3C; Mon, 02 Oct 2023 13:54:50 +0000 Received: from mail-qk1-x743.google.com ([2607:f8b0:4864:20::743]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qnJNm-00Cp3t-2q for linux-arm-kernel@lists.infradead.org; Mon, 02 Oct 2023 13:54:48 +0000 Received: by mail-qk1-x743.google.com with SMTP id af79cd13be357-7742be66bd3so876831285a.3 for ; Mon, 02 Oct 2023 06:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hefring-com.20230601.gappssmtp.com; s=20230601; t=1696254885; x=1696859685; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=STxM7vkkmDyUmxUH+gQAbgTWzPPiXJaAVUcK/e9j1i4=; b=cAhz0pvoAcmgK/rI40rFdT9yOI8zsYtQvReziusg9Ujq8MYtlNvVFAMD9o3hkBxrJT TEERjWOJNg3RV92gTK/3yioVF9n70q4HKakmSyneLkpJbGSM+UoBUP8uL0ejIFzUNGWm Os9JY6WXDXkb5axkkRjyTJeJDJqADglgRm34cSR6cWz1NvZdz2nfZ1jXmqOjPse67cnR Vb7F9Y+MXldJkEbotYkVSWP8nF1YO87m2v/mM6zqERyRpFo18dNaQGSKGpMaIBdVstYT Fk5hbtkkpX6g2F6Pb5wfincQU4ca9tFo/HmNIzd6gbz9FvlXk8nl3dmDrd7JLSpsb0ZU GXwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696254885; x=1696859685; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=STxM7vkkmDyUmxUH+gQAbgTWzPPiXJaAVUcK/e9j1i4=; b=XbwR8oCJaeryxjpMKQdSvTxOOMEcMDxPhkgMPuANxyzKGHk5DShIqLRoPuZvH4fbgA sqVuU0lSpzSrRnriABbYbZYlx8IWRqkNuNDSprgtgRy+dIKICh9MOPP0ZCWvumaS/uIp sxGYvmAdAkInoPxKeh6E4bwRaEibTf34Pja4zqZhNsWw+oZRTXTU7v3RvLYMDVJEH5Xy qSedHJTCaaT/1GV1m1/e0sxHmx8I9BL8VVEn1LJSBxTMY4v6NB7/l7s+2MnJjUAd5X5r wTfyH0uJ0DRgSM87G/4GNcGPxEoHKKGMm35YeOTUKBGE4F2b+tK1f66o2NGYIg26JI1r oW3w== X-Gm-Message-State: AOJu0YzcujJagkyg8gIL4Ao5DtHJCOK8CRuHvKNCUhA3rxusrIOJOQE1 zDNxPLC1IympZkJPbB9cia3hJw== X-Google-Smtp-Source: AGHT+IEs4NNprUgXOj7mVjG0S6MI/X0bgLI21KGJ4S6Xc/WbrCRFCrApaXSxBK8zWzz0pDpmlfRmAA== X-Received: by 2002:a05:620a:12f1:b0:774:13e:71cd with SMTP id f17-20020a05620a12f100b00774013e71cdmr10622494qkl.56.1696254884697; Mon, 02 Oct 2023 06:54:44 -0700 (PDT) Received: from dell-precision-5540 ([50.212.55.89]) by smtp.gmail.com with ESMTPSA id h8-20020ae9ec08000000b0076e672f535asm8922296qkg.57.2023.10.02.06.54.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 06:54:44 -0700 (PDT) Date: Mon, 2 Oct 2023 09:54:34 -0400 From: Ben Wolsieffer To: Jacob Keller Cc: linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Alexandre Torgue , Jose Abreu , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Christophe Roullier Subject: Re: [PATCH net] net: stmmac: dwmac-stm32: fix resume on STM32 MCU Message-ID: References: <20230927175749.1419774-1-ben.wolsieffer@hefring.com> <681cc4ca-9fd7-9436-6c7d-d7da95026ce3@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <681cc4ca-9fd7-9436-6c7d-d7da95026ce3@intel.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231002_065447_137612_0BE4422C X-CRM114-Status: GOOD ( 29.78 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Jacob, On Fri, Sep 29, 2023 at 10:48:47AM -0700, Jacob Keller wrote: > > > 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? Ideally, you want to turn off as many clocks as possible in suspend to save power. I'm assuming there is some hardware reason the STM32MP1 needs the RX clock on during suspend, but it was not explained in the original patch. Without more information, I'm trying to maintain the existing behavior. > > > 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 > > --- > > 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. Sorry, I should have linked this when I re-posted this patch for net, but I previously submitted this patch as part of a series with the cleanup but was asked to split them up for net and net-next. Personally, I would be fine with them going into net-next together (or squashed). The original series can be found here: https://lore.kernel.org/linux-arm-kernel/20230919164535.128125-3-ben.wolsieffer@hefring.com/T/ Thanks, Ben _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel