Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4927831ybc; Fri, 15 Nov 2019 12:13:24 -0800 (PST) X-Google-Smtp-Source: APXvYqxBSWSooRKxmD1IoO5Lc/CSSQd9u/db9gVVvIuQ1oWxSSx461B+Cu0mHBqaT6EaHT+HyKu7 X-Received: by 2002:a17:906:4cd2:: with SMTP id q18mr3321053ejt.319.1573848804126; Fri, 15 Nov 2019 12:13:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573848804; cv=none; d=google.com; s=arc-20160816; b=dzwjO0UK7IENqUSSLdfVQl+PFqDPD4UcA5lTTVixRDfjmvZKea/d/8ZZ5lm/LEi62+ reuMq5cuqyDLS4EoQdKpWQBdwuiwbkZiNOspJjUQdOyXXAUn3nEj4LNgq/2CDE4bdt1z VlH0YfF30SJgZx7hZkKOy6uhn7NdAUvtW5Y8qHiNml6dic29hXLZjvA05O/L3KyRSyiQ K1RsnG4cMDz+uHkeJ6kz4RBb8gN3mfGwN2QrjWb/X3NVMxxd5DqAnhb3TSKBY45qkAMD i5B/szasUtjxrun/k9qPniAyjTZbCJMdxsd5qv5dqTeRFQMq4l1tE3KAP7+LUJiwt93C V2gA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=wrnxUibPBLHnT2cN+WAOfRuRK+OiFhAk9koYlDustYg=; b=SRacwqPx8Ly6V9zBpj8X57itIUQSiZfVdbbHRfrUHxrxKKehOZVhjYM7wq24G5qxWn iirubjagoHXfMBLyUO4deNUIyXBEggH0AxaLSmUmXRsE56DUbb2bQfcbl6GiHAZKCGmL tAweLo24plJLne364sHQPnpHs313RWT1JJau1EYFkEkufEd5hP4hSXRFtAUGFXWTusk3 E5383KdsMIAJTNfUPu8hWgoN7TZSpUm1Q27S0qSfZjvLrW2Wm0h7xkuMYvV4jcw4jF29 8UIywVgGB9CnNUMW6cDQ2ezP1nN0+DgO3kDJwsnt1J8IviD1FKzapy6ctcwxGLpyFaQC 0jxQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id gu26si6210363ejb.228.2019.11.15.12.12.19; Fri, 15 Nov 2019 12:13:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726952AbfKOUKy (ORCPT + 99 others); Fri, 15 Nov 2019 15:10:54 -0500 Received: from shards.monkeyblade.net ([23.128.96.9]:40426 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726323AbfKOUKy (ORCPT ); Fri, 15 Nov 2019 15:10:54 -0500 Received: from localhost (unknown [IPv6:2601:601:9f00:1e2::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 6F33014E0BEC2; Fri, 15 Nov 2019 12:10:53 -0800 (PST) Date: Fri, 15 Nov 2019 12:10:50 -0800 (PST) Message-Id: <20191115.121050.591805779332799354.davem@davemloft.net> To: hslester96@gmail.com Cc: fugang.duan@nxp.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net v2] net: fec: add a check for CONFIG_PM to avoid clock count mis-match From: David Miller In-Reply-To: <20191112112830.27561-1-hslester96@gmail.com> References: <20191112112830.27561-1-hslester96@gmail.com> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 15 Nov 2019 12:10:53 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Chuhong Yuan Date: Tue, 12 Nov 2019 19:28:30 +0800 > If CONFIG_PM is enabled, runtime pm will work and call runtime_suspend > automatically to disable clks. > Therefore, remove only needs to disable clks when CONFIG_PM is disabled. > Add this check to avoid clock count mis-match caused by double-disable. > > Fixes: c43eab3eddb4 ("net: fec: add missed clk_disable_unprepare in remove") > Signed-off-by: Chuhong Yuan Your explanation in your reply to my feedback still doesn't explain the situation to me. For every clock enable done during probe, there must be a matching clock disable during remove. Period. There is no CONFIG_PM guarding the clock enables during probe in this driver, therefore there should be no reason to require CONFIG_PM guards to the clock disables during the remove method, You have to explain clearly, and in detail, why my logic and analysis of this situation is not correct. And when you do so, you will need to add those important details to the commit message of this change and submit a v3. Thank you.