From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3A3C715099F; Thu, 22 Feb 2024 17:06:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708621604; cv=none; b=kswNrQDrVARku7F8IK9dDiqbiristj14HmZihWpgrYn4PcO5FoM2fYxg8qihpzYw6mLFV9PafF+jUoEbyQGxsItbg1j95tilD3brUBiYLfHq1r6EHwwXW98v1gSvmX41N5lcTi4krVo3vrt7CQBgDq+IZ1CwmQV2K378igfsfEQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708621604; c=relaxed/simple; bh=kE8TIXCP4omiH8Tb48QLZ4vtCQlIIcYaY2PACwfRHLU=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; b=PXA93MwD/OdzL+FQOQgzWsH6W7CUa0KVCL6dkosrFMrtcALwmOscIayTgaSUL9i4jbbFTSRBUx1GCeO+9MDVX2VAQ68qHtDrZQ7XUMR+x7jdgR/9eYp1SQimodLGt31HTOv7Rq5GBoAFJqbIIX5G8YL5WLXYUf9z0AF4+3IciJ4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qMv3dQYD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qMv3dQYD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5688BC433C7; Thu, 22 Feb 2024 17:06:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708621603; bh=kE8TIXCP4omiH8Tb48QLZ4vtCQlIIcYaY2PACwfRHLU=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=qMv3dQYDhbkA55iCtTxciIgE1L7pMg9o9uWTVAV+VOYkCajdj9ypNeK3dAMJjedon Yfm16dXgjEDaJvw7MKL3T1NUQJuoykxKJy3QBBvO7KjZn6mhHuhTJGHvovxIKU2zrR zDIG+iHYedR7cXvE6GdAAvt5KB235VxZ/Plmw5wAIXTGdCIAdrxI/gYIsiztfOlUMO sRy4h/QB7EziUrqeYVH8Xhch+hYzriJXTd6xGKvdtvOfJu8/ojjSIEqc2no6ipAGbJ +fGCcGAK0vbTCM29gk3bUyqBGrb/tWnTENLA+Bk37mXCqwO4TnK5iKODRwQgZELV7b cavlvjo3SyKpg== Date: Thu, 22 Feb 2024 11:06:41 -0600 From: Bjorn Helgaas To: Vidya Sagar Cc: bhelgaas@google.com, rafael@kernel.org, lenb@kernel.org, will@kernel.org, lpieralisi@kernel.org, kw@linux.com, robh@kernel.org, frowand.list@gmail.com, linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, treding@nvidia.com, jonathanh@nvidia.com, kthota@nvidia.com, mmaddireddy@nvidia.com, sagar.tv@gmail.com Subject: Re: [PATCH V3] PCI: Add support for preserving boot configuration Message-ID: <20240222170641.GA15593@bhelgaas> Precedence: bulk X-Mailing-List: linux-acpi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240222124110.2681455-1-vidyas@nvidia.com> On Thu, Feb 22, 2024 at 06:11:10PM +0530, Vidya Sagar wrote: > Add support for preserving the boot configuration done by the > platform firmware per host bridge basis, based on the presence of > 'linux,pci-probe-only' property in the respective PCIe host bridge > device-tree node. It also unifies the ACPI and DT based boot flows > in this regard. > +/** > + * of_pci_bridge_check_probe_only - Return true if the boot configuration > + * needs to be preserved I don't like the "check_probe_only" name because it's a boolean function but the name doesn't tell me what a true/false return value means. Something like "preserve_resources" would be better. If you want "probe_only", even removing the "check" would help. > + * @node: Device tree node with the domain information. > + * > + * This function looks for "linux,pci-probe-only" property for a given > + * PCIe controller's node and returns true if found. Having this property > + * for a PCIe controller ensures that the kernel doesn't re-enumerate and > + * reconfigure the BAR resources that are already done by the platform firmware. This is generic PCI, not PCIe-specific (also in commit log and comment below). I think "enumeration" specifically refers to discovering what devices are present, and the kernel always does that, so drop that part. Reconfiguring BARs and bridge windows is what we want to prevent. > + * NOTE: The scope of "linux,pci-probe-only" defined within a PCIe bridge device > + * is limited to the hierarchy under that particular bridge device. whereas > + * the scope of "linux,pci-probe-only" defined within chosen node is > + * system wide. > + * > + * Return: true if the property exists false otherwise. > + */ > +bool of_pci_bridge_check_probe_only(struct device_node *node) > +{ > + return of_property_read_bool(node, "linux,pci-probe-only"); > +} > +EXPORT_SYMBOL_GPL(of_pci_bridge_check_probe_only); Why does this need to be exported for modules and exposed via include/linux/pci.h? > +static void pci_check_config_preserve(struct pci_host_bridge *host_bridge) > +{ > + if (&host_bridge->dev) { Checking &host_bridge->dev doesn't seem like the right way to determine whether this is an ACPI host bridge. > + union acpi_object *obj; > + > + /* > + * Evaluate the "PCI Boot Configuration" _DSM Function. If it > + * exists and returns 0, we must preserve any PCI resource > + * assignments made by firmware for this host bridge. > + */ > + obj = acpi_evaluate_dsm(ACPI_HANDLE(&host_bridge->dev), &pci_acpi_dsm_guid, 1, > + DSM_PCI_PRESERVE_BOOT_CONFIG, NULL); > + if (obj && obj->type == ACPI_TYPE_INTEGER && obj->integer.value == 0) > + host_bridge->preserve_config = 1; > + ACPI_FREE(obj); > + } 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 14D24C54791 for ; Thu, 22 Feb 2024 17:07:12 +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=YruEgYz3c4KM6H6OdkZ/+OvVUTF10wJRh3rnLFCit5g=; b=mcWh1oClSWqYiR Aib3n+T/PJ2UlDGhHerg+6srWyuHcDUXGPf8VHAo6nOAe47CAx2HxSkQebEfdlIORvUBZkDe/o6W9 0hrBvFXHJcvkxoM9zFvt5xS1YIacl9UbsCPizM5uMEfhKXQKBV6E6brgGWcLPMnqrJD/Nipi5mrVu N1ln5mvVdbYFpAWwVZdRVPdkdv+sWYyL3vpdPlDhF7VuwzQ9/KwxJWDo0qrr3uflUj8cKe67vjM3j 4fwgxRCBv/kxJ0wCvtDiANEYzEzr547Q+lWNC781Kpqlp6ORehcWCTX7usUZX+Sd2mi6Hay7/jv15 hfCZRVLveVCpl0GyMiMg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rdCX1-00000005ij3-2ePK; Thu, 22 Feb 2024 17:06:47 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rdCWy-00000005iiG-3sFd for linux-arm-kernel@lists.infradead.org; Thu, 22 Feb 2024 17:06:46 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id EF6AB618EE; Thu, 22 Feb 2024 17:06:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5688BC433C7; Thu, 22 Feb 2024 17:06:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708621603; bh=kE8TIXCP4omiH8Tb48QLZ4vtCQlIIcYaY2PACwfRHLU=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=qMv3dQYDhbkA55iCtTxciIgE1L7pMg9o9uWTVAV+VOYkCajdj9ypNeK3dAMJjedon Yfm16dXgjEDaJvw7MKL3T1NUQJuoykxKJy3QBBvO7KjZn6mhHuhTJGHvovxIKU2zrR zDIG+iHYedR7cXvE6GdAAvt5KB235VxZ/Plmw5wAIXTGdCIAdrxI/gYIsiztfOlUMO sRy4h/QB7EziUrqeYVH8Xhch+hYzriJXTd6xGKvdtvOfJu8/ojjSIEqc2no6ipAGbJ +fGCcGAK0vbTCM29gk3bUyqBGrb/tWnTENLA+Bk37mXCqwO4TnK5iKODRwQgZELV7b cavlvjo3SyKpg== Date: Thu, 22 Feb 2024 11:06:41 -0600 From: Bjorn Helgaas To: Vidya Sagar Cc: bhelgaas@google.com, rafael@kernel.org, lenb@kernel.org, will@kernel.org, lpieralisi@kernel.org, kw@linux.com, robh@kernel.org, frowand.list@gmail.com, linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, treding@nvidia.com, jonathanh@nvidia.com, kthota@nvidia.com, mmaddireddy@nvidia.com, sagar.tv@gmail.com Subject: Re: [PATCH V3] PCI: Add support for preserving boot configuration Message-ID: <20240222170641.GA15593@bhelgaas> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240222124110.2681455-1-vidyas@nvidia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240222_090645_114084_76890716 X-CRM114-Status: GOOD ( 23.09 ) 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 Thu, Feb 22, 2024 at 06:11:10PM +0530, Vidya Sagar wrote: > Add support for preserving the boot configuration done by the > platform firmware per host bridge basis, based on the presence of > 'linux,pci-probe-only' property in the respective PCIe host bridge > device-tree node. It also unifies the ACPI and DT based boot flows > in this regard. > +/** > + * of_pci_bridge_check_probe_only - Return true if the boot configuration > + * needs to be preserved I don't like the "check_probe_only" name because it's a boolean function but the name doesn't tell me what a true/false return value means. Something like "preserve_resources" would be better. If you want "probe_only", even removing the "check" would help. > + * @node: Device tree node with the domain information. > + * > + * This function looks for "linux,pci-probe-only" property for a given > + * PCIe controller's node and returns true if found. Having this property > + * for a PCIe controller ensures that the kernel doesn't re-enumerate and > + * reconfigure the BAR resources that are already done by the platform firmware. This is generic PCI, not PCIe-specific (also in commit log and comment below). I think "enumeration" specifically refers to discovering what devices are present, and the kernel always does that, so drop that part. Reconfiguring BARs and bridge windows is what we want to prevent. > + * NOTE: The scope of "linux,pci-probe-only" defined within a PCIe bridge device > + * is limited to the hierarchy under that particular bridge device. whereas > + * the scope of "linux,pci-probe-only" defined within chosen node is > + * system wide. > + * > + * Return: true if the property exists false otherwise. > + */ > +bool of_pci_bridge_check_probe_only(struct device_node *node) > +{ > + return of_property_read_bool(node, "linux,pci-probe-only"); > +} > +EXPORT_SYMBOL_GPL(of_pci_bridge_check_probe_only); Why does this need to be exported for modules and exposed via include/linux/pci.h? > +static void pci_check_config_preserve(struct pci_host_bridge *host_bridge) > +{ > + if (&host_bridge->dev) { Checking &host_bridge->dev doesn't seem like the right way to determine whether this is an ACPI host bridge. > + union acpi_object *obj; > + > + /* > + * Evaluate the "PCI Boot Configuration" _DSM Function. If it > + * exists and returns 0, we must preserve any PCI resource > + * assignments made by firmware for this host bridge. > + */ > + obj = acpi_evaluate_dsm(ACPI_HANDLE(&host_bridge->dev), &pci_acpi_dsm_guid, 1, > + DSM_PCI_PRESERVE_BOOT_CONFIG, NULL); > + if (obj && obj->type == ACPI_TYPE_INTEGER && obj->integer.value == 0) > + host_bridge->preserve_config = 1; > + ACPI_FREE(obj); > + } _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel