From mboxrd@z Thu Jan 1 00:00:00 1970 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=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS 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 60AEDC433E2 for ; Mon, 15 Jun 2020 07:06:25 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3EAC220707 for ; Mon, 15 Jun 2020 07:06:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3EAC220707 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkjBz-0003wy-Lw; Mon, 15 Jun 2020 07:06:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkjBy-0003wt-Nv for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 07:06:02 +0000 X-Inumbo-ID: aadc3fcc-aed6-11ea-b7c5-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id aadc3fcc-aed6-11ea-b7c5-12813bfff9fa; Mon, 15 Jun 2020 07:06:00 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 0WTN05Vi8M7oqOf5ArlUqW6cmr8syDAfoJDQqIWPIVHkjdE+tFQ1Gr/hyliRwcvcCAWlMwDtlG DlPFbTm5CDdeChWpSWIoQlYETY5GZkYEa8wWq9StiOc5UgKnM9xJ5y0PzN0JoUjEyDz8cbe7Hk LdOK5t4fhtKTW7yuCIK7K7OqIytjp1NGvgDfAzWdPH8HL6aeHsxuFeQC4u85oLOVb1tVo9YPr7 a2Tc0mPt2hQtNQ3I1O7O2nm0gBzd1ikzmWGZSK4qMR4b5GpCMxtJ3uabkJuGi+IWFDp+hJ6ZXz 0DU= X-SBRS: 2.7 X-MesageID: 20374503 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20374503" Date: Mon, 15 Jun 2020 09:05:49 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Grzegorz Uriasz Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Message-ID: <20200615070549.GA735@Air-de-Roger> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Jan Beulich , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sun, Jun 14, 2020 at 02:36:28PM +0000, Grzegorz Uriasz wrote: > On some computers the bit width of the PM Timer as reported > by ACPI is 32 bits when in fact the FADT flags report correctly > that the timer is 24 bits wide. On affected machines such as the > ASUS FX504GM and never gaming laptops this results in the inability > to resume the machine from suspend. Without this patch suspend is > broken on affected machines and even if a machine manages to resume > correctly then the kernel time and xen timers are trashed. > > Signed-off-by: Grzegorz Uriasz > Tested-by: Grzegorz Uriasz Thanks for the patch! I'm not sure it's required to add your Tested-by, I usually assume a patch has been tested by it's author unless told otherwise. > --- > xen/arch/x86/acpi/boot.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c > index bcba52e232..2ad3eb4abc 100644 > --- a/xen/arch/x86/acpi/boot.c > +++ b/xen/arch/x86/acpi/boot.c > @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) > if (fadt->xpm_timer_block.space_id == > ACPI_ADR_SPACE_SYSTEM_IO) { > pmtmr_ioport = fadt->xpm_timer_block.address; > - pmtmr_width = fadt->xpm_timer_block.bit_width; > + if (fadt->flags & ACPI_FADT_32BIT_TIMER) > + pmtmr_width = 32; > + else > + pmtmr_width = 24; I think there's also a block below that you need to fix, when xpm_timer_block is not set the data is fetched from pm_timer_block instead, which AFAICT also needs to take ACPI_FADT_32BIT_TIMER into account in order to use the correct size. FWIW, I would set pmtmr_width only once after pmtmr_ioport has been set, since regardless of whether the port is discovered using xpm_timer_block or pm_timer_block the size will always be derived from the flags field. Thanks, Roger.