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 281A3E81DE8 for ; Fri, 6 Oct 2023 11:48:47 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2R9LifEzAferOoWEqLWgqiH9gSbFOZ7k3+J4eyVfFDg=; b=jwO+3eOFM1EX4E wbGgqtO7Ecjo2VXF7CvrepCuDAb0a96Wzztai1p/va/6guOHzN8BAHf+pHK2bNxsbhgwzuU9zGaV5 OnHb4oScrHX81a8PcQRDujhgunarByBgHWRckvFFgtakJGARJAlu4jbCxUpRoKev+ZbiZtAmqA+NQ hnIfdIOGLfnpIi/cSnI/szAkj5E4T4QdT1ZSMB9f1N2aMFvm2v2T45U0Ff3whF5S7pEqcOtQ0MMub Vf8g/IGM2Pmrram1R4KN6rzVqJbq3DL+hV1BIq3yqvgvl7ygj79j2snxNQhnCsTqHiYhR3KgZkKD3 eVPwPR3wYBxI8tPIk3KA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qojJg-005iVp-34; Fri, 06 Oct 2023 11:48:24 +0000 Received: from mx07-00178001.pphosted.com ([185.132.182.106]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qojJe-005iUn-0l for linux-arm-kernel@lists.infradead.org; Fri, 06 Oct 2023 11:48:24 +0000 Received: from pps.filterd (m0288072.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.22/8.17.1.22) with ESMTP id 3965k6oa010374; Fri, 6 Oct 2023 13:47:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s= selector1; bh=7hUXSm4cUGROzEvTuYhVzV1bsIonYgdPmxDalGuj81U=; b=qt PvJLLDWgY5DKSI1hBa48qvYC54KaUafXbotwH1wYfiazDiLH8cO5DTg0xMQJxcKB AP8zc2noF7+c8K3GxJXp72WWTpKVX+fzBjUSthCGEryaQzmGdLgCw6uMMa9z6b6V OQjyD6T1Pjb8/QoUyVdhyBZTYy+K6gOQ6EPkSB5JIMAIlsveHtepF5nsE8Z+ghTt ZZcOnS0W1qGZvk5mwLIUxz4ls/xIA4ipVRfeCS1p3W/0gFZ6lnaRnJdfoCQEWHxe dFviJrbPhy48sR5G6t9sSZW6H/Ubr4wzBHHpqkXFQIlAlWw8i7uU7032XU5wW1K6 9G/CFE2XCTLzPWpJWVhQ== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3tj09gbe3d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Oct 2023 13:47:28 +0200 (MEST) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 54DA8100053; Fri, 6 Oct 2023 13:47:27 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node1.st.com [10.75.129.69]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 2071722A6EE; Fri, 6 Oct 2023 13:47:27 +0200 (CEST) Received: from [10.201.21.122] (10.201.21.122) by SHFDAG1NODE1.st.com (10.75.129.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Fri, 6 Oct 2023 13:47:26 +0200 Message-ID: Date: Fri, 6 Oct 2023 13:47:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH net] net: stmmac: dwmac-stm32: fix resume on STM32 MCU To: Ben Wolsieffer , Jacob Keller CC: , , , , Jose Abreu , "David S. Miller" , Eric Dumazet , "Jakub Kicinski" , Paolo Abeni , Maxime Coquelin , Christophe Roullier References: <20230927175749.1419774-1-ben.wolsieffer@hefring.com> <681cc4ca-9fd7-9436-6c7d-d7da95026ce3@intel.com> Content-Language: en-US From: Alexandre TORGUE In-Reply-To: X-Originating-IP: [10.201.21.122] X-ClientProxiedBy: EQNCAS1NODE3.st.com (10.75.129.80) To SHFDAG1NODE1.st.com (10.75.129.69) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-06_09,2023-10-06_01,2023-05-22_02 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231006_044822_917773_0BFB7831 X-CRM114-Status: GOOD ( 26.95 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 10/2/23 15:54, Ben Wolsieffer wrote: > 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. > Sorry for this late answer. We could need RX clock for WOL support. >> >>> 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