Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5752658pxj; Wed, 23 Jun 2021 08:15:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0G4TpRf93sSXOVvpW4tZxZ9yiQ/eziYtrrLbeN4X4MHzxP+XJWNaq8aZ3tLCkhhc95DYJ X-Received: by 2002:a6b:8f4b:: with SMTP id r72mr16123iod.183.1624461322331; Wed, 23 Jun 2021 08:15:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624461322; cv=none; d=google.com; s=arc-20160816; b=V6e32/YQgx6urKfH43yfmOYv0aW6XnhSEB9vm6Y0MozB8KRP0eNQwXUsbTrASC2qgh YRYSdCChOYsXtqf+mnDjG/dXp2Rs6ao1gRVTSONohaWQwoMor9qlI2IW1lxECaKA22Y7 9sNhio9GHy9SFXFIHXRxqYMX4pipqTrw89LsgQ94ufMefDyA3NZp3k1oFxb0WK2cHZjb EwkdiikEyoz+wIsuQ7BzG9njPUW3olVlA7K9dlG7tHy7NapU6QT4wxhLccvZN9n8mwOj wME+GavOBGCQJSNZFhJ/+VxioH9KIELNfBulu/TEHJzHvFnT2B5v6/Vm4Nue5vV3xrF6 CZEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=U3+9F5vVoaG5H4p3nlFqOOvXGqMwE0EpBxejnIAM/ws=; b=Bl3yc8p+HQXP/98JPGgATlb+uOJK9zn7frd/uoXyokOHBx4eaWm7OgCC0c1tt/y1Lw c94LJ9H/cxS+P/MdsOzWeiNfQ+bSQVPcD/H0cOCsw7HX6JxQiY/7rHZ5HEC0snaTW5iY lS0jU6hHooa2+odAqyBp+rY40zz/2K5AvZcoUTffBtGQEMxtSIcC+zbK4J0550efriU5 EuPZNFXFO8qRrfjKnm1uMsg6F6X1tdev/EVx38DYH/WBKZbsVuYgBS0OSpgVeF7IxTXf PzpIYyn/ISroVywSSqNtW7oMkYMVtwVXVliEEGcdI2w3TQnnflYVit6LYh46zqo/DFaH 1OOw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k24si274210jan.49.2021.06.23.08.15.09; Wed, 23 Jun 2021 08:15:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231379AbhFWPPV (ORCPT + 99 others); Wed, 23 Jun 2021 11:15:21 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:48620 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231364AbhFWPPV (ORCPT ); Wed, 23 Jun 2021 11:15:21 -0400 Received: from localhost (127.0.0.1) (HELO v370.home.net.pl) by /usr/run/smtp (/usr/run/postfix/private/idea_relay_lmtp) via UNIX with SMTP (IdeaSmtpServer 2.1.0) id 79ccbd21b1696034; Wed, 23 Jun 2021 17:13:02 +0200 Received: from kreacher.localnet (89-64-80-57.dynamic.chello.pl [89.64.80.57]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by v370.home.net.pl (Postfix) with ESMTPSA id 52FB9669A62; Wed, 23 Jun 2021 17:13:01 +0200 (CEST) From: "Rafael J. Wysocki" To: Viresh Kumar Cc: Srinivas Pandruvada , Len Brown , linux-pm@vger.kernel.org, Vincent Guittot , linux-kernel@vger.kernel.org Subject: Re: [PATCH V4 2/4] cpufreq: intel_pstate: Migrate to ->offline() instead of ->stop_cpu() Date: Wed, 23 Jun 2021 17:13:00 +0200 Message-ID: <5741915.lOV4Wx5bFT@kreacher> In-Reply-To: <6144911f36d3d1f5faddf81d744bd39946843f6b.1624421816.git.viresh.kumar@linaro.org> References: <6144911f36d3d1f5faddf81d744bd39946843f6b.1624421816.git.viresh.kumar@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-CLIENT-IP: 89.64.80.57 X-CLIENT-HOSTNAME: 89-64-80-57.dynamic.chello.pl X-VADE-SPAMSTATE: clean X-VADE-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfeegfedgkeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecujffqoffgrffnpdggtffipffknecuuegrihhlohhuthemucduhedtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjghfggfgtgesthfuredttddtjeenucfhrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqeenucggtffrrghtthgvrhhnpeetgefgleetgeduheeugeeikeevudelueelvdeufeejfeffgeefjedugfetfeehhfenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecukfhppeekledrieegrdektddrheejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepkeelrdeigedrkedtrdehjedphhgvlhhopehkrhgvrggthhgvrhdrlhhotggrlhhnvghtpdhmrghilhhfrhhomhepfdftrghfrggvlhculfdrucghhihsohgtkhhifdcuoehrjhifsehrjhifhihsohgtkhhirdhnvghtqedprhgtphhtthhopehvihhrvghshhdrkhhumhgrrheslhhinhgrrhhordhorhhgpdhrtghpthhtohepshhrihhnihhvrghsrdhprghnughruhhvrggurgeslhhinhhugidrihhnthgvlhdrtghomhdprhgtphhtthhopehlvghnsgeskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqphhmsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtohep vhhinhgtvghnthdrghhuihhtthhotheslhhinhgrrhhordhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhg X-DCC--Metrics: v370.home.net.pl 1024; Body=6 Fuz1=6 Fuz2=6 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, June 23, 2021 6:24:40 AM CEST Viresh Kumar wrote: > commit 367dc4aa932b ("cpufreq: Add stop CPU callback to cpufreq_driver > interface") added the stop_cpu() callback to allow the drivers to do > clean up before the CPU is completely down and its state can't be > modified. > > At that time the CPU hotplug framework used to call the cpufreq core's > registered notifier for different events like CPU_DOWN_PREPARE and > CPU_POST_DEAD. The stop_cpu() callback was called during the > CPU_DOWN_PREPARE event. > > This is no longer the case, cpuhp_cpufreq_offline() is called only once > by the CPU hotplug core now and we don't really need to separately > call stop_cpu() for cpufreq drivers. > > Migrate to using the offline() callbacks instead of stop_cpu(). > > Cc: Dirk Brandewie > Signed-off-by: Viresh Kumar > --- > drivers/cpufreq/intel_pstate.c | 10 ++-------- > 1 file changed, 2 insertions(+), 8 deletions(-) > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > index 0e69dffd5a76..b4c0ff7f5b71 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -2335,6 +2335,8 @@ static int intel_pstate_cpu_offline(struct cpufreq_policy *policy) > > pr_debug("CPU %d going offline\n", cpu->cpu); > > + intel_pstate_clear_update_util_hook(policy->cpu); As mentioned already in https://lore.kernel.org/linux-pm/CAJZ5v0g2tCZptcqh+c55YYiO7rDHmZivMLsmpq_7005zNPN1xg@mail.gmail.com/ this isn't particularly clean, because intel_pstate_cpu_offline() is also used in the passive mode where the above call is not needed. I would make a change like in the patch below instead. > + > if (cpu->suspended) > return 0; --- From: Rafael J. Wysocki Subject: [PATCH] cpufreq: intel_pstate: Combine ->stop_cpu() and ->offline() Combine the ->stop_cpu() and ->offline() callback routines for the active mode of intel_pstate so as to avoid setting the ->stop_cpu callback pointer which is going to be dropped from the framework. Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/intel_pstate.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) Index: linux-pm/drivers/cpufreq/intel_pstate.c =================================================================== --- linux-pm.orig/drivers/cpufreq/intel_pstate.c +++ linux-pm/drivers/cpufreq/intel_pstate.c @@ -2577,11 +2577,13 @@ static int intel_pstate_cpu_online(struc return 0; } -static void intel_pstate_stop_cpu(struct cpufreq_policy *policy) +static int intel_pstate_stop_cpu(struct cpufreq_policy *policy) { pr_debug("CPU %d stopping\n", policy->cpu); intel_pstate_clear_update_util_hook(policy->cpu); + + return intel_pstate_cpu_offline(policy); } static int intel_pstate_cpu_exit(struct cpufreq_policy *policy) @@ -2654,8 +2656,7 @@ static struct cpufreq_driver intel_pstat .resume = intel_pstate_resume, .init = intel_pstate_cpu_init, .exit = intel_pstate_cpu_exit, - .stop_cpu = intel_pstate_stop_cpu, - .offline = intel_pstate_cpu_offline, + .offline = intel_pstate_stop_cpu, .online = intel_pstate_cpu_online, .update_limits = intel_pstate_update_limits, .name = "intel_pstate",