From patchwork Wed May 4 16:45:42 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 569755 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 D50FBC43219 for ; Wed, 4 May 2022 17:06:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343881AbiEDRKa (ORCPT ); Wed, 4 May 2022 13:10:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356181AbiEDRJD (ORCPT ); Wed, 4 May 2022 13:09:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 835E452E41; Wed, 4 May 2022 09:54:56 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1F13961794; Wed, 4 May 2022 16:54:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69FA2C385A4; Wed, 4 May 2022 16:54:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1651683295; bh=TSEPwtreDnFz7e52zYOcOmj3K2cUukjzTzINFygPDPg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bvMiQtm6PNi/eFip9l7drEO9FKoFN9Em+kl0t/nK5QR42Zo3r1Yn9oG20iTdDbRQG 1TyOUIMjxMUipLkXJFXHGGdUaAw8a9r9f6MP+Vkju7sy5owGZ+o1U7BRzcfHMp+9Qy 8a/HiJj8BRRTPHaJiDRs6dEGA2giNnR8JBIlngdg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?utf-8?b?VmlsbGUgU3lyasOkbMOk?= , Woody Suwalski , "Rafael J. Wysocki" Subject: [PATCH 5.15 149/177] ACPI: processor: idle: Avoid falling back to C3 type C-states Date: Wed, 4 May 2022 18:45:42 +0200 Message-Id: <20220504153106.656086753@linuxfoundation.org> X-Mailer: git-send-email 2.36.0 In-Reply-To: <20220504153053.873100034@linuxfoundation.org> References: <20220504153053.873100034@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Ville Syrjälä commit fc45e55ebc58dbf622cb89ddbf797589c7a5510b upstream. The "safe state" index is used by acpi_idle_enter_bm() to avoid entering a C-state that may require bus mastering to be disabled on entry in the cases when this is not going to happen. For this reason, it should not be set to point to C3 type of C-states, because they may require bus mastering to be disabled on entry in principle. This was broken by commit d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state") which inadvertently allowed the "safe state" index to point to C3 type of C-states. This results in a machine that won't boot past the point when it first enters C3. Restore the correct behaviour (either demote to C1/C2, or use C3 but also set ARB_DIS=1). I hit this on a Fujitsu Siemens Lifebook S6010 (P3) machine. Fixes: d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state") Cc: 5.16+ # 5.16+ Signed-off-by: Ville Syrjälä Tested-by: Woody Suwalski [ rjw: Subject and changelog adjustments ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman --- drivers/acpi/processor_idle.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@ -792,7 +792,8 @@ static int acpi_processor_setup_cstates( if (cx->type == ACPI_STATE_C1 || cx->type == ACPI_STATE_C2 || cx->type == ACPI_STATE_C3) { state->enter_dead = acpi_idle_play_dead; - drv->safe_state_index = count; + if (cx->type != ACPI_STATE_C3) + drv->safe_state_index = count; } /* * Halt-induced C1 is not good for ->enter_s2idle, because it