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=-2.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_DKIMWL_WL_HIGH,USER_AGENT_MUTT autolearn=unavailable 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 1AC7FC282DD for ; Mon, 10 Jun 2019 10:11:45 +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 E4B0E20859 for ; Mon, 10 Jun 2019 10:11:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="oc8u5Gbh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E4B0E20859 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject: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=AYoXr8rVhTPCM0RuitS7S2ok0PJXrlztq9cqnOGrIxE=; b=oc8u5GbhCAte+3 YGO2TVHIRjbhznyRE2/c0B9Q9gIm9v4P45Mc5trOzB6yglKPrJDZfxK1VMT39PivvtzDrHNipTMvy y5KB0RztDi1XXDIdOBTMSFjc4csOHo8O6cDmP1MflLAAMWIlI7KzcHHTX/ZXW5h8HsPzOUka3xdk2 vl6E/bjU/3SVMXSouY6xWUZEnW/bTrqsJ+CA1r1Kh+T+EwZU12MFj0Lh29RGfCOOkEoJA9awzCXGa EWM3BepTIB+IY6HkwudlXWCy6Wzc7CZUEG6VcAvI/aVAVmy2KRIsbbfgkuPi1KjjrTEjldu9aKZll k5qluq0PbQ3objy/Cc6w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1haHH9-0006PU-Mg; Mon, 10 Jun 2019 10:11:39 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1haHH5-0006Op-Vv for linux-arm-kernel@lists.infradead.org; Mon, 10 Jun 2019 10:11:37 +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 762CE344; Mon, 10 Jun 2019 03:11:32 -0700 (PDT) Received: from redmoon (unknown [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 36A7A3F557; Mon, 10 Jun 2019 03:13:13 -0700 (PDT) Date: Mon, 10 Jun 2019 11:11:29 +0100 From: Lorenzo Pieralisi To: Benjamin Herrenschmidt Subject: Re: [RFC] ARM64 PCI resource survey issue(s) Message-ID: <20190610101129.GC25976@redmoon> References: <56715377f941f1953be43b488c2203ec090079a1.camel@kernel.crashing.org> <20190604014945.GE189360@google.com> <960c94eb151ba1d066090774621cf6ca6566d135.camel@kernel.crashing.org> <20190604124959.GF189360@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20190610_031136_122923_D47777D7 X-CRM114-Status: GOOD ( 17.64 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ard Biesheuvel , linux-pci@vger.kernel.org, Sinan Kaya , "Zilberman, Zeev" , "Saidi, Ali" , Bjorn Helgaas , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jun 05, 2019 at 06:41:16AM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2019-06-04 at 07:49 -0500, Bjorn Helgaas wrote: > > > Yes... I am not personally aware of such a case but I was led to > > > believe based on prior conversations that such setups do exist, > > > especially in the non-ACPI ARM64 world. Which is why I would suggest > > > initially changing the default only on ACPI, at least until we have a > > > bit better visibility. > > > > If a resource assignment that is valid in terms of all the PCI rules > > (BARs are valid, BARs are inside upstream bridge windows, etc) doesn't > > work, we would need more information in order to fix anything. We'd > > need to know exactly *what* doesn't work and *why* so we can avoid it. > > The current blanket statement of "reassign everything and hope it > > works better" is useless. > > I agree and I assume the problem stems from BIOSes creating either > invalid or incomplete assignments but as I said, I don't know for sure > as our platforms dont have that problem. The first thing that I would like to agree on is what mechanism the kernel has to ensure a BAR resource is not changed by the PCI resource assignment mechanism. (1) IORESOURCE_PCI_FIXED flag: I have *very* strong feelings that this flag works because x86 kernel code claims all resources on probe (which effectively makes them immutable). It does not work for PCI bridges apertures and I am not sure it works for arches (eg ARM64) that reassign everything, even for *devices* (2) Claiming resources: this basically means assigning a parent to a resource. Kernel PCI resource assignment code is full of code I do not understand and that in my opinion works because of (1). I *tried*, while posting ACPI PCI code for ARM64, to do what x86 does: - Claim all resources - Reassign the resources that could not be claimed This led to: a) Spurious dmesg logs (Eg Resources that could not be claimed) b) If FW set-up bridge windows, it may lead to reassignment failures if the bridge windows were sized *wrongly* but the kernel still manage to claim them (because they fit in the parent window). Hence, we reassign everything on ARM64 on ACPI (except for bus numbers and that was, indeed, a mistake). In short, this is a mess and one that I do not have much leeway to fix because the PCI resource assignment code is as it is owing to legacy that we can't touch unless we want to fix regressions for the next year. And then there is _DSM #5. The problem we have is that there is *no* specific way to tell what's right or wrong and that's what _DSM #5 is supposed to fix. To implement it to the letter it will take lots of work. First thing is to answer and agree (1) vs (2) above, aka define what an immutable resource is from a kernel point of view, one with a parent != NULL OR one with IORESOURCE_PCI_FIXED flag. Lorenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel