Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3306216imw; Mon, 18 Jul 2022 05:59:14 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t5VV9QoaEnKNgokldBXZ51BFL/93c3qnR4L+7U1X4aA9F+C+zILEtuu75xisV3ifLif3vJ X-Received: by 2002:a4a:e82b:0:b0:330:cee9:4a8a with SMTP id d11-20020a4ae82b000000b00330cee94a8amr9305951ood.31.1658149154170; Mon, 18 Jul 2022 05:59:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658149154; cv=none; d=google.com; s=arc-20160816; b=dTD7Nos7QzwEU3aS5GgVhFm0uMhjaYNfmBN/YafJOzuiKTWMo17oOMv6lWwEOk32Pk KEAZFe9rHYo4vkt6JyS97Ppfgqm3u+QBtm1Is8VcB/+JBpfQjn89+pv/SGRdmF05cJzh dRd5T76AQ0V455h6JGQMggUI02y4w+wDmgdAGyUcx9g2YDE57Nwrxc4D1XzXGrq9PXBn e4kiaAEtNjvSMbjU4Nye80+ZlkHWpmrw54BixWbGHoS2W/7VWvqlgooyQh4Ql0JWe4L+ FtFWnk62FoQ182GYPFqyYfqPf3ljCy+bPnYArV+fBzjQKeq61i38IL1lZzQjrFuJA7yr CmrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=bR440eyPDRrDeDZhkiifRZfSU8Lw0pD8TYpzCnpuvHE=; b=vnVWJs3tiSEyHgnLdMoQ2OrBMMW3AcapLwcqwGjJmdhCsbtkfPgRZQWtRZJAlgYmMr 1GU/Rb4e2fiREVSM3RhdTRueGUyVUueHiUHQf1XYFCRIg3KuBThp30jRJhbKAH+Pmpix NTu8qDgV0z2ElI8qZpRiUf05RdBkRV9PP3p1rVg2op0ExTvgg0NNajuvHQ6hc/26k6Cy wHDoKolStzDneglzGvJ6itQgQL9NYRT+ppiqYLyYdrBhTyrCw71psGzoBAzar+QS97u/ zfq/xVuojdpf4LLE/SktJjtwZ7VcPcyuZ1ouHkFzEEffzjJKd8/2tBJipUe3Nrc8jeAz JqEQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 5-20020aca0b05000000b0033a7968c394si2311810oil.224.2022.07.18.05.59.00; Mon, 18 Jul 2022 05:59:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234186AbiGRM00 (ORCPT + 99 others); Mon, 18 Jul 2022 08:26:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233407AbiGRM0Z (ORCPT ); Mon, 18 Jul 2022 08:26:25 -0400 Received: from SHSQR01.spreadtrum.com (mx1.unisoc.com [222.66.158.135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3FEF222 for ; Mon, 18 Jul 2022 05:26:23 -0700 (PDT) Received: from SHSend.spreadtrum.com (bjmbx01.spreadtrum.com [10.0.64.7]) by SHSQR01.spreadtrum.com with ESMTPS id 26ICORKL076857 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 18 Jul 2022 20:24:27 +0800 (CST) (envelope-from Di.Shen@unisoc.com) Received: from bj10906pcu1.spreadtrum.com (10.0.74.51) by BJMBX01.spreadtrum.com (10.0.64.7) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Mon, 18 Jul 2022 20:24:28 +0800 From: Di Shen To: , , CC: , , , , , , , Subject: [PATCH] thermal: cpufreq_cooling: Avoid all cluster using global cooling_ops Date: Mon, 18 Jul 2022 20:24:19 +0800 Message-ID: <20220718122419.9409-1-di.shen@unisoc.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.0.74.51] X-ClientProxiedBy: SHCAS01.spreadtrum.com (10.0.1.201) To BJMBX01.spreadtrum.com (10.0.64.7) X-MAIL: SHSQR01.spreadtrum.com 26ICORKL076857 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Now, all the cooling device use the globle cpufreq_cooling_ops. When the CONFIG_THERMAL_GOV_POWER_ALLOCATOR is enabled, once one cluster init the cpufreq_cooling_ops, it would make all cooling device use the power allocator's ops. If one's em is error because of the "em_is_sane", it would cause the em NULL, but the cooling device's ops is exist, as a result, it would cause panic because of the em. Add cpufreq_power_cooling_ops to avoid this case. Signed-off-by: Di Shen Signed-off-by: Xuewen Yan --- drivers/thermal/cpufreq_cooling.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/thermal/cpufreq_cooling.c b/drivers/thermal/cpufreq_cooling.c index b8151d95a806..af5cfb458370 100644 --- a/drivers/thermal/cpufreq_cooling.c +++ b/drivers/thermal/cpufreq_cooling.c @@ -493,6 +493,17 @@ static struct thermal_cooling_device_ops cpufreq_cooling_ops = { .set_cur_state = cpufreq_set_cur_state, }; +#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR +static struct thermal_cooling_device_ops cpufreq_power_cooling_ops = { + .get_max_state = cpufreq_get_max_state, + .get_cur_state = cpufreq_get_cur_state, + .set_cur_state = cpufreq_set_cur_state, + .get_requested_power = cpufreq_get_requested_power, + .state2power = cpufreq_state2power, + .power2state = cpufreq_power2state, +}; +#endif + /** * __cpufreq_cooling_register - helper function to create cpufreq cooling device * @np: a valid struct device_node to the cooling device device tree node @@ -559,9 +570,7 @@ __cpufreq_cooling_register(struct device_node *np, #ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR if (em_is_sane(cpufreq_cdev, em)) { cpufreq_cdev->em = em; - cooling_ops->get_requested_power = cpufreq_get_requested_power; - cooling_ops->state2power = cpufreq_state2power; - cooling_ops->power2state = cpufreq_power2state; + cooling_ops = &cpufreq_power_cooling_ops; } else #endif if (policy->freq_table_sorted == CPUFREQ_TABLE_UNSORTED) { -- 2.17.1