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.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=ham 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 4B873C31E4B for ; Fri, 14 Jun 2019 20:13:35 +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 1D7982133D for ; Fri, 14 Jun 2019 20:13:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="bAMc8PMo"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="y9B/wKt8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D7982133D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=4yB4LLj1K7zQexubMJJukQ3OGxSB3m8A+ZxCFied7Eo=; b=bAMc8PMopIgthA S2fazoxXr5dZygYRZEOaHcQbfWIESI3z8qlM8+BuBhj/3XJOoOPT1cYrBxuUYCRzrRG5HvXZUJM/o i+4PLCokQAFXPwWEetssBnRihoA4ACtPITiSrN4hW+9haglHOxOcpgzCmIpUYX6KR29LfYWU2tN4M u+t1lwPfAnAe2XPegDvCwu4/8NkIrUaiwFP4VcXH10GZK4DB1RPn3xSEmgbJKP3VpL2jON6mmxfWB bkZpLAF6qtLirPjt7JujsINI/FVZ+quHHOdX/ULoZFA2Rw+OUDDqMqc1E88jXtNf6ULfW8GGHAB75 w97G/PThIDd0+Ec4vZBQ==; 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 1hbsZq-0008AJ-QG; Fri, 14 Jun 2019 20:13:34 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hbsZo-00089X-Cy for linux-arm-kernel@lists.infradead.org; Fri, 14 Jun 2019 20:13:33 +0000 Received: from localhost (unknown [69.71.4.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AC94E2133D; Fri, 14 Jun 2019 20:13:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560543212; bh=xAM7mBjDbgUS5XcFtTkGqbwxqhzw2VQJQpfEmS3r5OU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=y9B/wKt8iAZmQzcNZMwojsGSPxWD0nlvAJ9fR2Mgc9gCFoXg973sQdjAjVCP/6T1t b9gCFz2nYYCVV+dwHCGPAcSHn7aY/9VRZMzyrF48P1GQ4HMlgijZoW0/5QGEf73pu9 RW4fNguuPDa39W3Az18UKkqM6+czwwa/16ADuqpE= Date: Fri, 14 Jun 2019 15:13:18 -0500 From: Bjorn Helgaas To: Benjamin Herrenschmidt Subject: Re: [RFC PATCH v2] arm64: acpi/pci: invoke _DSM whether to preserve firmware PCI setup Message-ID: <20190614201318.GT13533@google.com> References: <5783e36561bb77a1deb6ba67e5a9824488cc69c6.camel@kernel.crashing.org> <20190613190248.GH13533@google.com> <20190614095742.GA27188@e121166-lin.cambridge.arm.com> <906b2576756e82a54b584c3de2d8362602de07ce.camel@kernel.crashing.org> <84320a45ef9395d82bf1c5d4d2d7e6db189cbfda.camel@kernel.crashing.org> <20190614131253.GR13533@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190614_131332_465243_55726434 X-CRM114-Status: GOOD ( 15.03 ) 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: linux-pci , Lorenzo Pieralisi , Sinan Kaya , linux-arm-kernel , Ard Biesheuvel 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 Fri, Jun 14, 2019 at 11:48:18PM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2019-06-14 at 08:12 -0500, Bjorn Helgaas wrote: > > On Fri, Jun 14, 2019 at 08:43:19PM +1000, Benjamin Herrenschmidt > > wrote: > > > > > This least to another conversation we hinted at earlier.. we should > > > probably have a way to do the same at least for BARs on ACPI > > > systems so > > > we don't have to temporarily disable access to a device to size > > > them. > > > > The PCI Enhanced Allocation capability provides a way to do this. I > > don't know how widely used it is, but it's theoretically possible. > > Ok, I have to read about this. I haven't seen a device with that on > yet, it looks messy at a quick glance. > > Can ACPI convey the information ? On powerpc and sparc64 we have ways > to read the BAR values from the device-tree created by OF when it > assigned them. I agree, EA is messy. I don't think it's feasible to do this in ACPI. It's a pretty fundamental principle of PCI that you can discover what resources a device needs and uses by looking at its config space. In general PCIe requires ECAM, which gives the OS direct access to config space, although it does allow exceptions for architecture-specific firmware interfaces for accessing config space, e.g., ia64 SAL (PCIe r4.0, sec 7.2.2). Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel