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 2258CC77B7E for ; Tue, 2 May 2023 08:47:13 +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: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=zRP/5KbSSMFHYx7Es3po/2X1F1CaVAJG+/b9sNKGed8=; b=F8aoDtB9oGcvWc qpLoPoLMjQV6V+cNgd8CiWwKTHzu21UYlVA7ucSBa50FAd4cGHrFIsMfOyvDSu0QJva9iQSZhWrBW WM1NtGcgV/E+rw+9vQjq7v2w4dNV8xDkkZgnc8rribB6ZW4uaNVPGDMPPbWQp69g3E25eYtvRZC2D c00Z1dPP02PpkN/UFITHJZ0KSd7R5gve7cpE9P9Gj65oDcAWn3RncPBnJQdaMONYZJ76sK7Agx4SN n+LBVIxTb0vJb5Gs3RNCh1ZXceE1QLmVmsJmQRW52caaIqA3oMWk4MGpfSgujhxhD9eKrYTc6uiv2 D43uFizeIElAAu9jfZww==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ptleP-000fQc-17; Tue, 02 May 2023 08:46:21 +0000 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1ptleM-000fPo-1g for linux-arm-kernel@lists.infradead.org; Tue, 02 May 2023 08:46:20 +0000 Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1aae46e62e9so19418685ad.2 for ; Tue, 02 May 2023 01:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1683017175; x=1685609175; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hiQalyBCKoJzAGN9ygHoJ7Nfja67Oxy2+AA4JQPS0Pk=; b=kOuFAu58T3IPgNuNzVp5vCYh7hR6x44qFnuyjuSRIfLqqO0MHN5vtigFl/4id/LQVq f9b3pEh65z3oghVjzMcjeMOe6qEEWG37i5Pr72O440jxONR6H4uGh8jkayhV+Z/DE5UG 7zCYXfRzRRjSjfnZWXed9evFK4oZhbwOd7IuL8X8/XbpDgyKuMbE5SdZ2BJfPzxgZDED 1QIAn3JSzPflxYubseT69TnaL1bkMyVjF2KRYfUSHJLvZopFMBligxlqzHIcFi428JeL GkAlUCc/E2HY481Fgi/9gZArPY3Wlcmuv7LXpgcUOLiPojkd3p4Tw7rKT/63dODvb5wZ Vg/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683017175; x=1685609175; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hiQalyBCKoJzAGN9ygHoJ7Nfja67Oxy2+AA4JQPS0Pk=; b=UoYgGugGOvsJJ1uHReFJOjEgIdsInuv5mMbuKVURhHXRwlIFayzL1S+EAc01gPVWwv aFZ2UMuRTx/ranBnOlp5Ai0vDn+RkfnZZA9FkKAA2QNq1AwTiYUYAgkB5SIdSCyQkOFT 9EEGSyHQMSjHLqjetWGdJ0ZiH484bYyos6tZd3zBB2TLM94ybQ6QuBagftsMTyucsZ6o RZFiPTBT0qP0YYSdu8qYmfOLJ6tyb1zF9MuKvzc6tc7xVUYY6m+7e9SMWhuYJ5RRf1aE BfCiBxOqZMKmQiXuMzp+emMthuL4vvP/GB3/o7ykl7Y7W2iDDjZJEWdT0i+CbpqoJvbE xGYQ== X-Gm-Message-State: AC+VfDxYFTnD8+/vwVDpXvXeAxy7Bpy8RsskFynD1W5ec+Xzwrf1cM3D 0yE48s8qaXtzAkcvWZNmcqzkV7lPvb6TlIQFYWo= X-Google-Smtp-Source: ACHHUZ6I0qdjECptknquNNgpCQjBrs60RT5yKteV6HyLqYd2VSn4QOAnmQ+6LOEt3OVBlMYpUQ4hqA== X-Received: by 2002:a17:903:2304:b0:1a1:dd2a:fe6c with SMTP id d4-20020a170903230400b001a1dd2afe6cmr17861325plh.53.1683017175023; Tue, 02 May 2023 01:46:15 -0700 (PDT) Received: from dragon (80.251.214.228.16clouds.com. [80.251.214.228]) by smtp.gmail.com with ESMTPSA id n20-20020a170902969400b001a6e9d170b8sm19031044plp.265.2023.05.02.01.46.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 May 2023 01:46:13 -0700 (PDT) Date: Tue, 2 May 2023 16:45:58 +0800 From: Shawn Guo To: Bjorn Helgaas Cc: Lorenzo Pieralisi , Bjorn Helgaas , Catalin Marinas , Will Deacon , Maximilian Luz , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Andy Gross , Bjorn Andersson Subject: Re: [PATCH v2] arm64: PCI: Add quirk for Qualcomm WoA devices Message-ID: <20230502084558.GA2103@dragon> References: <20230423030520.9570-1-shawn.guo@linaro.org> <20230428213027.GA363093@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230428213027.GA363093@bhelgaas> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230502_014618_565243_D2E52B9D X-CRM114-Status: GOOD ( 36.44 ) 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, Apr 28, 2023 at 04:30:27PM -0500, Bjorn Helgaas wrote: > [+cc Andy, Bjorn A, plea for help from Qualcomm firmware folks] > > On Sun, Apr 23, 2023 at 11:05:20AM +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 platforms. > > That's not quite what the commit log says. The 8fd4391ee717 > assumption is that on arm64, > > - _CRS *consumer* resources are host bridge registers > - _CRS *producer* resources are windows > > which I think matches the intent of the ACPI spec. Yes, I will update. > > > The assumption stands true until Qualcomm WoA (Windows on ARM) devices > > emerge. These devices describe host bridge windows in PNP0A03 _CRS > > resources instead. For example, the Microsoft Surface Pro X has host > > bridges defined as > > > > 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 > > ) > > ... > > > The Memory32Fixed holds a host bridge window, but it's not properly > > defined as a "producer" resource. > > I assume you're saying the use of Memory32Fixed for a window is a > firmware defect, right? Yes, I will reword. > > (Per ACPI r6.5, sec 19.6.83, the Memory32Fixed descriptor cannot > specify a Producer/Consumer ResourceUsage. I think that means the > space is assumed to be ResourceConsumer.) > > > 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 devices to avoid the resource being removed. > > Since this is a Windows laptop, I assume this works with Windows and > that Windows will in fact assign BARs in that Memory32Fixed area. > > If we knew what the firmware author's intent was, we could probably > make Linux understand it. > > Maybe (probably) Windows treats these descriptors the same on arm64 as > on x86, i.e., *everything* in PNP0A03 _CRS is assumed to be "producer" > (at least, that's my experimental observation; I have no actual > knowledge of Windows). That's my bet too. > > So I guess 8fd4391ee717 must have been motivated by some early arm64 > platform that put "consumer" descriptors in PNP0A03 _CRS as Lorenzo > said [1]. > > In that case I guess our choices are: > > - Add quirks like this and keep adding them for every new arm64 > platform that uses the same "everything in PNP0A03 _CRS is a > producer" strategy. > > - Remove 8fd4391ee717, break whatever early arm64 platforms needed > it, and add piecemeal quirks for them. > > I hate both, but I think I hate the first more because it has no end, > while the second is painful but limited. Thanks for your opinion on this! Let's try to pursue the second then. > > Obviously we would need to do whatever we can to identify and fix > things that depend on 8fd4391ee717 before reverting it. Lorenzo, I have zero experience on any of those early arm64 platforms. I would appreciate it if you can give some direction on how to identify them. Looking at your comment below, I'm wondering if it's true that the firmware on those early arm64 platforms has no MCFG table but provide root->mcfg_addr via _CBA method? "I believe it is because there were arm64 platforms (early) that added a consumer descriptor in the host bridge CRS with MMIO registers space in it (I am not sure I can find the bug report - it has been a while, remember the issue with non-ECAM config space and where to add the MMIO resource required to "extend" MCFG config space ? I will never forget that :))." It would be very helpful if we can find someone running any of those early platforms, so that we can ask favor to dump ACPI tables and test things out. Shawn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel