From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Sinan Kaya <okaya@kernel.org>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
"Zilberman, Zeev" <zeev@amazon.com>,
"Saidi, Ali" <alisaidi@amazon.com>
Subject: Re: [PATCH/RESEND] arm64: acpi/pci: invoke _DSM whether to preserve firmware PCI setup
Date: Tue, 11 Jun 2019 15:58:32 +0100 [thread overview]
Message-ID: <20190611145832.GB11736@redmoon> (raw)
In-Reply-To: <d53fc77e1e754ddbd9af555ed5b344c5fa523154.camel@kernel.crashing.org>
On Thu, Jun 06, 2019 at 07:00:12PM +1000, Benjamin Herrenschmidt wrote:
> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> On arm64 ACPI systems, we unconditionally reconfigure the entire PCI
> hierarchy at boot. This is a departure from what is customary on ACPI
> systems, and may break assumptions in some places (e.g., EFIFB), that
> the kernel will leave BARs of enabled PCI devices where they are.
>
> Given that PCI already specifies a device specific ACPI method (_DSM)
> for PCI root bridge nodes that tells us whether the firmware thinks
> the configuration should be left alone, let's sidestep the entire
> policy debate about whether the PCI configuration should be preserved
> or not, and put it under the control of the firmware instead.
>
> [BenH: Added pci_assign_unassigned_root_bus_resources()]
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> So I would like this variant rather than mucking around with
> IORESOURCE_PCI_FIXED at this stage to fix the problem with our platforms.
>
> See my other email, IORESOURCE_PCI_FIXED doesn't really work terribly well
> when using pci_bus_size_bridges and pci_bus_assign_resources, and the
> resulting patches are ugly and add more mess.
>
> Long run, I propose to start working on consolidating all those various
> resource survey mechanisms around what x86 does, unless people strongly
> object... (with the addition of the probe only and force reassign quirks
> so platforms can still chose that).
>
> Note: I haven't tested the effect of pci_assign_unassigned_root_bus_resources
> as our platforms don't leave anything unassigned. I'm not entirely sure how
> well pci_bus_claim_resources() will deal with a partially assigned setup...
>
> We do want to support partial assignment by BIOS though, it's a trend to
> reduce boot time, people seem to want BIOSes to only assign what's critical
> for booting.
>
> Bjorn: I haven't made the claim path the default in absence of _DSM #5 yet.
> I suggest we do that as a separate patch in case it breaks somebody, thus
> making bisection more meaningful. It will also make this one more palatable
> to distros since it won't change the behaviour on systems without _DSM #5,
> and we verified nobody has it except Seattle which returns 1.
>
> arch/arm64/kernel/pci.c | 23 +++++++++++++++++++++--
> include/linux/pci-acpi.h | 7 ++++---
> 2 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index bb85e2f4603f..6358e1cb4f9f 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -168,6 +168,7 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> struct acpi_pci_generic_root_info *ri;
> struct pci_bus *bus, *child;
> struct acpi_pci_root_ops *root_ops;
> + union acpi_object *obj;
>
> ri = kzalloc(sizeof(*ri), GFP_KERNEL);
> if (!ri)
> @@ -193,8 +194,26 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> if (!bus)
> return NULL;
>
> - pci_bus_size_bridges(bus);
> - pci_bus_assign_resources(bus);
> + /*
> + * Invoke the PCI device specific method (_DSM) #5 'Ignore PCI Boot
> + * Configuration', which tells us whether the firmware wants us to
> + * preserve the configuration of the PCI resource tree for this root
> + * bridge.
> + */
> + obj = acpi_evaluate_dsm(ACPI_HANDLE(bus->bridge), &pci_acpi_dsm_guid, 1,
> + IGNORE_PCI_BOOT_CONFIG_DSM, NULL);
> + if (obj && obj->type == ACPI_TYPE_INTEGER && obj->integer.value == 0) {
> + /* preserve existing resource assignment */
> + pci_bus_claim_resources(bus);
> +
> + /* Assign anything that might have been left out */
> + pci_assign_unassigned_root_bus_resources(bus);
> + } else {
> + /* reconfigure the resource tree from scratch */
> + pci_bus_size_bridges(bus);
> + pci_bus_assign_resources(bus);
> + }
if (obj && obj->type == ACPI_TYPE_INTEGER && obj->integer.value == 0) {
/* preserve existing resource assignment */
pci_bus_claim_resources(bus);
}
pci_bus_size_bridges(bus);
pci_bus_assign_resources(bus);
That's how it should be I think:
1) we do not want pci_assign_unassigned_root_bus_resources(bus) to
reallocate resources already claimed (see realloc parameter), do we ?
2) pci_bus_size_bridges(bus) and pci_bus_assign_resources(bus) should
not interfere with resources already claimed so it *should* be safe
to call them anyway
Most importantly: I want everyone to agree that claiming is equivalent
to making a resource immutable (except for realloc, see (1) above)
because that's what we are doing by claiming on _DSM #5 == 0.
There are too many ways to make a resource immutable in the kernel
and this is confusing and prone to bugs.
Thanks,
Lorenzo
> + ACPI_FREE(obj);
>
> list_for_each_entry(child, &bus->children, node)
> pcie_bus_configure_settings(child);
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index 8082b612f561..62b7fdcc661c 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -107,9 +107,10 @@ static inline void acpiphp_check_host_bridge(struct acpi_device *adev) { }
> #endif
>
> extern const guid_t pci_acpi_dsm_guid;
> -#define DEVICE_LABEL_DSM 0x07
> -#define RESET_DELAY_DSM 0x08
> -#define FUNCTION_DELAY_DSM 0x09
> +#define IGNORE_PCI_BOOT_CONFIG_DSM 0x05
> +#define DEVICE_LABEL_DSM 0x07
> +#define RESET_DELAY_DSM 0x08
> +#define FUNCTION_DELAY_DSM 0x09
>
> #else /* CONFIG_ACPI */
> static inline void acpi_pci_add_bus(struct pci_bus *bus) { }
>
>
next prev parent reply other threads:[~2019-06-11 14:58 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 23:41 [RFC] ARM64 PCI resource survey issue(s) Benjamin Herrenschmidt
2019-06-04 1:49 ` Bjorn Helgaas
2019-06-04 3:32 ` Benjamin Herrenschmidt
2019-06-04 3:37 ` Benjamin Herrenschmidt
2019-06-04 6:56 ` Benjamin Herrenschmidt
2019-06-04 12:49 ` Bjorn Helgaas
2019-06-04 20:41 ` Benjamin Herrenschmidt
2019-06-06 9:00 ` [PATCH/RESEND] arm64: acpi/pci: invoke _DSM whether to preserve firmware PCI setup Benjamin Herrenschmidt
2019-06-06 9:13 ` Ard Biesheuvel
2019-06-06 10:55 ` Benjamin Herrenschmidt
2019-06-11 14:31 ` Lorenzo Pieralisi
2019-06-11 22:09 ` Benjamin Herrenschmidt
2019-06-11 22:34 ` Ard Biesheuvel
2019-06-11 22:40 ` Benjamin Herrenschmidt
2019-06-12 10:21 ` Lorenzo Pieralisi
2019-06-12 22:05 ` Benjamin Herrenschmidt
2019-06-11 14:58 ` Lorenzo Pieralisi [this message]
2019-06-11 22:19 ` Benjamin Herrenschmidt
2019-06-12 10:08 ` Lorenzo Pieralisi
2019-06-12 10:58 ` Benjamin Herrenschmidt
2019-06-11 23:39 ` Bjorn Helgaas
2019-06-12 0:06 ` Benjamin Herrenschmidt
2019-06-12 13:27 ` Bjorn Helgaas
2019-06-12 21:46 ` Benjamin Herrenschmidt
2019-06-12 23:58 ` Benjamin Herrenschmidt
2019-06-10 10:11 ` [RFC] ARM64 PCI resource survey issue(s) Lorenzo Pieralisi
2019-06-11 5:46 ` Benjamin Herrenschmidt
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=20190611145832.GB11736@redmoon \
--to=lorenzo.pieralisi@arm.com \
--cc=alisaidi@amazon.com \
--cc=ard.biesheuvel@linaro.org \
--cc=benh@kernel.crashing.org \
--cc=helgaas@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=okaya@kernel.org \
--cc=zeev@amazon.com \
/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).