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=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 DBFEAC47096 for ; Thu, 3 Jun 2021 14:18:31 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 A99F3613E9 for ; Thu, 3 Jun 2021 14:18:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A99F3613E9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wYc/7+KtLoDc5GnvxKlUMpDMOwkp9ggOzvK1agigGTE=; b=IPAJNLghXuPDfU fXEAiI258otudfDxAgSkIq4skucCJ1axOVLyf227b8uLrBYt0hqy5Tqwmttq8db2MgscWO8iYCaSG +wToLr+C9aX4W8P2j4Xr5BMjlTMyh0V1QeKIHFOPeh03PHC8uAAtQKPm533I+zUuxfEUlI7/6DHBb Y7oG6y0Sd2HYUi79HcAiQHjSNfDWfEsangNZ8KA8Oo2lNtXj946JcL0cLftFVdPfd/Vw/wyFgzWI1 ttqYNKgxIe34W1OoqOp1tBGmjw1n8BU5Jub8ZfPHRnEaZPlSfK+xdGzZz0mRQl4ofFJHCk8jSZxtZ L/nOp19af8f+N5Lb3XBA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1loo9W-0095ZI-Cs; Thu, 03 Jun 2021 14:16:54 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1loo9R-0095Ym-Nx for linux-arm-kernel@lists.infradead.org; Thu, 03 Jun 2021 14:16:51 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 593E911FB; Thu, 3 Jun 2021 07:16:47 -0700 (PDT) Received: from lpieralisi (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 71DE23F73D; Thu, 3 Jun 2021 07:16:46 -0700 (PDT) Date: Thu, 3 Jun 2021 15:16:41 +0100 From: Lorenzo Pieralisi To: Qian Cai Cc: Bjorn Helgaas , Catalin Marinas , Will Deacon , linux-arm , Linux PCI Subject: Re: Arm64 double PCI ECAM reservations in acpi_resource_consumer() Message-ID: <20210603141641.GA17284@lpieralisi> References: <3a1165b6-033f-33af-fe1f-33a1be4b500a@quicinc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3a1165b6-033f-33af-fe1f-33a1be4b500a@quicinc.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210603_071649_898027_FDB57DFC X-CRM114-Status: GOOD ( 19.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jun 02, 2021 at 08:15:20PM -0400, Qian Cai wrote: > > > On 6/2/2021 6:09 PM, Bjorn Helgaas wrote: > > [+cc linux-pci] > > > > On Wed, Jun 2, 2021 at 4:49 PM Qian Cai wrote: > >> > >> Bjorn, I noticed PCI ECAM could be reserved twice on arm64. Firs time through, > >> > >> [ 19.087790][ T1] acpi_ns_walk_namespace+0xc0/0x390 > >> [ 19.092927][ T1] acpi_get_devices+0x160/0x1a4 > >> [ 19.097629][ T1] acpi_resource_consumer+0x8c/0xc0 > >> [ 19.102680][ T1] pci_acpi_scan_root+0x158/0x4c8 > >> [ 19.107555][ T1] acpi_pci_root_add+0x450/0x8e8 > >> [ 19.112345][ T1] acpi_bus_attach+0x300/0x7d0 > >> [ 19.116960][ T1] acpi_bus_attach+0x178/0x7d0 > >> [ 19.121576][ T1] acpi_bus_attach+0x178/0x7d0 > >> [ 19.126190][ T1] acpi_bus_scan+0xa8/0x170 > >> [ 19.130545][ T1] acpi_scan_init+0x220/0x558 > >> [ 19.135074][ T1] acpi_init+0x1f4/0x270 > >> > >> where pci_acpi_setup_ecam_mapping() confirmed all reservations are succeed. Then, > >> > >> [ 19.880588][ T1] acpi_ns_walk_namespace+0xc0/0x390 > >> [ 19.885725][ T1] acpi_get_devices+0x160/0x1a4 > >> [ 19.890426][ T1] pnpacpi_init+0xa0/0x10 > >> > >> As the results, those messages are showed up during the boot in pnpacpi_init(). > >> > >> [ 17.763968] system 00:00: [mem 0x10000000000-0x1000fffffff window] could not be reserved > >> [ 17.772900] system 00:00: [mem 0x7800000000-0x780fffffff window] could not be reserved > >> [ 17.781627] system 00:00: [mem 0x7000000000-0x700fffffff window] could not be reserved > >> [ 17.790350] system 00:00: [mem 0x6000000000-0x600fffffff window] could not be reserved > >> [ 17.799073] system 00:00: [mem 0x5800000000-0x580fffffff window] could not be reserved > >> [ 17.808155] system 00:00: [mem 0x1000000000-0x100fffffff window] could not be reserved > >> [ 17.816862] system 00:00: [mem 0x600000000-0x60fffffff window] could not be reserved > >> [ 17.825417] system 00:00: [mem 0x400000000-0x40fffffff window] could not be reserved > >> > >> Looking through the x86's version of pci_acpi_scan_root(), it won't call acpi_resource_consumer(), so I suppose this bug is only affecting arm64? > > > > This might be related to > > https://lore.kernel.org/linux-acpi/20210510234020.1330087-1-luzmaximilian@gmail.com/T/#u > > > > Can you try applying that patch to see if it is related? > > Unfortunately, that revert patch does not help. FYI, here is the first reservation from acpi_resource_consumer(). This is not the "reservation". AFAICS acpi_resource_consumer() checks whether the ECAM region is part of _a_ given ACPI device _CRS in the namespace, it does not "reserve" anything. IIUC the issue here is that we request the ECAM region in pci_ecam_create() and later the code in: drivers/pnp/system.c tries to request the ECAM region (that lives in the PNP0C02 _CRS) and fails (see reserve_range() and request_mem_region()). As the comment in reserve_range() goes, this is harmless, not sure whether there is anything to do about it. Lorenzo > [ 16.224306] acpi PNP0A08:00: ECAM area [mem 0x10000000000-0x1000fffffff] reserved by PNP0C02:00 > [ 16.241027] acpi PNP0A08:00: ECAM at [mem 0x10000000000-0x1000fffffff] for [bus 00-ff] > [ 16.810172] acpi PNP0A08:01: ECAM area [mem 0x7800000000-0x780fffffff] reserved by PNP0C02:00 > [ 16.826701] acpi PNP0A08:01: ECAM at [mem 0x7800000000-0x780fffffff] for [bus 00-ff] > [ 17.289302] acpi PNP0A08:02: ECAM area [mem 0x1000000000-0x100fffffff] reserved by PNP0C02:00 > [ 17.305840] acpi PNP0A08:02: ECAM at [mem 0x1000000000-0x100fffffff] for [bus 00-ff] > [ 17.641917] acpi PNP0A08:03: ECAM area [mem 0x5800000000-0x580fffffff] reserved by PNP0C02:00 > [ 17.658445] acpi PNP0A08:03: ECAM at [mem 0x5800000000-0x580fffffff] for [bus 00-ff] > [ 18.059837] acpi PNP0A08:04: ECAM area [mem 0x6000000000-0x600fffffff] reserved by PNP0C02:00 > [ 18.076368] acpi PNP0A08:04: ECAM at [mem 0x6000000000-0x600fffffff] for [bus 00-ff] > [ 18.413220] acpi PNP0A08:05: ECAM area [mem 0x7000000000-0x700fffffff] reserved by PNP0C02:00 > [ 18.429745] acpi PNP0A08:05: ECAM at [mem 0x7000000000-0x700fffffff] for [bus 00-ff] > [ 18.767189] acpi PNP0A08:06: ECAM area [mem 0x600000000-0x60fffffff] reserved by PNP0C02:00 > [ 18.783559] acpi PNP0A08:06: ECAM at [mem 0x600000000-0x60fffffff] for [bus 00-ff] > [ 19.201613] acpi PNP0A08:07: ECAM area [mem 0x400000000-0x40fffffff] reserved by PNP0C02:00 > [ 19.217965] acpi PNP0A08:07: ECAM at [mem 0x400000000-0x40fffffff] for [bus 00-ff] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel