From nobody Tue Jun 23 02:20:37 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09498C433EF for ; Sun, 13 Mar 2022 05:55:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233648AbiCMF4m (ORCPT ); Sun, 13 Mar 2022 00:56:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232495AbiCMF4l (ORCPT ); Sun, 13 Mar 2022 00:56:41 -0500 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E78456754 for ; Sat, 12 Mar 2022 21:55:34 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id v1-20020a17090a088100b001bf25f97c6eso11637643pjc.0 for ; Sat, 12 Mar 2022 21:55:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=exfznBY+8JaiqjcDeRUubcAF4qIYlFp8JUbTCkFqZ5M=; b=MhMvtLvpQJWvNVTUIsimGCFiMnhO17PlQOSbHa1pVzGpCBXKJSO9eYMDQY99ENqKDO z8a0bTEav96SfAg9Xf+JdUs8Qkka9rU3toWCQwDrlPKkjVfSIlTE0MwRLn41dGG9/SWX SdpNcu6ogCgiwUxMDPZsNxacJSYUW5kNHb24Im+q2HbgOaE6XR6s+c/SaZYRExm8eO6+ VeVti0x8MhS/2jZYl90RuUs32iDHks9uJN/fLVRUmTVufw9H7dMyka+aLd/DvuPT3f3T qST4L48iIrP2owBmWbfj8DqP1UkcORLJ3DowTTqyygq3slmQJD281ZAt2f9ZeBqrCuoJ z4bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=exfznBY+8JaiqjcDeRUubcAF4qIYlFp8JUbTCkFqZ5M=; b=q5UVBlbBFH1SB2hgj72dvf3EOixoFXfyielm5Xt0myFjryGgwLeb34lij9tes36us2 Fwt+5Rm79h9zEi8ZsT9xCikaozqgAz2WCEMpIYkDIgwl4s7C2OeVh2EJxYFzwIhnpJ9O FK0CA28NXsNd4ekdlfU1LOvK8BDhn38CDGKRYISRd7wsqwoikuNm/tGpmDo2JzBM34Nz uGzps7HGL4ae8ROELEA99ih3IoHrWECTf51/dIcqyebPCrufT5ZZyTSQbLN+Bj0H+sgR kNbTtCOHo+j2dGx3IXZT7iuUSwln3q64cD/BbFOEOisM80TYcupuN/+d9silROgiF5Ex sMuA== X-Gm-Message-State: AOAM531n0mvHSKkt4Ro44NGHzl89MbCu8fUkw9BVvW9Ug3ypBVirkN/D a6uWUng7U71AhueVZZzkLJllB9qRuXzTzWHE X-Google-Smtp-Source: ABdhPJyOK+qFktZuiPxUZjxTeitrjLe/+UsVD0eU1EpOK6RKocPEjcoE0FAT8+CG23cjszCMULLz8A== X-Received: by 2002:a17:902:ce05:b0:14f:8cfa:1ace with SMTP id k5-20020a170902ce0500b0014f8cfa1acemr17779214plg.149.1647150933943; Sat, 12 Mar 2022 21:55:33 -0800 (PST) Received: from localhost.localdomain (104.225.159.237.16clouds.com. [104.225.159.237]) by smtp.gmail.com with ESMTPSA id m11-20020a056a00080b00b004f75d5f9b5csm14792447pfk.26.2022.03.12.21.55.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Mar 2022 21:55:33 -0800 (PST) From: Leo Yan To: Sudeep Holla , Greg Kroah-Hartman , "Rafael J. Wysocki" , Vincent Guittot , Bryan O'Donoghue , linux-kernel@vger.kernel.org Cc: Leo Yan Subject: [PATCH v1 1/3] arch_topology: Correct semantics for 'cap_parsing_failed' Date: Sun, 13 Mar 2022 13:55:10 +0800 Message-Id: <20220313055512.248571-2-leo.yan@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220313055512.248571-1-leo.yan@linaro.org> References: <20220313055512.248571-1-leo.yan@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" As described in the DT binding document [1]: "capacity-dmips-mhz property is all-or-nothing: if it is specified for a cpu node, it has to be specified for every other cpu nodes, or the system will fall back to the default capacity value for every CPU". In other words, we can accept that cases that "capacity-dmips-mhz" property is specified or not specified for all CPU nodes. The only failure is the DT binding is inconsistent for all CPUs nodes, e.g only part of CPUs have bound the "capacity-dmips-mhz" property. Currently kernel only considers all CPU nodes having "capacity-dmips-mhz" property as a parsing success; for the other two cases, one is all CPU nodes without "capacity-dmips-mhz" property, and another is inconsistent binding crossing CPU nodes, kernel considers them as parsing failure and set 'cap_parsing_failed' flag as true. This patch makes more clear for the semantics of 'cap_parsing_failed', it only takes the inconsistent binding case as parsing failure. So it sets the flag 'cap_parsing_failed' to true only when the array 'raw_capacity' is not NULL and current CPU node doesn't contain the property "capacity-dmips-mhz". It marks 'cap_parsing_failed' as a static global variable to allow it can be used in the source file. [1] Documentation/devicetree/bindings/arm/cpu-capacity.txt Signed-off-by: Leo Yan --- drivers/base/arch_topology.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index 976154140f0b..b81777ae6425 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -234,6 +234,7 @@ static int register_cpu_capacity_sysctl(void) subsys_initcall(register_cpu_capacity_sysctl); =20 static int update_topology; +static bool cap_parsing_failed; =20 int topology_update_cpu_topology(void) { @@ -291,7 +292,6 @@ void topology_normalize_cpu_scale(void) bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int = cpu) { struct clk *cpu_clk; - static bool cap_parsing_failed; int ret; u32 cpu_capacity; =20 @@ -331,9 +331,9 @@ bool __init topology_parse_cpu_capacity(struct device_n= ode *cpu_node, int cpu) pr_err("cpu_capacity: missing %pOF raw capacity\n", cpu_node); pr_err("cpu_capacity: partial information: fallback to 1024 for all CPU= s\n"); + cap_parsing_failed =3D true; + free_raw_capacity(); } - cap_parsing_failed =3D true; - free_raw_capacity(); } =20 return !ret; --=20 2.25.1 From nobody Tue Jun 23 02:20:37 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED6BDC433F5 for ; Sun, 13 Mar 2022 05:55:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233650AbiCMF4s (ORCPT ); Sun, 13 Mar 2022 00:56:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232495AbiCMF4o (ORCPT ); Sun, 13 Mar 2022 00:56:44 -0500 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7900E5C64F for ; Sat, 12 Mar 2022 21:55:37 -0800 (PST) Received: by mail-pj1-x1035.google.com with SMTP id v1-20020a17090a088100b001bf25f97c6eso11637701pjc.0 for ; Sat, 12 Mar 2022 21:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=RoUZCESpVak/+s5nDva9vIyHAPScWiyh0Htj7zHIWxk=; b=dbrQWgCvpao5bpKsgabNyuQl7n+KLu0erxIIC+VyQTMy5PYHC2x1tproIsCaoXdNjP enSAgXnHVsbuqwh8g3leH5yayk+IHu2TF/3JrAOO9EbcYd/tfy2l6FrVBY03X0n+/oez 5RMboM8nWN+bYjS9tQRd7rLcR4ZLClsVTNpgtmzL1cD8GnNc005YOSQUlbT7H09Qi75d cR+hItwwF9Vlg04pynhV1iowFCDIMQ7Gqjuzh6hedIkW6Nj695FwOLVdXzCe1D7LjOIs VchRnbZt5dtm0JnYD2uDoT+z0cWoHh5Uw6mpNyZqbhSWaJjjvpNR9YLKHGkl7CuxGiLl aumw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=RoUZCESpVak/+s5nDva9vIyHAPScWiyh0Htj7zHIWxk=; b=bSQUNl5IRlBbotEubzj31uNBe7wN/TK5pr/fQuwDl4haa1EtCdJgKCD+Mzpx+27zSy n0r52v+kINbR9xOtDywi1vFJmLZdUNS0G1fCBttAvZ+BE4d6DXOlovVDpd0E1EsJR5JT 96fzolHmemxFbgLiDqGUU3WW+bBpGZ25mo1OuAwa4OXWsvDCF5h/g462lzPtqzk+tULs oQG6ZagW4DRy9vbEyuNslXs5SVLzW71CxhMRRlXWEr412LayXStMym9iNkseq4X9O6/Y M9Yv583maNbMKlCizf90z4zQbyLscxOIkH0T/v30V0PdYkejXrsxk15iNJszBNIOm2NV pVcA== X-Gm-Message-State: AOAM532tw2UsCKgXvhF6IefjulIXQ8fHJnaMoLBONpgEKfcPJFbydS+o FJXemM0URed6GxZFDFuSr+YAmw== X-Google-Smtp-Source: ABdhPJyxMxe8oMdlaQF42Ft12F68YNmEg9/wp3cIe9ei2q/SPjhJh6S68VwX0tS32LdQLYkhxfqpLw== X-Received: by 2002:a17:902:c7c5:b0:153:3a41:aa45 with SMTP id r5-20020a170902c7c500b001533a41aa45mr9400958pla.88.1647150936905; Sat, 12 Mar 2022 21:55:36 -0800 (PST) Received: from localhost.localdomain (104.225.159.237.16clouds.com. [104.225.159.237]) by smtp.gmail.com with ESMTPSA id m11-20020a056a00080b00b004f75d5f9b5csm14792447pfk.26.2022.03.12.21.55.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Mar 2022 21:55:36 -0800 (PST) From: Leo Yan To: Sudeep Holla , Greg Kroah-Hartman , "Rafael J. Wysocki" , Vincent Guittot , Bryan O'Donoghue , linux-kernel@vger.kernel.org Cc: Leo Yan Subject: [PATCH v1 2/3] arch_topology: Handle inconsistent binding of CPU raw capacity Date: Sun, 13 Mar 2022 13:55:11 +0800 Message-Id: <20220313055512.248571-3-leo.yan@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220313055512.248571-1-leo.yan@linaro.org> References: <20220313055512.248571-1-leo.yan@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" There have a corner case is if we use below DT binding: cpu0: cpu@0 { compatible =3D "arm,cortex-a53"; device_type =3D "cpu"; reg =3D <0x0 0x0>; enable-method =3D "psci"; }; cpu1: cpu@1 { compatible =3D "arm,cortex-a53"; device_type =3D "cpu"; reg =3D <0x0 0x1>; enable-method =3D "psci"; capacity-dmips-mhz =3D <1024>; }; In this case, CPU0 node misses to bind "capacity-dmips-mhz" property, and CPU1 node binds the property, this means the CPU raw capacity binding is inconsistent across all CPUs. This patch introduces an extra flag 'cap_property_miss' to indicate that any previous CPU nodes miss binding for "capacity-dmips-mhz" property, and any new CPU node contains the property, it detects the inconsistent binding, and sets 'cap_parsing_failed' to true and frees raw capacity array. Signed-off-by: Leo Yan --- drivers/base/arch_topology.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index b81777ae6425..0687576e880b 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -294,6 +294,7 @@ bool __init topology_parse_cpu_capacity(struct device_n= ode *cpu_node, int cpu) struct clk *cpu_clk; int ret; u32 cpu_capacity; + static bool cap_property_miss; =20 if (cap_parsing_failed) return false; @@ -301,6 +302,20 @@ bool __init topology_parse_cpu_capacity(struct device_= node *cpu_node, int cpu) ret =3D of_property_read_u32(cpu_node, "capacity-dmips-mhz", &cpu_capacity); if (!ret) { + /* + * A previous CPU node misses binding for CPU raw capacity and + * current CPU node finds its property "capacity-dmips-mhz", + * thus the DT binding for "capacity-dmips-mhz" is inconsistent + * across all CPUs. Set 'cap_parsing_failed' flag and drop the + * CPU raw capacity values. + */ + if (cap_property_miss) { + pr_err("cpu_capacity: binding %pOF raw capacity\n", + cpu_node); + pr_err("cpu_capacity: partial information: fallback to 1024 for all CPU= s\n"); + goto parsing_failure; + } + if (!raw_capacity) { raw_capacity =3D kcalloc(num_possible_cpus(), sizeof(*raw_capacity), @@ -331,12 +346,18 @@ bool __init topology_parse_cpu_capacity(struct device= _node *cpu_node, int cpu) pr_err("cpu_capacity: missing %pOF raw capacity\n", cpu_node); pr_err("cpu_capacity: partial information: fallback to 1024 for all CPU= s\n"); - cap_parsing_failed =3D true; - free_raw_capacity(); + goto parsing_failure; + } else { + cap_property_miss =3D true; } } =20 return !ret; + +parsing_failure: + cap_parsing_failed =3D true; + free_raw_capacity(); + return !ret; } =20 #ifdef CONFIG_CPU_FREQ --=20 2.25.1 From nobody Tue Jun 23 02:20:37 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E3DAC433F5 for ; Sun, 13 Mar 2022 05:55:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232495AbiCMF4x (ORCPT ); Sun, 13 Mar 2022 00:56:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233677AbiCMF4s (ORCPT ); Sun, 13 Mar 2022 00:56:48 -0500 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D12705C84A for ; Sat, 12 Mar 2022 21:55:40 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id d10-20020a17090a7bca00b001c5ed9a196bso706156pjl.1 for ; Sat, 12 Mar 2022 21:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=sFlYEAQckeRXon3Gb7dVboi70GiJgP07IOxKz1DUs5s=; b=pMOwCnvI12AKaRkWveBPimdXWZxUhOX8XXJtN07f7lfryegGQwbpP3kRdQIqw3UkEZ qdo+Nydo02HpHPQXtpV45dD+K0eSWI5WcSY37yGEfZBKpWyzkgw+OQImfr0XtqA/Krn+ CTS65jz+XcKKtXJqn/q+VnfPnuAGRYc4gXzSLVwXHWE4nBz9n/A0amBHeRo3f0QgJazX k1OOQBD0UWQsUBbyyBkiz8z5Y3k/xD+8MIpKNg4FH2rx3rM2rXDYFc+dXjZ4sqHUXVS2 vk0wx3tf3A1p11mcM505dNm4DvuIamZmTgo9mPfEplwX3nE3ZyBQLIo2i9W3XqTZJW2q 9GZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=sFlYEAQckeRXon3Gb7dVboi70GiJgP07IOxKz1DUs5s=; b=r8sMCEs5BhMxvBYxX/KITMZIoELvc7oj9U1fOqpnvnbfZ30cZqpb9nHgSLzHlxqSdM M6A8qByAf54l9Z4lAjDik1xj+ZKwlIgoiYKSuo8vzkmcbtoff6JHMZGABPbWE2yxSrzL oCIrtM71BxdJYZ1nzlkaZR5iKOu0i49VfnQDiYw2MgPw3HqhII4HaqRur2U1CfUDm/Wa YF4dgmbb4XeGQoQgRcDCVF8BgXJG3qSF6Ca8mGlMEOfG75t7tX/B1CAogprxebyQT9T4 mG4PHvudISO8tOw69kifaSxd+3rUiNXH960WF8ej5qJENZDZW/Ec+udvYdbG3CzKkCCW WLOQ== X-Gm-Message-State: AOAM530NATbZWlQA2CW2+n4AUEKFWpSBGF5GbW3qFustZNpGwozWt7uO +Wq3Tk3cmEskliF03MX9kEGWjA== X-Google-Smtp-Source: ABdhPJxUaUZin7PI0oBHosSTs9vG81M1zq0t61rGjZDIiMfNvkfMZqCkbD4AYgfObTnqMDsnqleqWA== X-Received: by 2002:a17:902:c94e:b0:151:a988:f3dd with SMTP id i14-20020a170902c94e00b00151a988f3ddmr18308247pla.142.1647150940242; Sat, 12 Mar 2022 21:55:40 -0800 (PST) Received: from localhost.localdomain (104.225.159.237.16clouds.com. [104.225.159.237]) by smtp.gmail.com with ESMTPSA id m11-20020a056a00080b00b004f75d5f9b5csm14792447pfk.26.2022.03.12.21.55.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Mar 2022 21:55:39 -0800 (PST) From: Leo Yan To: Sudeep Holla , Greg Kroah-Hartman , "Rafael J. Wysocki" , Vincent Guittot , Bryan O'Donoghue , linux-kernel@vger.kernel.org Cc: Leo Yan Subject: [PATCH v1 3/3] arch_topology: Scale CPU capacity if without CPU raw capacity Date: Sun, 13 Mar 2022 13:55:12 +0800 Message-Id: <20220313055512.248571-4-leo.yan@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220313055512.248571-1-leo.yan@linaro.org> References: <20220313055512.248571-1-leo.yan@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Unlike a typical Arm big.LITTLE architecture, some Arm systems (like Qualcomm SoC msm8996 and msm8939) have two clusters, all CPUs in two clusters have the same micro architecture, but some CPUs are "fast" and other are "slow". On this kind platform, all CPUs have the same raw CPU capacity but "fast" CPUs have higher maximum frequency than "slow" ones. Let's see an example, there have two clusters and every cluster have 4 CPUs, every CPU has the same raw CPU capacity. The cluster 0 has the maximum frequency 1497.6MHz and the cluster 1 has the maximum frequency 1113.6MHz, if don't specify "capacity-dmips-mhz" in DT, the we will get below result: # cat /sys/devices/system/cpu/cpu*/cpu_capacity 1024 1024 1024 1024 1024 1024 1024 1024 If "capacity-dmips-mhz" property is not specified for CPU nodes, the kernel will fallback to default capacity value SCHED_CAPACITY_SCALE (1024). Though CPUs in different clusters have different maximum frequencies, kernel skips to scale CPU capacity so that every CPU capacity is always SCHED_CAPACITY_SCALE (1024). This patch is to scale CPU capacity even though "capacity-dmips-mhz" property is not specified in DT. If "capacity-dmips-mhz" property is absent in DT binding, the array "raw_capacity" is not allocated so we rollback to use SCHED_CAPACITY_SCALE as raw CPU capacity and proceed to scale CPU capacity based on maximum frequency. After apply this patch, we can get below result for up elaborated platform: # cat /sys/devices/system/cpu/cpu*/cpu_capacity 1024 1024 1024 1024 761 761 761 761 Signed-off-by: Leo Yan --- drivers/base/arch_topology.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index 0687576e880b..ef1fa2e417ea 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -267,20 +267,25 @@ void topology_normalize_cpu_scale(void) { u64 capacity; u64 capacity_scale; + u32 raw_cpu_capacity; int cpu; =20 - if (!raw_capacity) + if (cap_parsing_failed) return; =20 capacity_scale =3D 1; for_each_possible_cpu(cpu) { - capacity =3D raw_capacity[cpu] * per_cpu(freq_factor, cpu); + raw_cpu_capacity =3D + raw_capacity ? raw_capacity[cpu] : SCHED_CAPACITY_SCALE; + capacity =3D raw_cpu_capacity * per_cpu(freq_factor, cpu); capacity_scale =3D max(capacity, capacity_scale); } =20 pr_debug("cpu_capacity: capacity_scale=3D%llu\n", capacity_scale); for_each_possible_cpu(cpu) { - capacity =3D raw_capacity[cpu] * per_cpu(freq_factor, cpu); + raw_cpu_capacity =3D + raw_capacity ? raw_capacity[cpu] : SCHED_CAPACITY_SCALE; + capacity =3D raw_cpu_capacity * per_cpu(freq_factor, cpu); capacity =3D div64_u64(capacity << SCHED_CAPACITY_SHIFT, capacity_scale); topology_set_cpu_scale(cpu, capacity); @@ -373,7 +378,7 @@ init_cpu_capacity_callback(struct notifier_block *nb, struct cpufreq_policy *policy =3D data; int cpu; =20 - if (!raw_capacity) + if (cap_parsing_failed) return 0; =20 if (val !=3D CPUFREQ_CREATE_POLICY) @@ -412,7 +417,7 @@ static int __init register_cpufreq_notifier(void) * until we have the necessary code to parse the cpu capacity, so * skip registering cpufreq notifier. */ - if (!acpi_disabled || !raw_capacity) + if (!acpi_disabled || cap_parsing_failed) return -EINVAL; =20 if (!alloc_cpumask_var(&cpus_to_visit, GFP_KERNEL)) --=20 2.25.1