From: Bjorn Helgaas <helgaas@kernel.org>
To: Vidya Sagar <vidyas@nvidia.com>
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
Date: Thu, 22 Feb 2024 11:06:41 -0600 [thread overview]
Message-ID: <20240222170641.GA15593@bhelgaas> (raw)
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);
> + }
next prev parent reply other threads:[~2024-02-22 17:06 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 3:07 [PATCH V2 0/2] Add support to preserve boot config in the DT flow Vidya Sagar
2024-01-10 3:07 ` [PATCH V2 1/2] dt-bindings: Add PCIe "preserve-boot-config" property Vidya Sagar
2024-01-12 14:33 ` Rob Herring
2024-01-10 3:07 ` [PATCH V2 2/2] PCI: Add support for " Vidya Sagar
2024-01-12 16:58 ` Bjorn Helgaas
2024-01-15 14:32 ` Vidya Sagar
2024-01-16 16:55 ` Rob Herring
2024-01-19 17:31 ` Bjorn Helgaas
2024-01-12 16:59 ` Bjorn Helgaas
2024-02-22 12:41 ` [PATCH V3] PCI: Add support for preserving boot configuration Vidya Sagar
2024-02-22 17:06 ` Bjorn Helgaas [this message]
2024-02-22 21:18 ` Vidya Sagar
2024-02-22 22:08 ` Bjorn Helgaas
2024-02-23 8:00 ` [PATCH V4] " Vidya Sagar
2024-03-05 14:10 ` Rob Herring
2024-03-05 14:24 ` Rob Herring
2024-04-01 7:50 ` [PATCH V5] " Vidya Sagar
2024-04-02 16:01 ` Rob Herring
2024-04-10 7:44 ` Vidya Sagar
2024-04-10 20:50 ` Bjorn Helgaas
2024-04-18 17:31 ` Vidya Sagar
2024-04-18 17:40 ` [PATCH V6] " Vidya Sagar
2024-04-21 19:03 ` Bjorn Helgaas
2024-04-21 19:09 ` [PATCH v7-incomplete 0/3] " Bjorn Helgaas
2024-04-21 19:09 ` [PATCH v7-incomplete 1/3] PCI: Move PRESERVE_BOOT_CONFIG _DSM evaluation to pci_register_host_bridge() Bjorn Helgaas
2024-04-22 7:45 ` Andy Shevchenko
2024-04-21 19:09 ` [PATCH v7-incomplete 2/3] PCI: of: Add of_pci_preserve_config() for per-host bridge support Bjorn Helgaas
2024-04-21 19:09 ` [PATCH v7-incomplete 3/3] PCI: Unify ACPI and DT 'preserve config' support Bjorn Helgaas
2024-04-22 7:43 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240222170641.GA15593@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=kthota@nvidia.com \
--cc=kw@linux.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mmaddireddy@nvidia.com \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=sagar.tv@gmail.com \
--cc=treding@nvidia.com \
--cc=vidyas@nvidia.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).