From patchwork Tue Oct 13 07:35:57 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Zhang, Rui" X-Patchwork-Id: 269497 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 310A4C433E7 for ; Tue, 13 Oct 2020 07:36:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 043D72065C for ; Tue, 13 Oct 2020 07:36:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390183AbgJMHgA (ORCPT ); Tue, 13 Oct 2020 03:36:00 -0400 Received: from mga02.intel.com ([134.134.136.20]:56233 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390384AbgJMHgA (ORCPT ); Tue, 13 Oct 2020 03:36:00 -0400 IronPort-SDR: 7+yGIyBNuXdXeCx4HwHf/fng5JqtInXU09c8/2u5J+rhzf0mFGRPwkhYjOi4YzGeecJ1gsiEyF vWPv3sWZruYA== X-IronPort-AV: E=McAfee;i="6000,8403,9772"; a="152798297" X-IronPort-AV: E=Sophos;i="5.77,369,1596524400"; d="scan'208";a="152798297" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2020 00:35:59 -0700 IronPort-SDR: P9O0t4Hamz5UJ1bEkVTgPUrx+UnMpAnFYxBFM4vks5YKO67i9rE2fnHE8hSm2EhNIQ5I9KDqld ndiD1ElcNB2g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,369,1596524400"; d="scan'208";a="313713138" Received: from lkp-server02.sh.intel.com (HELO inn.sh.intel.com) ([10.239.97.151]) by orsmga003.jf.intel.com with ESMTP; 13 Oct 2020 00:35:57 -0700 From: Zhang Rui To: linux-acpi@vger.kernel.org, rjw@rjwysocki.net Cc: sukumar.ghorai@intel.com, rui.zhang@intel.com Subject: [PATCH V2] acpi: reboot: fix racing after writing to ACPI RESET_REG Date: Tue, 13 Oct 2020 15:35:57 +0800 Message-Id: <20201013073557.4580-1-rui.zhang@intel.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org According to the ACPI spec, "The system must reset immediately following the write to the ACPI RESET_REG register.", but there are cases that the system does not follow this and results in racing with the subsequetial reboot mechanism, which brings unexpected behavior. Fix this by adding a 15ms delay after writing to the ACPI RESET_REG. Reported-by: Ghorai, Sukumar Signed-off-by: Zhang Rui --- drivers/acpi/reboot.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c index ca707f5b521d..0e357cb5612f 100644 --- a/drivers/acpi/reboot.c +++ b/drivers/acpi/reboot.c @@ -3,6 +3,7 @@ #include #include #include +#include #ifdef CONFIG_PCI static void acpi_pci_reboot(struct acpi_generic_address *rr, u8 reset_value) @@ -66,4 +67,13 @@ void acpi_reboot(void) acpi_reset(); break; } + + /* + * Some platforms do not shutdown immediately after writing to the + * ACPI reset register, and this results in racing with the + * subsequetial reboot mechanism. + * Delay for 15ms has been proved to be long enough for the system + * to reboot, for these platforms. + */ + mdelay(15); }