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.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 6F242C5B57D for ; Wed, 3 Jul 2019 01:18:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4840F20673 for ; Wed, 3 Jul 2019 01:18:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562116701; bh=qg21pARqRrGiqzp8oVFATV/rRvwdeZy0ZvC+FpGJras=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=AhOtobrZehKX7PmrSIeH/s25yiZutIpiKQjdJk6DdO5xZH2knIL8jrN1OYfvhxQh9 CpVUpvDiX/BSUaUhnTs1mt74/Y+XgiMVO3L5yCLEbsgoWKHwB1ub/p8v9ZnxTfuuKV r6x3hckrXgz4jwmuf2B6UKOU7fGEjXfIXIOI6slU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727360AbfGCBST (ORCPT ); Tue, 2 Jul 2019 21:18:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:59100 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727377AbfGCBSF (ORCPT ); Tue, 2 Jul 2019 21:18:05 -0400 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 75DB3218D9; Tue, 2 Jul 2019 21:39:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562103594; bh=qg21pARqRrGiqzp8oVFATV/rRvwdeZy0ZvC+FpGJras=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AdDH7F2UwNKk7hs8XFn48mBnJYW3tekpy49ww101NDf6ClrVP8HVoVh9ZXMduwfGI 4c9zuOtndSvhsQmRkGPnlQJT1IUNR1jMFyb0erLoU6mlKMKP/lZCGuiIKyloixILC7 QSoakQtXMIafoY2n2pzNdlCTaF9hR/xp3U/7j5RQ= Date: Tue, 2 Jul 2019 16:39:51 -0500 From: Bjorn Helgaas To: Nicholas Johnson Cc: Logan Gunthorpe , Benjamin Herrenschmidt , "linux-pci@vger.kernel.org" Subject: Re: Multitude of resource assignment functions Message-ID: <20190702213951.GF128603@google.com> References: <024eec86-dfb9-0a23-6385-9e8dfe9a0381@deltatee.com> <442c6b35a1aab9833fd2942b499d4fb082a71a15.camel@kernel.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Sun, Jun 30, 2019 at 02:57:37AM +0000, Nicholas Johnson wrote: > - Should pci=noacpi imply pci=nocrs? It does not appear to, and I feel > like it should, as CRS is part of ACPI and relates to PCI. "pci=noacpi" means "Do not use ACPI for IRQ routing or for PCI scanning." "pci=nocrs" means "Ignore PCI host bridge windows from ACPI." If we ignore _CRS, we have no idea what the PCI host bridge apertures are, so we cannot allocate resources for devices on the root bus. The "Do not use ACPI for ... PCI scanning" part indeed does suggest that "pci=noacpi" could imply "pci=nocrs", but I don't think there's anything to be gained by changing that now. We probably *should* remove "or for PCI scanning" from the documentation, because "pci=noacpi" only affects IRQs. The only reason these exist at all is as a debugging aid to temporarily work around issues in firmware or Linux until we can develop a real fix or quirk that works without the user specifying a kernel parameter. > - Does anybody know why with pci=noacpi, you get dmesg warnings about > cannot find PCI int A mapping - but they do not seem to cause the > devices any issues in functioning? Is it because they are using MSI? I doubt it. I think you're just lucky. In general the information from _PRT and _CRS is essential for correct operation. > - Does pci=ignorefw sound good for a future proposal? No, at least not without more description of what this would accomplish. It sounds like you would want this to turn off _PRT, _CRS, and other information from ACPI. You may not like ACPI, but that information is there for good reason, and if we didn't get it from ACPI we would have to get it from somewhere else. There is always "acpi=off" if you just don't want ACPI at all. Bjorn