From: Ard Biesheuvel <ard.biesheuvel@linaro.org> To: linux-efi@vger.kernel.org, Ingo Molnar <mingo@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, "H . Peter Anvin" <hpa@zytor.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer Date: Tue, 4 Apr 2017 17:02:38 +0100 [thread overview] Message-ID: <20170404160245.27812-5-ard.biesheuvel@linaro.org> (raw) In-Reply-To: <20170404160245.27812-1-ard.biesheuvel@linaro.org> On UEFI systems, the PCI subsystem is enumerated by the firmware, and if a graphical framebuffer is exposed by a PCI device, its base address and size are exposed to the OS via the Graphics Output Protocol (GOP). On arm64 PCI systems, the entire PCI hierarchy is reconfigured from scratch at boot. This may result in the GOP framebuffer address to become stale, if the BAR covering the framebuffer is modified. This will cause the framebuffer to become unresponsive, and may in some cases result in unpredictable behavior if the range is reassigned to another device. So add a non-x86 quirk to the EFI fb driver to find the BAR associated with the GOP base address, and claim the BAR resource so that the PCI core will not move it. Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...") Cc: <stable@vger.kernel.org> # v4.7+ Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> --- drivers/video/fbdev/efifb.c | 66 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 65 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index 8c4dc1e1f94f..758960b6aec9 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -10,6 +10,7 @@ #include <linux/efi.h> #include <linux/errno.h> #include <linux/fb.h> +#include <linux/pci.h> #include <linux/platform_device.h> #include <linux/screen_info.h> #include <video/vga.h> @@ -143,6 +144,8 @@ static struct attribute *efifb_attrs[] = { }; ATTRIBUTE_GROUPS(efifb); +static bool pci_dev_disabled; /* FB base matches BAR of a disabled device */ + static int efifb_probe(struct platform_device *dev) { struct fb_info *info; @@ -152,7 +155,7 @@ static int efifb_probe(struct platform_device *dev) unsigned int size_total; char *option = NULL; - if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI) + if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled) return -ENODEV; if (fb_get_options("efifb", &option)) @@ -360,3 +363,64 @@ static struct platform_driver efifb_driver = { }; builtin_platform_driver(efifb_driver); + +#ifndef CONFIG_X86 + +static bool pci_bar_found; /* did we find a BAR matching the efifb base? */ + +static void claim_efifb_bar(struct pci_dev *dev, int idx) +{ + u16 word; + + pci_bar_found = true; + + pci_read_config_word(dev, PCI_COMMAND, &word); + if (!(word & PCI_COMMAND_MEMORY)) { + pci_dev_disabled = true; + dev_err(&dev->dev, + "BAR %d: assigned to efifb but device is disabled!\n", + idx); + return; + } + + if (pci_claim_resource(dev, idx)) { + pci_dev_disabled = true; + dev_err(&dev->dev, + "BAR %d: failed to claim resource for efifb!\n", idx); + return; + } + + dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx); +} + +static void efifb_fixup_resources(struct pci_dev *dev) +{ + u64 base = screen_info.lfb_base; + u64 size = screen_info.lfb_size; + int i; + + if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI) + return; + + if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE) + base |= (u64)screen_info.ext_lfb_base << 32; + + if (!base) + return; + + for (i = 0; i < PCI_STD_RESOURCE_END; i++) { + struct resource *res = &dev->resource[i]; + + if (!(res->flags & IORESOURCE_MEM)) + continue; + + if (res->start <= base && res->end >= base + size - 1) { + claim_efifb_bar(dev, i); + break; + } + } +} +DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY, + 16, efifb_fixup_resources); + +#endif -- 2.9.3
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> To: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>, "H . Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> Cc: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer Date: Tue, 4 Apr 2017 17:02:38 +0100 [thread overview] Message-ID: <20170404160245.27812-5-ard.biesheuvel@linaro.org> (raw) In-Reply-To: <20170404160245.27812-1-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> On UEFI systems, the PCI subsystem is enumerated by the firmware, and if a graphical framebuffer is exposed by a PCI device, its base address and size are exposed to the OS via the Graphics Output Protocol (GOP). On arm64 PCI systems, the entire PCI hierarchy is reconfigured from scratch at boot. This may result in the GOP framebuffer address to become stale, if the BAR covering the framebuffer is modified. This will cause the framebuffer to become unresponsive, and may in some cases result in unpredictable behavior if the range is reassigned to another device. So add a non-x86 quirk to the EFI fb driver to find the BAR associated with the GOP base address, and claim the BAR resource so that the PCI core will not move it. Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...") Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v4.7+ Cc: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> Cc: Peter Jones <pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> --- drivers/video/fbdev/efifb.c | 66 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 65 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index 8c4dc1e1f94f..758960b6aec9 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -10,6 +10,7 @@ #include <linux/efi.h> #include <linux/errno.h> #include <linux/fb.h> +#include <linux/pci.h> #include <linux/platform_device.h> #include <linux/screen_info.h> #include <video/vga.h> @@ -143,6 +144,8 @@ static struct attribute *efifb_attrs[] = { }; ATTRIBUTE_GROUPS(efifb); +static bool pci_dev_disabled; /* FB base matches BAR of a disabled device */ + static int efifb_probe(struct platform_device *dev) { struct fb_info *info; @@ -152,7 +155,7 @@ static int efifb_probe(struct platform_device *dev) unsigned int size_total; char *option = NULL; - if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI) + if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled) return -ENODEV; if (fb_get_options("efifb", &option)) @@ -360,3 +363,64 @@ static struct platform_driver efifb_driver = { }; builtin_platform_driver(efifb_driver); + +#ifndef CONFIG_X86 + +static bool pci_bar_found; /* did we find a BAR matching the efifb base? */ + +static void claim_efifb_bar(struct pci_dev *dev, int idx) +{ + u16 word; + + pci_bar_found = true; + + pci_read_config_word(dev, PCI_COMMAND, &word); + if (!(word & PCI_COMMAND_MEMORY)) { + pci_dev_disabled = true; + dev_err(&dev->dev, + "BAR %d: assigned to efifb but device is disabled!\n", + idx); + return; + } + + if (pci_claim_resource(dev, idx)) { + pci_dev_disabled = true; + dev_err(&dev->dev, + "BAR %d: failed to claim resource for efifb!\n", idx); + return; + } + + dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx); +} + +static void efifb_fixup_resources(struct pci_dev *dev) +{ + u64 base = screen_info.lfb_base; + u64 size = screen_info.lfb_size; + int i; + + if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI) + return; + + if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE) + base |= (u64)screen_info.ext_lfb_base << 32; + + if (!base) + return; + + for (i = 0; i < PCI_STD_RESOURCE_END; i++) { + struct resource *res = &dev->resource[i]; + + if (!(res->flags & IORESOURCE_MEM)) + continue; + + if (res->start <= base && res->end >= base + size - 1) { + claim_efifb_bar(dev, i); + break; + } + } +} +DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY, + 16, efifb_fixup_resources); + +#endif -- 2.9.3
next prev parent reply other threads:[~2017-04-04 16:03 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-04 16:02 [GIT PULL 00/12] EFI updates for v4.12 Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 1/2] efi/libstub: Skip GOP with PIXEL_BLT_ONLY format Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 01/12] x86/efi: Clean up efi CR3 save/restore Ard Biesheuvel 2017-04-05 8:51 ` [tip:efi/core] x86/efi: Clean up the EFI CR3 save/restore logic tip-bot for Andy Lutomirski 2017-04-04 16:02 ` [PATCH 02/12] efi: arm-stub: Correct FDT and initrd allocation rules for arm64 Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-05 8:52 ` [tip:efi/core] efi/arm-stub: " tip-bot for Ard Biesheuvel 2017-04-05 10:33 ` tip-bot for Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel [this message] 2017-04-04 16:02 ` [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 03/12] efi: arm-stub: Round up FDT allocation to mapping size Ard Biesheuvel 2017-04-05 8:53 ` [tip:efi/core] efi/arm-stub: " tip-bot for Ard Biesheuvel 2017-04-05 10:34 ` tip-bot for Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 04/12] x86/efi-bgrt: Move efi-bgrt handling out of arch/x86 Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-05 8:53 ` [tip:efi/core] x86/efi/bgrt: " tip-bot for Bhupesh Sharma 2017-04-05 10:34 ` tip-bot for Bhupesh Sharma 2017-04-04 16:02 ` [PATCH 05/12] efi: bgrt: Enable ACPI BGRT handling on arm64 Ard Biesheuvel 2017-04-05 8:54 ` [tip:efi/core] efi/bgrt: " tip-bot for Bhupesh Sharma 2017-04-05 10:35 ` tip-bot for Bhupesh Sharma 2017-04-04 16:02 ` [PATCH 06/12] pstore: return error code (if any) from efi_pstore_write Ard Biesheuvel 2017-04-05 8:54 ` [tip:efi/core] efi/pstore: Return error code (if any) from efi_pstore_write() tip-bot for Evgeny Kalugin 2017-04-05 10:35 ` tip-bot for Evgeny Kalugin 2017-04-04 16:02 ` [PATCH 07/12] x86/efi: Clean up a minor mistake in code comment Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-05 8:55 ` [tip:efi/core] x86/efi: Clean up a minor mistake in comment tip-bot for Baoquan He 2017-04-05 10:36 ` tip-bot for Baoquan He 2017-04-04 16:02 ` [PATCH 08/12] efi/arm32-stub: Allow boottime allocations in the vmlinux region Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-05 8:55 ` [tip:efi/core] efi/arm32-stub: Allow boot-time " tip-bot for Ard Biesheuvel 2017-04-05 10:36 ` tip-bot for Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 09/12] efi/libstub: Fix harmless command line parsing bug Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 2017-04-05 8:56 ` [tip:efi/core] " tip-bot for Ard Biesheuvel 2017-04-05 10:37 ` tip-bot for Ard Biesheuvel 2017-04-04 16:06 ` [GIT PULL 00/12] EFI updates for v4.12 Ard Biesheuvel 2017-04-04 16:09 ` [PATCH 10/12] efi/libstub: Unify command line param parsing Ard Biesheuvel 2017-04-04 16:09 ` Ard Biesheuvel 2017-04-04 16:09 ` [PATCH 11/12] efi/libstub: arm/arm64: Disable debug prints on 'quiet' cmdline arg Ard Biesheuvel 2017-04-05 8:57 ` [tip:efi/core] efi/libstub/arm/arm64: " tip-bot for Ard Biesheuvel 2017-04-05 10:38 ` tip-bot for Ard Biesheuvel 2017-04-11 4:08 ` [PATCH 11/12] efi/libstub: arm/arm64: " Jon Masters 2017-04-04 16:09 ` [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region Ard Biesheuvel 2017-04-04 16:09 ` Ard Biesheuvel 2017-04-05 8:57 ` [tip:efi/core] ef/libstub/arm/arm64: " tip-bot for Ard Biesheuvel 2017-04-05 10:39 ` tip-bot for Ard Biesheuvel 2017-04-07 15:58 ` [PATCH 12/12] ef/libstub: arm/arm64: " Catalin Marinas 2017-04-07 15:58 ` Catalin Marinas 2017-04-07 16:02 ` Ard Biesheuvel 2017-04-07 16:02 ` Ard Biesheuvel 2017-04-05 8:56 ` [tip:efi/core] efi/libstub: Unify command line param parsing tip-bot for Ard Biesheuvel 2017-04-05 10:38 ` tip-bot for Ard Biesheuvel -- strict thread matches above, loose matches on Subject: below -- 2017-04-04 15:27 [GIT PULL 0/2] EFI fixes for v4.11 Ard Biesheuvel 2017-04-04 15:27 ` [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer Ard Biesheuvel 2017-05-19 16:27 ` Bjorn Helgaas 2017-05-19 16:37 ` Ard Biesheuvel 2017-05-19 16:37 ` Ard Biesheuvel 2017-05-19 20:44 ` Bjorn Helgaas 2017-05-19 22:04 ` Ard Biesheuvel 2017-05-19 22:04 ` Ard Biesheuvel
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=20170404160245.27812-5-ard.biesheuvel@linaro.org \ --to=ard.biesheuvel@linaro.org \ --cc=hpa@zytor.com \ --cc=linux-efi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@kernel.org \ --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: linkBe 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.