Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1502855pxu; Sat, 24 Oct 2020 12:54:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwkQ3ngdO3gHv1aQjde7WjhHi1qhH38ZegcMK9cw3bXoHOKKxjqyxY6f/poGgZxLYRaS56W X-Received: by 2002:a17:906:b204:: with SMTP id p4mr8487364ejz.214.1603569255979; Sat, 24 Oct 2020 12:54:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603569255; cv=none; d=google.com; s=arc-20160816; b=UnX3pBJkwibBc/1zvQG9pzMAan/Y5HyX6u0G1TrIfVT61LIHoqPzaxkqr+rAw57Hgn foj6qUs1WvTKLt93lMdjRoO2QCR2kfTXdBcOAFu525CVxv7tDTLaYGUnsZl/90P10A3b 2pJe9dQp5bEjBF3nW2fVuaMCwfbLqBvMHvIsUqXy8oep0WKiKbBytNqVE07SKEuIS711 icSCG3p9+6CpSylmXKo6yAipst7BrrikAauqhHx+VZtDOjCdbkzmBnyO/3NqkQFBxNE1 tFvTFzgbRjAvtNpVRcf6C7hBfXhHStuDVFmcpsvksbDhAp0gfBVLasyp4hRJPkpsGyki WwNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from:ironport-sdr :ironport-sdr; bh=oGbaOhsyTcYz9K/vumrLosc4VuRmbbHwZe136Cs33pU=; b=aiWeHpp757JRheW6Gppx1FTFkgvepaAICppMsXE8KhITebEiC6K6KTmcar0gVB3iEy WFnOrD3GDDBUIuI2AZCAeYY4H54Vs9xuEaocCUnkIonZZiDJyktGC//Dyjq8HnaXqrC+ MLb0fofFSjkpvn/2u4wWTTjIRFT+2Lo8MzKoLbrItWwUHiFVIiVnOokQho2DlW1h0+xq 91VmPiazouZeH+0+EIfg/DCsXTC2J/xasYWF3QeWI+9s7Pvi7mkvnW/n1VNVedhMZlpb kfeXcoynpjP17/A3l+3JKiXeQFZxKDAxDivS3GCMUuBZb1cFF+vac83OsuBBfUOMS0ry 8OlQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g20si4543087ejm.339.2020.10.24.12.53.37; Sat, 24 Oct 2020 12:54:15 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761257AbgJXQ1t (ORCPT + 99 others); Sat, 24 Oct 2020 12:27:49 -0400 Received: from mga18.intel.com ([134.134.136.126]:49816 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760111AbgJXQ1s (ORCPT ); Sat, 24 Oct 2020 12:27:48 -0400 IronPort-SDR: GB9ympbJs4IqkzUlPd+XTSG5YdzL9rP7rELDxZZinI0+9Mww4lRs3mw2clC2b0NGMfj0+wJVwz JX6MOp7M1+WQ== X-IronPort-AV: E=McAfee;i="6000,8403,9784"; a="155568293" X-IronPort-AV: E=Sophos;i="5.77,412,1596524400"; d="scan'208";a="155568293" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2020 09:27:48 -0700 IronPort-SDR: q/d4CGkNYsO2YETvtlAgGKKbbVKRamwEtUfMYy3pMEPizZxoUnFSU1CAKAzr7noqKuzqXxxXLV TpJm+LhjjdPQ== X-IronPort-AV: E=Sophos;i="5.77,412,1596524400"; d="scan'208";a="534797141" Received: from chenyu-office.sh.intel.com ([10.239.158.173]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2020 09:27:46 -0700 From: Chen Yu To: Len Brown , "Rafael J. Wysocki" Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Chen Yu , "5 . 6+" Subject: [PATCH] intel_idle: Fix max_cstate for processor models without C-state tables Date: Sun, 25 Oct 2020 00:29:53 +0800 Message-Id: <20201024162953.14142-1-yu.c.chen@intel.com> X-Mailer: git-send-email 2.17.1 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently intel_idle driver gets the c-state information from ACPI _CST if the processor model is not recognized by it. However the c-state in _CST starts with index 1 which is different from the index in intel_idle driver's internal c-state table. While intel_idle_max_cstate_reached() was previously introduced to deal with intel_idle driver's internal c-state table, re-using this function directly on _CST might get wrong. Fix this by subtracting the index by 1 when checking max cstate via _CST. For example, append intel_idle.max_cstate=1 in boot command line, Before the patch: grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/name POLL After the patch: grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/name /sys/devices/system/cpu/cpu0/cpuidle/state0/name:POLL /sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1_ACPI Fixes: 18734958e9bf ("intel_idle: Use ACPI _CST for processor models without C-state tables") Reported-by: Pengfei Xu Cc: 5.6+ # 5.6+ Signed-off-by: Chen Yu --- drivers/idle/intel_idle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c index 9a810e4a7946..dbd4be1c271b 100644 --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@ -1236,7 +1236,7 @@ static void __init intel_idle_init_cstates_acpi(struct cpuidle_driver *drv) struct acpi_processor_cx *cx; struct cpuidle_state *state; - if (intel_idle_max_cstate_reached(cstate)) + if (intel_idle_max_cstate_reached(cstate - 1)) break; cx = &acpi_state_table.states[cstate]; -- 2.17.1