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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id B7A91C6FD19 for ; Fri, 10 Mar 2023 23:06:49 +0000 (UTC) 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: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:References: List-Owner; bh=9kHO17GwBK9SL/0tH5fWgLaKBKc4/Obf2LJaTrY0muw=; b=CPzyBdXF+7ZpjJ C3ytHBc1bcCotHdoaon68Sdp7dUBG7CXnAv6dZPLNINYy5AJ775DTp0lyHs7IGeyqVUiojux1E6qH OcXd8uDrG62ylQipzzFpa/Zm0Gph5tPhdL4V+6M7DNC8A43auzevkLnScLD7o+45fehXexBjJWiQM Ki5JkYoCIp7WwE8d3LysOntkzuOsut0bZ/z3OaC/cTHxh14htncsOrKu0LAIQX8WNNnlu6cZMrYRT jpIjlwxuqQ4dlDrHaja6Y2VjJykcd8Oi8V+NsyzHpVPTq0C8qLmAEz/qjXros+y8gUz4ssd57Rxyl XkYdeakq8/jG5TpypG4w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1palo5-00GZgg-ID; Fri, 10 Mar 2023 23:05:49 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1palo1-00GZfU-8m for linux-arm-kernel@lists.infradead.org; Fri, 10 Mar 2023 23:05:47 +0000 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 ams.source.kernel.org (Postfix) with ESMTPS id C3899B82400; Fri, 10 Mar 2023 23:05:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51FBFC433D2; Fri, 10 Mar 2023 23:05:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678489541; bh=qYf7XwsN3paZxawhDYAE5mQqUB8cGC47Gx+srOcNCLw=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=WxtsZXJnV6YIb9iZHhO/zmGSkmBWj4CDw+iRqijYdhHcVErkfqUtb0zJ35Lv0EZxU i5VJfsuu/mZdzc0FeisJzSsw1XDqHrK338fvVZCdjiiOJ3rch9A1YfebAGs6JohYoH qsm+MaSmdexvgI44G/3sKrINfU+1fRSE8ZO3OAB2ZAVTf9yv1KCAbeZ0KKOeshsa9e 2kjspx8opCNRL6ffRGDjvY1Ft086IYzztnFdqwfnTZMIgpzeA3aW1S9hmaDnOqwlDL TwezQaKFX8So4kX5OIdGe5HpPffjGRqgdMrWuuNbF3mRR2DRhcqEbtmLK90jdd4rFJ Aa64mApHwIt6g== Date: Fri, 10 Mar 2023 17:05:39 -0600 From: Bjorn Helgaas To: Lorenzo Pieralisi Cc: Shawn Guo , Catalin Marinas , Will Deacon , Bjorn Helgaas , Maximilian Luz , linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: PCI: Add quirk for platforms running Windows Message-ID: <20230310230539.GA1289856@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230310_150545_652887_0B53C625 X-CRM114-Status: GOOD ( 37.37 ) 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 Fri, Mar 10, 2023 at 02:26:55PM +0100, Lorenzo Pieralisi wrote: > On Wed, Mar 08, 2023 at 12:53:10PM -0600, Bjorn Helgaas wrote: > > On Mon, Feb 27, 2023 at 10:12:21AM +0800, Shawn Guo wrote: > > > Commit 8fd4391ee717 ("arm64: PCI: Exclude ACPI "consumer" resources from > > > host bridge windows") introduced a check to remove host bridge register > > > resources for all arm64 platforms, with the assumption that the PNP0A03 > > > _CRS resources would always be host bridge registers and never as windows > > > on arm64. > > > > > > The assumption stands true until Qualcomm Snapdragon Windows laptops > > > emerge. These laptops describe host bridge windows in PNP0A03 _CRS > > > resources instead. For example, the Microsoft Surface Pro X has host > > > bridges defined as > > > > > > Name (_HID, EisaId ("PNP0A08") /* PCI Express Bus */) // _HID: Hardware ID > > > Name (_CID, EisaId ("PNP0A03") /* PCI Bus */) // _CID: Compatible ID > > > > > > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings > > > { > > > Name (RBUF, ResourceTemplate () > > > { > > > Memory32Fixed (ReadWrite, > > > 0x60200000, // Address Base > > > 0x01DF0000, // Address Length > > > ) > > > WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, > > > 0x0000, // Granularity > > > 0x0000, // Range Minimum > > > 0x0001, // Range Maximum > > > 0x0000, // Translation Offset > > > 0x0002, // Length > > > ,, ) > > > }) > > > Return (RBUF) /* \_SB_.PCI0._CRS.RBUF */ > > > } > > > > > > The Memory32Fixed holds a host bridge window, but it's not properly > > > defined as a "producer" resource. Consequently the resource gets > > > removed by kernel, and the BAR allocation fails later on: > > > > > > [ 0.150731] pci 0002:00:00.0: BAR 14: no space for [mem size 0x00100000] > > > [ 0.150744] pci 0002:00:00.0: BAR 14: failed to assign [mem size 0x00100000] > > > [ 0.150758] pci 0002:01:00.0: BAR 0: no space for [mem size 0x00004000 64bit] > > > [ 0.150769] pci 0002:01:00.0: BAR 0: failed to assign [mem size 0x00004000 64bit] > > > > > > This eventually prevents the PCIe NVME drive from being accessible. > > > > > > Add a quirk for these platforms to avoid the resource being removed. > > > > > > Signed-off-by: Shawn Guo > > > --- > > > We are running into the issue on more devices than just Surface Pro X > > > now, so trying to sort it out with a quirk as suggested by Lorenzo [1]. > > > > One thing I don't like about this application of quirks is that the > > list of affected platforms is likely to grow, which is an ongoing > > burden for users and developers. > > > > Can we have a conversation with Qualcomm about how they *intend* this > > to work? Linux is probably doing something wrong (interpreting > > something differently than Windows does), and if we could fix that, we > > have a better chance of future platforms working without quirks. > > Catch-22. What if some firmware would add host bridge MMIO register > space (marked as consumer) in the _CRS ? We would end up allocating > BAR regions in there, which is not right, so your commit: > > 8fd4391ee717 ("arm64: PCI: Exclude ACPI "consumer" resources from host bridge windows") > > is correct and if we revert it we would trigger regressions on some > arm64 platforms for the reason I mention above. > > We can look for clarification at ACPI specs level but for firmware > that is out there I am not sure what options we have. I don't remember why 8fd4391ee717 exists; I assume there was some platform that needed it. I should have included that in the commit log; mea culpa. In any event, I assume Windows works on both that platform and the ones mentioned in this quirk, and I assume Windows doesn't require platform-specific quirks for something like this. I admit that's a lot of assuming, but if Windows can do it, Linux should be able to do it, too. > > > +static struct acpi_platform_list qcom_platlist[] = { > > > + /* Thinkpad X13s */ > > > + { "LENOVO", "SDM8280 ", 0, ACPI_SIG_DSDT, all_versions, QCOM_DSDT_QUIRK }, > > > + /* Microsoft Surface Pro 9 (5G) and Windows Dev Kit 2023 */ > > > + { "QCOMM ", "SDM8280 ", 0, ACPI_SIG_DSDT, all_versions, QCOM_DSDT_QUIRK }, > > > + /* Microsoft Surface Pro X */ > > > + { "QCOMM ", "SDM8180 ", 0, ACPI_SIG_DSDT, all_versions, QCOM_DSDT_QUIRK }, _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel