All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: linux-efi@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	linux-kernel@vger.kernel.org,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Young <dyoung@redhat.com>,
	Saravana Kannan <saravanak@google.com>
Subject: [PATCH 08/13] efi/arm: defer probe of PCIe backed efifb on DT systems
Date: Mon, 13 Jan 2020 18:22:40 +0100	[thread overview]
Message-ID: <20200113172245.27925-9-ardb@kernel.org> (raw)
In-Reply-To: <20200113172245.27925-1-ardb@kernel.org>

The new of_devlink support breaks PCIe probing on ARM platforms booting
via UEFI if the firmware exposes a EFI framebuffer that is backed by a
PCI device. The reason is that the probing order gets reversed,
resulting in a resource conflict on the framebuffer memory window when
the PCIe probes last, causing it to give up entirely.

Given that we rely on PCI quirks to deal with EFI framebuffers that get
moved around in memory, we cannot simply drop the memory reservation, so
instead, let's use the device link infrastructure to register this
dependency, and force the probing to occur in the expected order.

Co-developed-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 drivers/firmware/efi/arm-init.c | 107 ++++++++++++++++++++++++++++++--
 1 file changed, 103 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 904fa09e6a6b..d99f5b0c8a09 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -10,10 +10,12 @@
 #define pr_fmt(fmt)	"efi: " fmt
 
 #include <linux/efi.h>
+#include <linux/fwnode.h>
 #include <linux/init.h>
 #include <linux/memblock.h>
 #include <linux/mm_types.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/of_fdt.h>
 #include <linux/platform_device.h>
 #include <linux/screen_info.h>
@@ -276,15 +278,112 @@ void __init efi_init(void)
 		efi_memmap_unmap();
 }
 
+static bool efifb_overlaps_pci_range(const struct of_pci_range *range)
+{
+	u64 fb_base = screen_info.lfb_base;
+
+	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
+		fb_base |= (u64)(unsigned long)screen_info.ext_lfb_base << 32;
+
+	return fb_base >= range->cpu_addr &&
+	       fb_base < (range->cpu_addr + range->size);
+}
+
+static struct device_node *find_pci_overlap_node(void)
+{
+	struct device_node *np;
+
+	for_each_node_by_type(np, "pci") {
+		struct of_pci_range_parser parser;
+		struct of_pci_range range;
+		int err;
+
+		err = of_pci_range_parser_init(&parser, np);
+		if (err) {
+			pr_warn("of_pci_range_parser_init() failed: %d\n", err);
+			continue;
+		}
+
+		for_each_of_pci_range(&parser, &range)
+			if (efifb_overlaps_pci_range(&range))
+				return np;
+	}
+	return NULL;
+}
+
+/*
+ * If the efifb framebuffer is backed by a PCI graphics controller, we have
+ * to ensure that this relation is expressed using a device link when
+ * running in DT mode, or the probe order may be reversed, resulting in a
+ * resource reservation conflict on the memory window that the efifb
+ * framebuffer steals from the PCIe host bridge.
+ */
+static int efifb_add_links(const struct fwnode_handle *fwnode,
+			   struct device *dev)
+{
+	struct device_node *sup_np;
+	struct device *sup_dev;
+
+	sup_np = find_pci_overlap_node();
+
+	/*
+	 * If there's no PCI graphics controller backing the efifb, we are
+	 * done here.
+	 */
+	if (!sup_np)
+		return 0;
+
+	sup_dev = get_dev_from_fwnode(&sup_np->fwnode);
+	of_node_put(sup_np);
+
+	/*
+	 * Return -ENODEV if the PCI graphics controller device hasn't been
+	 * registered yet.  This ensures that efifb isn't allowed to probe
+	 * and this function is retried again when new devices are
+	 * registered.
+	 */
+	if (!sup_dev)
+		return -ENODEV;
+
+	/*
+	 * If this fails, retrying this function at a later point won't
+	 * change anything. So, don't return an error after this.
+	 */
+	if (!device_link_add(dev, sup_dev, 0))
+		dev_warn(dev, "device_link_add() failed\n");
+
+	put_device(sup_dev);
+
+	return 0;
+}
+
+static const struct fwnode_operations efifb_fwnode_ops = {
+	.add_links = efifb_add_links,
+};
+
+static struct fwnode_handle efifb_fwnode = {
+	.ops = &efifb_fwnode_ops,
+};
+
 static int __init register_gop_device(void)
 {
-	void *pd;
+	struct platform_device *pd;
+	int err;
 
 	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
 		return 0;
 
-	pd = platform_device_register_data(NULL, "efi-framebuffer", 0,
-					   &screen_info, sizeof(screen_info));
-	return PTR_ERR_OR_ZERO(pd);
+	pd = platform_device_alloc("efi-framebuffer", 0);
+	if (!pd)
+		return -ENOMEM;
+
+	if (IS_ENABLED(CONFIG_PCI))
+		pd->dev.fwnode = &efifb_fwnode;
+
+	err = platform_device_add_data(pd, &screen_info, sizeof(screen_info));
+	if (err)
+		return err;
+
+	return platform_device_add(pd);
 }
 subsys_initcall(register_gop_device);
