Received: by 10.223.176.5 with SMTP id f5csp2077240wra; Sun, 4 Feb 2018 20:04:27 -0800 (PST) X-Google-Smtp-Source: AH8x226v3w6ZV4S8vpIpx/OmWrZwZiOYfWXLyVit8fNHfjc7tXalLwddfk3+r88kYz35zplLHMqD X-Received: by 10.99.191.15 with SMTP id v15mr6069286pgf.216.1517803467412; Sun, 04 Feb 2018 20:04:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517803467; cv=none; d=google.com; s=arc-20160816; b=Z2s3AVl/rW6QTD/jNsmEpAoYMoJC5/14FjrRMl/uPFWLyg9klJ0qKOUyuVXLBSdZYR i/Cr/1w8RKZXop9VFbfCD09VRqBtPV9wADT7icjmilfK5L2dUVcitVptna+6f8poCr8q F/jf9mhhwIjjyX1kQZnkmeDeY6EimtxQBvklujxGgwDfoVplijIcGvt/6jFIbrJz4jVr df8upq7MgQztOuyXQW5D3Xj/Ooken3S0N1jpSUDs926tT+2zp8hYs6ByLj39egMG9UTx 4VDWsE8VhB+hBhdfbmoffvOOf3Hbzu9hdukN7SFJ0ziRj/RgOzBnmyCEDAYcdCiMAGVm EG0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=u636R6J+EXPzXX9cNEEPsR27WUnLDKa+zpF65eThP6o=; b=oggs90kjdK6PQV22e02fllb9PxFVg9b5G2FThuHcJUynjFIy1aIlInc8UIzjW4lRZp xVf6Q7SGSgjeBmke9hFfoZQ1cOzlCeBCgQZ7SiG/DfEM0NK/TZLbJp7Whj/tvQ2kI7oK I7HbmAA7Xuoj/gD8tBfjmva7dJXoBcavZay3KCBiirTgvoMKnbtz1xlUw1FpIkJNnb1q xjA8I4dy48ihi8JzjlkgcGctFdmbpwz0kBhYxHSppEq9nlazpdr38az2JyzJgCrJHNsF DeWAaLNtI3v7CAKvnhHzBwE4rWB5lVjAfr2KY9OooJINw6je21/DvvhXYgJFi58yYLr4 Dzbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=VZ0NLnwX; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g6-v6si6311999plp.731.2018.02.04.20.04.11; Sun, 04 Feb 2018 20:04:27 -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; dkim=pass header.i=@linaro.org header.s=google header.b=VZ0NLnwX; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752312AbeBEEBa (ORCPT + 99 others); Sun, 4 Feb 2018 23:01:30 -0500 Received: from mail-pl0-f65.google.com ([209.85.160.65]:44939 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752166AbeBEEBW (ORCPT ); Sun, 4 Feb 2018 23:01:22 -0500 Received: by mail-pl0-f65.google.com with SMTP id f8so10938066plk.11 for ; Sun, 04 Feb 2018 20:01:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=u636R6J+EXPzXX9cNEEPsR27WUnLDKa+zpF65eThP6o=; b=VZ0NLnwXk/MG65W7aF4rJER6VobIb031rjGkd4Y0GjP9anY3M65g07vmxytk9hj5qf N7zhwywP0XFcXaoQs/yvt5i1bO64eIVySd3jPwq7KDy/nhIB5DnTIZQU21NEGRD+Okik uSaDAQeq2jjY6DfJeglIbVE/mcSY8ad5GFFSY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=u636R6J+EXPzXX9cNEEPsR27WUnLDKa+zpF65eThP6o=; b=sX0w9CmByVfgbAB6IIbNo5ol0/EHJI1T2kKcO597ZPoQAlwnA2xFarT64JDlFOaqxP QQ6TZkX2bpDo91j6mvh4WZlb9ijycarmwslZlju+Dkf6+eso9vi8YRRn5dWfenzdJOni VFHTe831IKib8FJMkb4xwLxxIQ6V1VEfOmphZjAVpY09+Oh2oh30HZ8w0snbONPYxk7+ qYaREEaRE4aly73btu3q1yt3/WsCAIcXcFW/koGOMl6Mju0h5Z0Cx7qgpgW1p1E8zhn8 6e6nsdtvESRXbPJ+8Vx4exQdasj+hjzDaNVv0X/Xf2p90fHnedJSI3+RKol38syjhmRo Cfgg== X-Gm-Message-State: AKwxytc79A/mC3xuYJCu6+8zVDjEhIh3jovH10cVuTGyTJH1vKQOPV9Z SfWqWb7Gkrl86UkApvGNWadgDA== X-Received: by 2002:a17:902:8ec4:: with SMTP id x4-v6mr13382259plo.271.1517803282209; Sun, 04 Feb 2018 20:01:22 -0800 (PST) Received: from localhost ([122.172.61.199]) by smtp.gmail.com with ESMTPSA id k3sm4301415pgr.12.2018.02.04.20.01.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2018 20:01:20 -0800 (PST) Date: Mon, 5 Feb 2018 09:31:18 +0530 From: Viresh Kumar To: Bo Yan Cc: Saravana Kannan , "Rafael J. Wysocki" , sgurrappadi@nvidia.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] cpufreq: skip cpufreq resume if it's not suspended Message-ID: <20180205040118.GB28462@vireshk-i7> References: <1516744675-21233-1-git-send-email-byan@nvidia.com> <1744712.rO4QOLozun@aspire.rjw.lan> <913f1715-bdd0-1c03-ad76-38be9d3d2298@nvidia.com> <17447147.z6jfkRxuEB@aspire.rjw.lan> <5A74BD55.5000402@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02-02-18, 13:28, Bo Yan wrote: > On 02/02/2018 11:34 AM, Saravana Kannan wrote: > >I rather have this fixed in the dpm_suspend/resume() code. This is just > >masking the first issue that's being caused by unbalanced error handling. > >If that means adding flags in dpm_suspend/resume() then that's what we > >should do right now and clean it up later if it can be improved. Making > >cpufreq more messy doesn't seem like the right answer. +1 > dpm_suspend and dpm_resume by themselves are not balanced in this particular > case. As it's currently structured, dpm_resume can't be omitted even if > dpm_suspend is skipped due to earlier failure.? I think checking > cpufreq_suspended flag is a reasonable compromise. If we can find a way to > make dpm_suspend/dpm_resume also balanced, that will be best. I think cpufreq is just one of the users which broke. Others didn't break because: - They don't have a complicated resume part. - Or we just don't know that they broke. Resuming something that never suspended is just broken by design. Yeah, its much simpler in this particular case to fix cpufreq core but the suspend/resume/hibernation part is really core kernel and should be fixed to avoid such band-aids. -- viresh