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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E978BC433EF for ; Thu, 10 Feb 2022 06:40:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235328AbiBJGkB (ORCPT ); Thu, 10 Feb 2022 01:40:01 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:49092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229901AbiBJGkA (ORCPT ); Thu, 10 Feb 2022 01:40:00 -0500 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F19FA10A6; Wed, 9 Feb 2022 22:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644475203; x=1676011203; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ZfJE1FFBu6sgemhtirYEevD0xuq7pkhl4dDQwqgLxNY=; b=VQ7cHeQwrjW1aSUrAzEG6IKiV5b1RIdsbZgi8j6KqYSxwUJGct51Pz8g md/mdEUhKNsOowkAHCxRJgXPE4EL1TgTApRNIOP63GORGCsF00TxrnqxX UvYPdrGqH0YvbG2zSAD/SwumTnrNZTFKbKWYr2NFU6PtH33O5PEl+jAPU Zg6ryScn3TwmXvKmsmTQ2WDyAW25+w4kX7UI7dPQpDQRKilW8OWHdJa8m 5ziD+bVJ7a1HGXgLj0kEu/abH4E21aSwJm1EBf6j0SEF037GxURVKtKVV v5Z9TUiWlKylA69L695g7wqBdbhq5cDPq1msDwf8qThKaK/v7LNl9j50e g==; X-IronPort-AV: E=McAfee;i="6200,9189,10253"; a="247006511" X-IronPort-AV: E=Sophos;i="5.88,358,1635231600"; d="scan'208";a="247006511" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2022 22:40:00 -0800 X-IronPort-AV: E=Sophos;i="5.88,358,1635231600"; d="scan'208";a="526354353" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.162]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Feb 2022 22:39:55 -0800 Received: by lahna (sSMTP sendmail emulation); Thu, 10 Feb 2022 08:39:48 +0200 Date: Thu, 10 Feb 2022 08:39:48 +0200 From: Mika Westerberg To: Hans de Goede Cc: "Rafael J. Wysocki" , Bjorn Helgaas , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Myron Stowe , Juha-Pekka Heikkila , Ingo Molnar , Borislav Petkov , linux-acpi , Linux PCI , x86@kernel.org, Linux Kernel Mailing List , Benoit =?iso-8859-1?Q?Gr=E9goire?= , Hui Wang Subject: Re: [5.17 regression] "x86/PCI: Ignore E820 reservations for bridge windows on newer systems" breaks suspend/resume Message-ID: References: <697aaf96-ec60-4e11-b011-0e4151e714d7@redhat.com> <02994528-aaad-5259-1774-19aeacdd18fc@redhat.com> <2f01e99d-e830-d03c-3a9d-30b95726cc2c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2f01e99d-e830-d03c-3a9d-30b95726cc2c@redhat.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi Hans, On Wed, Feb 09, 2022 at 05:08:13PM +0100, Hans de Goede wrote: > As mentioned in my email from 10 seconds ago I think a better simpler > fix would be to just do: > > diff --git a/arch/x86/kernel/resource.c b/arch/x86/kernel/resource.c > index 9b9fb7882c20..18656f823764 100644 > --- a/arch/x86/kernel/resource.c > +++ b/arch/x86/kernel/resource.c > @@ -28,6 +28,10 @@ static void remove_e820_regions(struct resource *avail) > int i; > struct e820_entry *entry; > > + /* Only remove E820 reservations on classic BIOS boot */ > + if (efi_enabled(EFI_MEMMAP)) > + return; > + > for (i = 0; i < e820_table->nr_entries; i++) { > entry = &e820_table->entries[i]; > > > I'm curious what you think of that? I'm not an expert in this e820 stuff but this one looks really simple and makes sense to me. So definitely should go with it assuming there are no objections from the x86 maintainers.