-- 
2.20.1


  parent reply	other threads:[~2020-01-13 17:23 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13 17:22 [GIT PULL 00/13] More EFI updates for v5.6 Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 01/13] efi/libstub/x86: use const attribute for efi_is_64bit() Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 02/13] efi/libstub/x86: use mandatory 16-byte stack alignment in mixed mode Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 03/13] efi/libstub/x86: fix unused-variable warning Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 04/13] x86/mm: fix NX bit clearing issue in kernel_map_pages_in_pgd Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 05/13] efi/x86: don't map the entire kernel text RW for mixed mode Ard Biesheuvel
2020-04-08 10:42   ` Jiri Slaby
2020-04-08 10:47     ` Ard Biesheuvel
2020-04-08 10:51       ` Jiri Slaby
2020-04-09  7:51         ` Ard Biesheuvel
2020-04-09  8:06           ` Gary Lin
2020-04-09  8:10             ` Jiri Slaby
2020-04-09  8:19               ` Ard Biesheuvel
2020-04-09  8:34                 ` Jiri Slaby
2020-04-09  9:09                   ` Ard Biesheuvel
2020-04-09  9:45                     ` Ard Biesheuvel
2020-04-09 10:09                     ` Jiri Slaby
2020-04-09 10:45                       ` Ard Biesheuvel
2020-04-09 11:08                         ` Ard Biesheuvel
2020-04-09 11:25                           ` Ard Biesheuvel
2020-04-09 11:32                             ` Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 06/13] efi/x86: avoid RWX mappings for all of DRAM Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 07/13] efi/x86: limit EFI old memory map to SGI UV machines Ard Biesheuvel
2020-01-13 17:22 ` Ard Biesheuvel [this message]
2020-01-13 17:22 ` [PATCH 09/13] efi: Fix comment for efi_mem_type() wrt absent physical addresses Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 10/13] efi: Add a flags parameter to efi_memory_map Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 11/13] efi: Add tracking for dynamically allocated memmaps Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 12/13] efi: Fix efi_memmap_alloc() leaks Ard Biesheuvel
2020-01-13 17:22 ` [PATCH 13/13] efi: Fix handling of multiple efi_fake_mem= entries Ard Biesheuvel
2020-01-20  8:25 ` [GIT PULL 00/13] More EFI updates for v5.6 Ingo Molnar
2020-01-20  8:45   ` Ard Biesheuvel
2020-01-22  7:03     ` Ingo Molnar

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=20200113172245.27925-9-ardb@kernel.org \
    --to=ardb@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=arnd@arndb.de \
    --cc=dan.j.williams@intel.com \
    --cc=dyoung@redhat.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=saravanak@google.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.