* [GIT PULL 0/2] EFI fixes for v4.11 @ 2017-04-04 15:27 ` Ard Biesheuvel 0 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-04-04 15:27 UTC (permalink / raw) To: linux-efi, Ingo Molnar, Thomas Gleixner, H . Peter Anvin Cc: leif.lindholm, lorenzo.pieralisi, Ard Biesheuvel, linux-kernel, Eugene Cohen, Matt Fleming, Peter Jones Hello all, Please pull these fixes for EFI framebuffer support on ARM/arm64 systems. The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe: efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +0000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e: efifb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-04 15:56:43 +0100) ---------------------------------------------------------------- Two fixes related to the EFI framebuffer driver: - Ignore Graphics Output Protocol (GOP) implementations that are marked as BLT-only -- the framebuffer base address is invalid in this case, and the Blt() method is not accessible to the kernel. - If the GOP framebuffer base address coincides with a memory BAR of a PCI device that has memory decoding enabled, claim the memory resource so that the PCI core will not attempt to move it later on. ---------------------------------------------------------------- Ard Biesheuvel (1): efifb: Avoid reconfiguration of BAR that covers the framebuffer Cohen, Eugene (1): efi/libstub: Skip GOP with PIXEL_BLT_ONLY format drivers/firmware/efi/libstub/gop.c | 6 ++-- drivers/video/fbdev/efifb.c | 66 +++++++++++++++++++++++++++++++++++++- 2 files changed, 69 insertions(+), 3 deletions(-) ^ permalink raw reply [flat|nested] 23+ messages in thread
* [GIT PULL 0/2] EFI fixes for v4.11 @ 2017-04-04 15:27 ` Ard Biesheuvel 0 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-04-04 15:27 UTC (permalink / raw) To: linux-efi-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Thomas Gleixner, H . Peter Anvin Cc: leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, lorenzo.pieralisi-5wv7dgnIgG8, Ard Biesheuvel, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eugene Cohen, Matt Fleming, Peter Jones Hello all, Please pull these fixes for EFI framebuffer support on ARM/arm64 systems. The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe: efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +0000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e: efifb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-04 15:56:43 +0100) ---------------------------------------------------------------- Two fixes related to the EFI framebuffer driver: - Ignore Graphics Output Protocol (GOP) implementations that are marked as BLT-only -- the framebuffer base address is invalid in this case, and the Blt() method is not accessible to the kernel. - If the GOP framebuffer base address coincides with a memory BAR of a PCI device that has memory decoding enabled, claim the memory resource so that the PCI core will not attempt to move it later on. ---------------------------------------------------------------- Ard Biesheuvel (1): efifb: Avoid reconfiguration of BAR that covers the framebuffer Cohen, Eugene (1): efi/libstub: Skip GOP with PIXEL_BLT_ONLY format drivers/firmware/efi/libstub/gop.c | 6 ++-- drivers/video/fbdev/efifb.c | 66 +++++++++++++++++++++++++++++++++++++- 2 files changed, 69 insertions(+), 3 deletions(-) ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 1/2] efi/libstub: Skip GOP with PIXEL_BLT_ONLY format 2017-04-04 15:27 ` Ard Biesheuvel (?) @ 2017-04-04 15:27 ` Ard Biesheuvel 2017-04-05 7:57 ` [tip:efi/urgent] " tip-bot for Cohen, Eugene -1 siblings, 1 reply; 23+ messages in thread From: Ard Biesheuvel @ 2017-04-04 15:27 UTC (permalink / raw) To: linux-efi, Ingo Molnar, Thomas Gleixner, H . Peter Anvin Cc: leif.lindholm, lorenzo.pieralisi, Cohen, Eugene, Ard Biesheuvel, linux-kernel From: "Cohen, Eugene" <eugene@hp.com> The UEFI Specification permits Graphics Output Protocol (GOP) instances without direct framebuffer access. This is indicated in the Mode structure with a PixelFormat enumeration value of PIXEL_BLT_ONLY. Given that the kernel does not know how to drive a Blt() only framebuffer (which is only permitted before ExitBootServices() anyway), we should disregard such framebuffers when looking for a GOP instance that is suitable for use as the boot console. So modify the EFI GOP initialization to not use a PIXEL_BLT_ONLY instance, preventing attempts later in boot to use an invalid screen_info.lfb_base address. Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...") Signed-off-by: Eugene Cohen <eugene@hp.com> [ardb: - move Blt() only check into the loop - clarify that Blt() only GOPs are unusable by the kernel] Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> --- drivers/firmware/efi/libstub/gop.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/libstub/gop.c b/drivers/firmware/efi/libstub/gop.c index 932742e4cf23..24c461dea7af 100644 --- a/drivers/firmware/efi/libstub/gop.c +++ b/drivers/firmware/efi/libstub/gop.c @@ -149,7 +149,8 @@ setup_gop32(efi_system_table_t *sys_table_arg, struct screen_info *si, status = __gop_query32(sys_table_arg, gop32, &info, &size, ¤t_fb_base); - if (status == EFI_SUCCESS && (!first_gop || conout_found)) { + if (status == EFI_SUCCESS && (!first_gop || conout_found) && + info->pixel_format != PIXEL_BLT_ONLY) { /* * Systems that use the UEFI Console Splitter may * provide multiple GOP devices, not all of which are @@ -266,7 +267,8 @@ setup_gop64(efi_system_table_t *sys_table_arg, struct screen_info *si, status = __gop_query64(sys_table_arg, gop64, &info, &size, ¤t_fb_base); - if (status == EFI_SUCCESS && (!first_gop || conout_found)) { + if (status == EFI_SUCCESS && (!first_gop || conout_found) && + info->pixel_format != PIXEL_BLT_ONLY) { /* * Systems that use the UEFI Console Splitter may * provide multiple GOP devices, not all of which are -- 2.9.3 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [tip:efi/urgent] efi/libstub: Skip GOP with PIXEL_BLT_ONLY format 2017-04-04 15:27 ` [PATCH 1/2] efi/libstub: Skip GOP with PIXEL_BLT_ONLY format Ard Biesheuvel @ 2017-04-05 7:57 ` tip-bot for Cohen, Eugene 0 siblings, 0 replies; 23+ messages in thread From: tip-bot for Cohen, Eugene @ 2017-04-05 7:57 UTC (permalink / raw) To: linux-tip-commits Cc: ard.biesheuvel, peterz, mingo, torvalds, eugene, hpa, linux-kernel, tglx, matt Commit-ID: 540f4c0e894f7e46a66dfa424b16424cbdc12c38 Gitweb: http://git.kernel.org/tip/540f4c0e894f7e46a66dfa424b16424cbdc12c38 Author: Cohen, Eugene <eugene@hp.com> AuthorDate: Tue, 4 Apr 2017 16:27:43 +0100 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Wed, 5 Apr 2017 09:20:18 +0200 efi/libstub: Skip GOP with PIXEL_BLT_ONLY format The UEFI Specification permits Graphics Output Protocol (GOP) instances without direct framebuffer access. This is indicated in the Mode structure with a PixelFormat enumeration value of PIXEL_BLT_ONLY. Given that the kernel does not know how to drive a Blt() only framebuffer (which is only permitted before ExitBootServices() anyway), we should disregard such framebuffers when looking for a GOP instance that is suitable for use as the boot console. So modify the EFI GOP initialization to not use a PIXEL_BLT_ONLY instance, preventing attempts later in boot to use an invalid screen_info.lfb_base address. Signed-off-by: Eugene Cohen <eugene@hp.com> [ Moved the Blt() only check into the loop and clarified that Blt() only GOPs are unusable by the kernel. ] Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: <stable@vger.kernel.org> # v4.7+ Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: leif.lindholm@linaro.org Cc: linux-efi@vger.kernel.org Cc: lorenzo.pieralisi@arm.com Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...") Link: http://lkml.kernel.org/r/20170404152744.26687-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org> --- drivers/firmware/efi/libstub/gop.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/libstub/gop.c b/drivers/firmware/efi/libstub/gop.c index 932742e..24c461d 100644 --- a/drivers/firmware/efi/libstub/gop.c +++ b/drivers/firmware/efi/libstub/gop.c @@ -149,7 +149,8 @@ setup_gop32(efi_system_table_t *sys_table_arg, struct screen_info *si, status = __gop_query32(sys_table_arg, gop32, &info, &size, ¤t_fb_base); - if (status == EFI_SUCCESS && (!first_gop || conout_found)) { + if (status == EFI_SUCCESS && (!first_gop || conout_found) && + info->pixel_format != PIXEL_BLT_ONLY) { /* * Systems that use the UEFI Console Splitter may * provide multiple GOP devices, not all of which are @@ -266,7 +267,8 @@ setup_gop64(efi_system_table_t *sys_table_arg, struct screen_info *si, status = __gop_query64(sys_table_arg, gop64, &info, &size, ¤t_fb_base); - if (status == EFI_SUCCESS && (!first_gop || conout_found)) { + if (status == EFI_SUCCESS && (!first_gop || conout_found) && + info->pixel_format != PIXEL_BLT_ONLY) { /* * Systems that use the UEFI Console Splitter may * provide multiple GOP devices, not all of which are ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer 2017-04-04 15:27 ` Ard Biesheuvel (?) (?) @ 2017-04-04 15:27 ` Ard Biesheuvel 2017-04-05 7:58 ` [tip:efi/urgent] efi/fb: " tip-bot for Ard Biesheuvel ` (2 more replies) -1 siblings, 3 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-04-04 15:27 UTC (permalink / raw) To: linux-efi, Ingo Molnar, Thomas Gleixner, H . Peter Anvin Cc: leif.lindholm, lorenzo.pieralisi, Ard Biesheuvel, linux-kernel 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 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [tip:efi/urgent] efi/fb: Avoid reconfiguration of BAR that covers the framebuffer 2017-04-04 15:27 ` [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer Ard Biesheuvel @ 2017-04-05 7:58 ` tip-bot for Ard Biesheuvel 2017-04-05 10:30 ` tip-bot for Ard Biesheuvel 2017-05-19 16:27 ` [PATCH 2/2] efifb: " Bjorn Helgaas 2 siblings, 0 replies; 23+ messages in thread From: tip-bot for Ard Biesheuvel @ 2017-04-05 7:58 UTC (permalink / raw) To: linux-tip-commits Cc: ard.biesheuvel, linux-kernel, torvalds, pjones, mingo, matt, tglx, peterz, hpa Commit-ID: 5a8997342183bb792fe2c15cecf371665d784dd7 Gitweb: http://git.kernel.org/tip/5a8997342183bb792fe2c15cecf371665d784dd7 Author: Ard Biesheuvel <ard.biesheuvel@linaro.org> AuthorDate: Tue, 4 Apr 2017 16:27:44 +0100 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Wed, 5 Apr 2017 09:20:18 +0200 efi/fb: Avoid reconfiguration of BAR that covers the framebuffer On UEFI systems, the PCI subsystem is enumerated by the firmware, and if a graphical framebuffer is exposed via 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. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: <stable@vger.kernel.org> # v4.7+ Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: leif.lindholm@linaro.org Cc: linux-efi@vger.kernel.org Cc: lorenzo.pieralisi@arm.com Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...") Link: http://lkml.kernel.org/r/20170404152744.26687-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.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 8c4dc1e..758960b 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 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [tip:efi/urgent] efi/fb: Avoid reconfiguration of BAR that covers the framebuffer 2017-04-04 15:27 ` [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer Ard Biesheuvel 2017-04-05 7:58 ` [tip:efi/urgent] efi/fb: " tip-bot for Ard Biesheuvel @ 2017-04-05 10:30 ` tip-bot for Ard Biesheuvel 2017-05-19 16:27 ` [PATCH 2/2] efifb: " Bjorn Helgaas 2 siblings, 0 replies; 23+ messages in thread From: tip-bot for Ard Biesheuvel @ 2017-04-05 10:30 UTC (permalink / raw) To: linux-tip-commits Cc: pjones, tglx, peterz, torvalds, matt, ard.biesheuvel, linux-kernel, mingo, hpa Commit-ID: 55d728a40d368ba80443be85c02e641fc9082a3f Gitweb: http://git.kernel.org/tip/55d728a40d368ba80443be85c02e641fc9082a3f Author: Ard Biesheuvel <ard.biesheuvel@linaro.org> AuthorDate: Tue, 4 Apr 2017 16:27:44 +0100 Committer: Ingo Molnar <mingo@kernel.org> CommitDate: Wed, 5 Apr 2017 12:25:53 +0200 efi/fb: Avoid reconfiguration of BAR that covers the framebuffer On UEFI systems, the PCI subsystem is enumerated by the firmware, and if a graphical framebuffer is exposed via 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. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: <stable@vger.kernel.org> # v4.7+ Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: leif.lindholm@linaro.org Cc: linux-efi@vger.kernel.org Cc: lorenzo.pieralisi@arm.com Fixes: 9822504c1fa5 ("efifb: Enable the efi-framebuffer platform driver ...") Link: http://lkml.kernel.org/r/20170404152744.26687-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.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 8c4dc1e..b827a81 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); + +#if defined(CONFIG_PCI) && !defined(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 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer 2017-04-04 15:27 ` [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer Ard Biesheuvel 2017-04-05 7:58 ` [tip:efi/urgent] efi/fb: " tip-bot for Ard Biesheuvel 2017-04-05 10:30 ` tip-bot for Ard Biesheuvel @ 2017-05-19 16:27 ` Bjorn Helgaas 2017-05-19 16:37 ` Ard Biesheuvel 2 siblings, 1 reply; 23+ messages in thread From: Bjorn Helgaas @ 2017-05-19 16:27 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi, Ingo Molnar, Thomas Gleixner, H . Peter Anvin, leif.lindholm, lorenzo.pieralisi, linux-kernel, linux-pci [+cc linux-pci] On Tue, Apr 04, 2017 at 04:27:44PM +0100, Ard Biesheuvel wrote: > 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. I know this has already been merged as 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that covers the framebuffer"), and I'm not suggesting that we revert it, but I have some misgivings. One is the "#ifndef CONFIG_X86". In principle, there is nothing arch- specific here. I don't think it's a good idea to build in dependencies on things like "this arch preserves (or reprograms) PCI BARs". The PCI core may reprogram all, some, or none of the PCI BARs, depending on what (if anything) firmware has done. Another is the use of pci_claim_resource() to express the idea that "this BAR can not be moved". We have IORESOURCE_PCI_FIXED for that purpose, and previous versions of the patch used that. I understand there was some problem with that, but I wish we could figure out and fix that problem instead of using a different mechanism. I'm not even completely sold on the idea that we need to prevent the BAR from being moved. I'm not a UEFI expert, but if this requirement is in the spec, we should reference it. If not, it should be sufficient to remember the boot-time BAR value, match the GOP base to *that*, and map it to whatever the current BAR value is. > 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer @ 2017-05-19 16:37 ` Ard Biesheuvel 0 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-05-19 16:37 UTC (permalink / raw) To: Bjorn Helgaas Cc: linux-efi, Ingo Molnar, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel, linux-pci Hi Bjorn, On 19 May 2017 at 17:27, Bjorn Helgaas <helgaas@kernel.org> wrote: > [+cc linux-pci] > > On Tue, Apr 04, 2017 at 04:27:44PM +0100, Ard Biesheuvel wrote: >> 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. > > I know this has already been merged as 55d728a40d36 ("efi/fb: Avoid > reconfiguration of BAR that covers the framebuffer"), and I'm not > suggesting that we revert it, but I have some misgivings. > Thanks for taking a look. I have been struggling with this issue for a while now. > One is the "#ifndef CONFIG_X86". In principle, there is nothing arch- > specific here. I don't think it's a good idea to build in dependencies on > things like "this arch preserves (or reprograms) PCI BARs". The PCI core > may reprogram all, some, or none of the PCI BARs, depending on what (if > anything) firmware has done. > IIRC this was a late addition. I agree that the issue exists in theory on x86 as well. However, I was primarily dealing with the reality of arm64 systems that suddenly explode in inexplicable ways after upgrading the kernel to one that happens to have EFIFB built in. The patch went into -stable as well, so I still think adding #ifndef CONFIG_X86 was the right choice here. > Another is the use of pci_claim_resource() to express the idea that "this > BAR can not be moved". We have IORESOURCE_PCI_FIXED for that purpose, and > previous versions of the patch used that. I understand there was some > problem with that, but I wish we could figure out and fix that problem > instead of using a different mechanism. > OK. The problem was that IORESOURCE_PCI_FIXED does not prevent the PCI subsystem from handing out the same range to another device. > I'm not even completely sold on the idea that we need to prevent the BAR > from being moved. I'm not a UEFI expert, but if this requirement is in the > spec, we should reference it. If not, it should be sufficient to remember > the boot-time BAR value, match the GOP base to *that*, and map it to > whatever the current BAR value is. > There is no such requirement in the spec. The graphics output protocol is not described in terms of PCI, BARs etc. The framebuffer is simply a memory range with side effects that is left enabled when handing over to the OS. In summary, I am as unhappy with the patch as you are, but it is still an improvement over the previous situation, so let's simply collaborate to get this into shape going forward. My preference would be to investigate IORESOURCE_PCI_FIXED again, because that still seems like the best way to deal with a live framebuffer on a PCI device that has memory decoding enabled. It should also address the issue with the current version of the patch, i.e., that claiming resources at this point is not possible if the device resides behind a bridge. So is there any guidance you can give as to how to proceed? If we set IORESOURCE_PCI_FIXED, how should be prevent the PCI layer from assigning this resource elsewhere if we cannot claim it yet? Regards, Ard. >> 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 >> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer @ 2017-05-19 16:37 ` Ard Biesheuvel 0 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-05-19 16:37 UTC (permalink / raw) To: Bjorn Helgaas Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-pci Hi Bjorn, On 19 May 2017 at 17:27, Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > [+cc linux-pci] > > On Tue, Apr 04, 2017 at 04:27:44PM +0100, Ard Biesheuvel wrote: >> 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. > > I know this has already been merged as 55d728a40d36 ("efi/fb: Avoid > reconfiguration of BAR that covers the framebuffer"), and I'm not > suggesting that we revert it, but I have some misgivings. > Thanks for taking a look. I have been struggling with this issue for a while now. > One is the "#ifndef CONFIG_X86". In principle, there is nothing arch- > specific here. I don't think it's a good idea to build in dependencies on > things like "this arch preserves (or reprograms) PCI BARs". The PCI core > may reprogram all, some, or none of the PCI BARs, depending on what (if > anything) firmware has done. > IIRC this was a late addition. I agree that the issue exists in theory on x86 as well. However, I was primarily dealing with the reality of arm64 systems that suddenly explode in inexplicable ways after upgrading the kernel to one that happens to have EFIFB built in. The patch went into -stable as well, so I still think adding #ifndef CONFIG_X86 was the right choice here. > Another is the use of pci_claim_resource() to express the idea that "this > BAR can not be moved". We have IORESOURCE_PCI_FIXED for that purpose, and > previous versions of the patch used that. I understand there was some > problem with that, but I wish we could figure out and fix that problem > instead of using a different mechanism. > OK. The problem was that IORESOURCE_PCI_FIXED does not prevent the PCI subsystem from handing out the same range to another device. > I'm not even completely sold on the idea that we need to prevent the BAR > from being moved. I'm not a UEFI expert, but if this requirement is in the > spec, we should reference it. If not, it should be sufficient to remember > the boot-time BAR value, match the GOP base to *that*, and map it to > whatever the current BAR value is. > There is no such requirement in the spec. The graphics output protocol is not described in terms of PCI, BARs etc. The framebuffer is simply a memory range with side effects that is left enabled when handing over to the OS. In summary, I am as unhappy with the patch as you are, but it is still an improvement over the previous situation, so let's simply collaborate to get this into shape going forward. My preference would be to investigate IORESOURCE_PCI_FIXED again, because that still seems like the best way to deal with a live framebuffer on a PCI device that has memory decoding enabled. It should also address the issue with the current version of the patch, i.e., that claiming resources at this point is not possible if the device resides behind a bridge. So is there any guidance you can give as to how to proceed? If we set IORESOURCE_PCI_FIXED, how should be prevent the PCI layer from assigning this resource elsewhere if we cannot claim it yet? Regards, Ard. >> 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 >> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer 2017-05-19 16:37 ` Ard Biesheuvel (?) @ 2017-05-19 20:44 ` Bjorn Helgaas 2017-05-19 22:04 ` Ard Biesheuvel -1 siblings, 1 reply; 23+ messages in thread From: Bjorn Helgaas @ 2017-05-19 20:44 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi, Ingo Molnar, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel, linux-pci On Fri, May 19, 2017 at 05:37:30PM +0100, Ard Biesheuvel wrote: > Hi Bjorn, > > On 19 May 2017 at 17:27, Bjorn Helgaas <helgaas@kernel.org> wrote: > > [+cc linux-pci] > > > > On Tue, Apr 04, 2017 at 04:27:44PM +0100, Ard Biesheuvel wrote: > >> 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. > > > > I know this has already been merged as 55d728a40d36 ("efi/fb: Avoid > > reconfiguration of BAR that covers the framebuffer"), and I'm not > > suggesting that we revert it, but I have some misgivings. > ... > > Another is the use of pci_claim_resource() to express the idea that "this > > BAR can not be moved". We have IORESOURCE_PCI_FIXED for that purpose, and > > previous versions of the patch used that. I understand there was some > > problem with that, but I wish we could figure out and fix that problem > > instead of using a different mechanism. > > OK. The problem was that IORESOURCE_PCI_FIXED does not prevent the PCI > subsystem from handing out the same range to another device. Yes, this would definitely be a problem. There must be a path where we start doing the reassignment before we claim the resources that have already been assigned. That's what seems backwards to me -- it seems like we should claim things that are valid first so we know to avoid them. > > I'm not even completely sold on the idea that we need to prevent the BAR > > from being moved. I'm not a UEFI expert, but if this requirement is in the > > spec, we should reference it. If not, it should be sufficient to remember > > the boot-time BAR value, match the GOP base to *that*, and map it to > > whatever the current BAR value is. > > There is no such requirement in the spec. The graphics output protocol > is not described in terms of PCI, BARs etc. The framebuffer is simply > a memory range with side effects that is left enabled when handing > over to the OS. > > In summary, I am as unhappy with the patch as you are, but it is still > an improvement over the previous situation, so let's simply > collaborate to get this into shape going forward. > > My preference would be to investigate IORESOURCE_PCI_FIXED again, > because that still seems like the best way to deal with a live > framebuffer on a PCI device that has memory decoding enabled. It > should also address the issue with the current version of the patch, > i.e., that claiming resources at this point is not possible if the > device resides behind a bridge. > > So is there any guidance you can give as to how to proceed? If we set > IORESOURCE_PCI_FIXED, how should be prevent the PCI layer from > assigning this resource elsewhere if we cannot claim it yet? My preference would actually be to remember the boot BAR values and map to the current values because that avoids the unnecessary restriction. The IORESOURCE_PCI_FIXED uses that seem legitimate to me are the legacy VGA and IDE things (stuff that's not described by BARs and *can't* be moved) and the new "Enhanced Allocation" stuff (basically a way to describe more non-BAR resources). We do something sort of similar with pci_revert_fw_address(), although it's currently only implemented for x86. I could imagine a more generic solution that could be used for this GOP issue and could also replace pci_revert_fw_address(). Conceptually it could be as simple as adding 7 u64 boot-time BAR values (6 BARs + the ROM) to struct pci_dev. We went to a lot of trouble to implement the pcibios_fwaddrmap stuff on x86, and I can't remember why it's x86-specific. Maybe we thought the extra 56 bytes per dev was too much overhead (it does seem like a lot for such a limited use case). Maybe there's a clever way to store just the BARs we actually change and keep that long enough for efifb to use it. It *would* be nice to fix the problem with IORESOURCE_PCI_FIXED, and I think it would help clean up PCI resource management a lot. Ideally we would be able to claim host bridge resources even before scanning the bus, then claim BARs immediately when we discover them. That would allow us to automatically use any setup done by firmware, and reassign anything that we couldn't claim. But I think this will end up being difficult because we currently do the PCI bus scan before looking at ACPI resources, and sometimes those ACPI resources overlap with the host bridge windows. Every time I look at this, I get discouraged. Bjorn ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer @ 2017-05-19 22:04 ` Ard Biesheuvel 0 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-05-19 22:04 UTC (permalink / raw) To: Bjorn Helgaas Cc: linux-efi, Ingo Molnar, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel, linux-pci On 19 May 2017 at 21:44, Bjorn Helgaas <helgaas@kernel.org> wrote: > On Fri, May 19, 2017 at 05:37:30PM +0100, Ard Biesheuvel wrote: >> Hi Bjorn, >> >> On 19 May 2017 at 17:27, Bjorn Helgaas <helgaas@kernel.org> wrote: >> > [+cc linux-pci] >> > >> > On Tue, Apr 04, 2017 at 04:27:44PM +0100, Ard Biesheuvel wrote: >> >> 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. >> > >> > I know this has already been merged as 55d728a40d36 ("efi/fb: Avoid >> > reconfiguration of BAR that covers the framebuffer"), and I'm not >> > suggesting that we revert it, but I have some misgivings. >> ... > >> > Another is the use of pci_claim_resource() to express the idea that "this >> > BAR can not be moved". We have IORESOURCE_PCI_FIXED for that purpose, and >> > previous versions of the patch used that. I understand there was some >> > problem with that, but I wish we could figure out and fix that problem >> > instead of using a different mechanism. >> >> OK. The problem was that IORESOURCE_PCI_FIXED does not prevent the PCI >> subsystem from handing out the same range to another device. > > Yes, this would definitely be a problem. There must be a path where > we start doing the reassignment before we claim the resources that > have already been assigned. That's what seems backwards to me -- it > seems like we should claim things that are valid first so we know to > avoid them. > >> > I'm not even completely sold on the idea that we need to prevent the BAR >> > from being moved. I'm not a UEFI expert, but if this requirement is in the >> > spec, we should reference it. If not, it should be sufficient to remember >> > the boot-time BAR value, match the GOP base to *that*, and map it to >> > whatever the current BAR value is. >> >> There is no such requirement in the spec. The graphics output protocol >> is not described in terms of PCI, BARs etc. The framebuffer is simply >> a memory range with side effects that is left enabled when handing >> over to the OS. >> >> In summary, I am as unhappy with the patch as you are, but it is still >> an improvement over the previous situation, so let's simply >> collaborate to get this into shape going forward. >> >> My preference would be to investigate IORESOURCE_PCI_FIXED again, >> because that still seems like the best way to deal with a live >> framebuffer on a PCI device that has memory decoding enabled. It >> should also address the issue with the current version of the patch, >> i.e., that claiming resources at this point is not possible if the >> device resides behind a bridge. >> >> So is there any guidance you can give as to how to proceed? If we set >> IORESOURCE_PCI_FIXED, how should be prevent the PCI layer from >> assigning this resource elsewhere if we cannot claim it yet? > > My preference would actually be to remember the boot BAR values and > map to the current values because that avoids the unnecessary > restriction. The IORESOURCE_PCI_FIXED uses that seem legitimate to me > are the legacy VGA and IDE things (stuff that's not described by BARs > and *can't* be moved) and the new "Enhanced Allocation" stuff > (basically a way to describe more non-BAR resources). > > We do something sort of similar with pci_revert_fw_address(), although > it's currently only implemented for x86. I could imagine a more > generic solution that could be used for this GOP issue and could also > replace pci_revert_fw_address(). > I already proposed something like this a while ago: http://marc.info//?l=linux-fbdev&m=149190021316410&w=2 > Conceptually it could be as simple as adding 7 u64 boot-time BAR > values (6 BARs + the ROM) to struct pci_dev. We went to a lot of > trouble to implement the pcibios_fwaddrmap stuff on x86, and I can't > remember why it's x86-specific. Maybe we thought the extra 56 bytes > per dev was too much overhead (it does seem like a lot for such a > limited use case). Maybe there's a clever way to store just the BARs > we actually change and keep that long enough for efifb to use it. > > It *would* be nice to fix the problem with IORESOURCE_PCI_FIXED, and I > think it would help clean up PCI resource management a lot. Ideally > we would be able to claim host bridge resources even before scanning > the bus, then claim BARs immediately when we discover them. That > would allow us to automatically use any setup done by firmware, and > reassign anything that we couldn't claim. > > But I think this will end up being difficult because we currently do > the PCI bus scan before looking at ACPI resources, and sometimes those > ACPI resources overlap with the host bridge windows. Every time I > look at this, I get discouraged. > > Bjorn ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer @ 2017-05-19 22:04 ` Ard Biesheuvel 0 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-05-19 22:04 UTC (permalink / raw) To: Bjorn Helgaas Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-pci On 19 May 2017 at 21:44, Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > On Fri, May 19, 2017 at 05:37:30PM +0100, Ard Biesheuvel wrote: >> Hi Bjorn, >> >> On 19 May 2017 at 17:27, Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: >> > [+cc linux-pci] >> > >> > On Tue, Apr 04, 2017 at 04:27:44PM +0100, Ard Biesheuvel wrote: >> >> 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. >> > >> > I know this has already been merged as 55d728a40d36 ("efi/fb: Avoid >> > reconfiguration of BAR that covers the framebuffer"), and I'm not >> > suggesting that we revert it, but I have some misgivings. >> ... > >> > Another is the use of pci_claim_resource() to express the idea that "this >> > BAR can not be moved". We have IORESOURCE_PCI_FIXED for that purpose, and >> > previous versions of the patch used that. I understand there was some >> > problem with that, but I wish we could figure out and fix that problem >> > instead of using a different mechanism. >> >> OK. The problem was that IORESOURCE_PCI_FIXED does not prevent the PCI >> subsystem from handing out the same range to another device. > > Yes, this would definitely be a problem. There must be a path where > we start doing the reassignment before we claim the resources that > have already been assigned. That's what seems backwards to me -- it > seems like we should claim things that are valid first so we know to > avoid them. > >> > I'm not even completely sold on the idea that we need to prevent the BAR >> > from being moved. I'm not a UEFI expert, but if this requirement is in the >> > spec, we should reference it. If not, it should be sufficient to remember >> > the boot-time BAR value, match the GOP base to *that*, and map it to >> > whatever the current BAR value is. >> >> There is no such requirement in the spec. The graphics output protocol >> is not described in terms of PCI, BARs etc. The framebuffer is simply >> a memory range with side effects that is left enabled when handing >> over to the OS. >> >> In summary, I am as unhappy with the patch as you are, but it is still >> an improvement over the previous situation, so let's simply >> collaborate to get this into shape going forward. >> >> My preference would be to investigate IORESOURCE_PCI_FIXED again, >> because that still seems like the best way to deal with a live >> framebuffer on a PCI device that has memory decoding enabled. It >> should also address the issue with the current version of the patch, >> i.e., that claiming resources at this point is not possible if the >> device resides behind a bridge. >> >> So is there any guidance you can give as to how to proceed? If we set >> IORESOURCE_PCI_FIXED, how should be prevent the PCI layer from >> assigning this resource elsewhere if we cannot claim it yet? > > My preference would actually be to remember the boot BAR values and > map to the current values because that avoids the unnecessary > restriction. The IORESOURCE_PCI_FIXED uses that seem legitimate to me > are the legacy VGA and IDE things (stuff that's not described by BARs > and *can't* be moved) and the new "Enhanced Allocation" stuff > (basically a way to describe more non-BAR resources). > > We do something sort of similar with pci_revert_fw_address(), although > it's currently only implemented for x86. I could imagine a more > generic solution that could be used for this GOP issue and could also > replace pci_revert_fw_address(). > I already proposed something like this a while ago: http://marc.info//?l=linux-fbdev&m=149190021316410&w=2 > Conceptually it could be as simple as adding 7 u64 boot-time BAR > values (6 BARs + the ROM) to struct pci_dev. We went to a lot of > trouble to implement the pcibios_fwaddrmap stuff on x86, and I can't > remember why it's x86-specific. Maybe we thought the extra 56 bytes > per dev was too much overhead (it does seem like a lot for such a > limited use case). Maybe there's a clever way to store just the BARs > we actually change and keep that long enough for efifb to use it. > > It *would* be nice to fix the problem with IORESOURCE_PCI_FIXED, and I > think it would help clean up PCI resource management a lot. Ideally > we would be able to claim host bridge resources even before scanning > the bus, then claim BARs immediately when we discover them. That > would allow us to automatically use any setup done by firmware, and > reassign anything that we couldn't claim. > > But I think this will end up being difficult because we currently do > the PCI bus scan before looking at ACPI resources, and sometimes those > ACPI resources overlap with the host bridge windows. Every time I > look at this, I get discouraged. > > Bjorn ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <CGME20170405100833epcas1p4b5076679dc4f8644fa789b421a66f953@epcas1p4.samsung.com>]
* Re: [GIT PULL 0/2] EFI fixes for v4.11 [not found] ` <CGME20170405100833epcas1p4b5076679dc4f8644fa789b421a66f953@epcas1p4.samsung.com> @ 2017-04-05 10:08 ` Bartlomiej Zolnierkiewicz 2017-04-05 10:14 ` Ard Biesheuvel 0 siblings, 1 reply; 23+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2017-04-05 10:08 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi, Ingo Molnar, Thomas Gleixner, H . Peter Anvin, leif.lindholm, lorenzo.pieralisi, linux-kernel, Eugene Cohen, Matt Fleming, Peter Jones Hi, On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote: > Hello all, > > Please pull these fixes for EFI framebuffer support on ARM/arm64 systems. > > The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe: > > efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +0000) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent > > for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e: > > efifb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-04 15:56:43 +0100) > > ---------------------------------------------------------------- > Two fixes related to the EFI framebuffer driver: > - Ignore Graphics Output Protocol (GOP) implementations that are marked as > BLT-only -- the framebuffer base address is invalid in this case, and the > Blt() method is not accessible to the kernel. > - If the GOP framebuffer base address coincides with a memory BAR of a PCI > device that has memory decoding enabled, claim the memory resource so that > the PCI core will not attempt to move it later on. > > ---------------------------------------------------------------- > Ard Biesheuvel (1): > efifb: Avoid reconfiguration of BAR that covers the framebuffer This patch breaks build if PCI support is not enabled: drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’: drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function ‘pci_claim_resource’ [-Werror=implicit-function-declaration] (x86 ifdefs are not enough, the patch should also check for PCI support) Also please cc: linux-fbdev mailing list & me on fbdev related patches. > Cohen, Eugene (1): > efi/libstub: Skip GOP with PIXEL_BLT_ONLY format > > drivers/firmware/efi/libstub/gop.c | 6 ++-- > drivers/video/fbdev/efifb.c | 66 +++++++++++++++++++++++++++++++++++++- > 2 files changed, 69 insertions(+), 3 deletions(-) Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [GIT PULL 0/2] EFI fixes for v4.11 2017-04-05 10:08 ` [GIT PULL 0/2] EFI fixes for v4.11 Bartlomiej Zolnierkiewicz @ 2017-04-05 10:14 ` Ard Biesheuvel 0 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-04-05 10:14 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz, Ingo Molnar Cc: linux-efi, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel, Eugene Cohen, Matt Fleming, Peter Jones On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote: > > Hi, > > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote: >> Hello all, >> >> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems. >> >> The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe: >> >> efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +0000) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent >> >> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e: >> >> efifb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-04 15:56:43 +0100) >> >> ---------------------------------------------------------------- >> Two fixes related to the EFI framebuffer driver: >> - Ignore Graphics Output Protocol (GOP) implementations that are marked as >> BLT-only -- the framebuffer base address is invalid in this case, and the >> Blt() method is not accessible to the kernel. >> - If the GOP framebuffer base address coincides with a memory BAR of a PCI >> device that has memory decoding enabled, claim the memory resource so that >> the PCI core will not attempt to move it later on. >> >> ---------------------------------------------------------------- >> Ard Biesheuvel (1): >> efifb: Avoid reconfiguration of BAR that covers the framebuffer > > This patch breaks build if PCI support is not enabled: > > drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’: > drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function ‘pci_claim_resource’ [-Werror=implicit-function-declaration] > > (x86 ifdefs are not enough, the patch should also check for PCI support) > > Also please cc: linux-fbdev mailing list & me on fbdev related patches. > Thanks for the report. The patch was tested successfully on an impressive list of configurations by kbuild test robot, but apparently, none of those has PCI disabled. Ingo, since you have queued this already, how would you like to proceed? I don't think we need anything beyond diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index 758960b6aec9..b827a8113e26 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = { builtin_platform_driver(efifb_driver); -#ifndef CONFIG_X86 +#if defined(CONFIG_PCI) && !defined(CONFIG_X86) static bool pci_bar_found; /* did we find a BAR matching the efifb base? */ -- Ard. ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [GIT PULL 0/2] EFI fixes for v4.11 @ 2017-04-05 10:14 ` Ard Biesheuvel 0 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-04-05 10:14 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz, Ingo Molnar Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eugene Cohen, Matt Fleming, Peter Jones On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz <b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote: > > Hi, > > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote: >> Hello all, >> >> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems. >> >> The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe: >> >> efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +0000) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent >> >> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e: >> >> efifb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-04 15:56:43 +0100) >> >> ---------------------------------------------------------------- >> Two fixes related to the EFI framebuffer driver: >> - Ignore Graphics Output Protocol (GOP) implementations that are marked as >> BLT-only -- the framebuffer base address is invalid in this case, and the >> Blt() method is not accessible to the kernel. >> - If the GOP framebuffer base address coincides with a memory BAR of a PCI >> device that has memory decoding enabled, claim the memory resource so that >> the PCI core will not attempt to move it later on. >> >> ---------------------------------------------------------------- >> Ard Biesheuvel (1): >> efifb: Avoid reconfiguration of BAR that covers the framebuffer > > This patch breaks build if PCI support is not enabled: > > drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’: > drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function ‘pci_claim_resource’ [-Werror=implicit-function-declaration] > > (x86 ifdefs are not enough, the patch should also check for PCI support) > > Also please cc: linux-fbdev mailing list & me on fbdev related patches. > Thanks for the report. The patch was tested successfully on an impressive list of configurations by kbuild test robot, but apparently, none of those has PCI disabled. Ingo, since you have queued this already, how would you like to proceed? I don't think we need anything beyond diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index 758960b6aec9..b827a8113e26 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = { builtin_platform_driver(efifb_driver); -#ifndef CONFIG_X86 +#if defined(CONFIG_PCI) && !defined(CONFIG_X86) static bool pci_bar_found; /* did we find a BAR matching the efifb base? */ -- Ard. ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [GIT PULL 0/2] EFI fixes for v4.11 2017-04-05 10:14 ` Ard Biesheuvel (?) @ 2017-04-05 10:26 ` Ingo Molnar 2017-04-05 10:32 ` Ard Biesheuvel -1 siblings, 1 reply; 23+ messages in thread From: Ingo Molnar @ 2017-04-05 10:26 UTC (permalink / raw) To: Ard Biesheuvel Cc: Bartlomiej Zolnierkiewicz, linux-efi, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel, Eugene Cohen, Matt Fleming, Peter Jones * Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz > <b.zolnierkie@samsung.com> wrote: > > > > Hi, > > > > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote: > >> Hello all, > >> > >> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems. > >> > >> The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe: > >> > >> efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +0000) > >> > >> are available in the git repository at: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent > >> > >> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e: > >> > >> efifb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-04 15:56:43 +0100) > >> > >> ---------------------------------------------------------------- > >> Two fixes related to the EFI framebuffer driver: > >> - Ignore Graphics Output Protocol (GOP) implementations that are marked as > >> BLT-only -- the framebuffer base address is invalid in this case, and the > >> Blt() method is not accessible to the kernel. > >> - If the GOP framebuffer base address coincides with a memory BAR of a PCI > >> device that has memory decoding enabled, claim the memory resource so that > >> the PCI core will not attempt to move it later on. > >> > >> ---------------------------------------------------------------- > >> Ard Biesheuvel (1): > >> efifb: Avoid reconfiguration of BAR that covers the framebuffer > > > > This patch breaks build if PCI support is not enabled: > > > > drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’: > > drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function ‘pci_claim_resource’ [-Werror=implicit-function-declaration] > > > > (x86 ifdefs are not enough, the patch should also check for PCI support) > > > > Also please cc: linux-fbdev mailing list & me on fbdev related patches. > > > > Thanks for the report. The patch was tested successfully on an > impressive list of configurations by kbuild test robot, but > apparently, none of those has PCI disabled. > > Ingo, since you have queued this already, how would you like to > proceed? I don't think we need anything beyond > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c > index 758960b6aec9..b827a8113e26 100644 > --- a/drivers/video/fbdev/efifb.c > +++ b/drivers/video/fbdev/efifb.c > @@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = { > > builtin_platform_driver(efifb_driver); > > -#ifndef CONFIG_X86 > +#if defined(CONFIG_PCI) && !defined(CONFIG_X86) I've rebased it all, it's still pretty fresh (two hours old) and the delta fix would look pretty ugly in the urgent branch. Thanks, Ingo ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [GIT PULL 0/2] EFI fixes for v4.11 2017-04-05 10:26 ` Ingo Molnar @ 2017-04-05 10:32 ` Ard Biesheuvel 0 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-04-05 10:32 UTC (permalink / raw) To: Ingo Molnar Cc: Bartlomiej Zolnierkiewicz, linux-efi, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel, Eugene Cohen, Matt Fleming, Peter Jones On 5 April 2017 at 11:26, Ingo Molnar <mingo@kernel.org> wrote: > > * Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > >> On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz >> <b.zolnierkie@samsung.com> wrote: >> > >> > Hi, >> > >> > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote: >> >> Hello all, >> >> >> >> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems. >> >> >> >> The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe: >> >> >> >> efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +0000) >> >> >> >> are available in the git repository at: >> >> >> >> git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent >> >> >> >> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e: >> >> >> >> efifb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-04 15:56:43 +0100) >> >> >> >> ---------------------------------------------------------------- >> >> Two fixes related to the EFI framebuffer driver: >> >> - Ignore Graphics Output Protocol (GOP) implementations that are marked as >> >> BLT-only -- the framebuffer base address is invalid in this case, and the >> >> Blt() method is not accessible to the kernel. >> >> - If the GOP framebuffer base address coincides with a memory BAR of a PCI >> >> device that has memory decoding enabled, claim the memory resource so that >> >> the PCI core will not attempt to move it later on. >> >> >> >> ---------------------------------------------------------------- >> >> Ard Biesheuvel (1): >> >> efifb: Avoid reconfiguration of BAR that covers the framebuffer >> > >> > This patch breaks build if PCI support is not enabled: >> > >> > drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’: >> > drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function ‘pci_claim_resource’ [-Werror=implicit-function-declaration] >> > >> > (x86 ifdefs are not enough, the patch should also check for PCI support) >> > >> > Also please cc: linux-fbdev mailing list & me on fbdev related patches. >> > >> >> Thanks for the report. The patch was tested successfully on an >> impressive list of configurations by kbuild test robot, but >> apparently, none of those has PCI disabled. >> >> Ingo, since you have queued this already, how would you like to >> proceed? I don't think we need anything beyond >> >> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c >> index 758960b6aec9..b827a8113e26 100644 >> --- a/drivers/video/fbdev/efifb.c >> +++ b/drivers/video/fbdev/efifb.c >> @@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = { >> >> builtin_platform_driver(efifb_driver); >> >> -#ifndef CONFIG_X86 >> +#if defined(CONFIG_PCI) && !defined(CONFIG_X86) > > I've rebased it all, it's still pretty fresh (two hours old) and the delta fix > would look pretty ugly in the urgent branch. > Thanks for cleaning that up. -- Ard. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [GIT PULL 0/2] EFI fixes for v4.11 @ 2017-04-05 10:44 ` Bartlomiej Zolnierkiewicz 0 siblings, 0 replies; 23+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2017-04-05 10:44 UTC (permalink / raw) To: Ard Biesheuvel Cc: Ingo Molnar, linux-efi, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel, Eugene Cohen, Matt Fleming, Peter Jones On Wednesday, April 05, 2017 11:14:06 AM Ard Biesheuvel wrote: > On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz > <b.zolnierkie@samsung.com> wrote: > > > > Hi, > > > > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote: > >> Hello all, > >> > >> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems. > >> > >> The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe: > >> > >> efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +0000) > >> > >> are available in the git repository at: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent > >> > >> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e: > >> > >> efifb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-04 15:56:43 +0100) > >> > >> ---------------------------------------------------------------- > >> Two fixes related to the EFI framebuffer driver: > >> - Ignore Graphics Output Protocol (GOP) implementations that are marked as > >> BLT-only -- the framebuffer base address is invalid in this case, and the > >> Blt() method is not accessible to the kernel. > >> - If the GOP framebuffer base address coincides with a memory BAR of a PCI > >> device that has memory decoding enabled, claim the memory resource so that > >> the PCI core will not attempt to move it later on. > >> > >> ---------------------------------------------------------------- > >> Ard Biesheuvel (1): > >> efifb: Avoid reconfiguration of BAR that covers the framebuffer > > > > This patch breaks build if PCI support is not enabled: > > > > drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’: > > drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function ‘pci_claim_resource’ [-Werror=implicit-function-declaration] > > > > (x86 ifdefs are not enough, the patch should also check for PCI support) > > > > Also please cc: linux-fbdev mailing list & me on fbdev related patches. > > > > Thanks for the report. The patch was tested successfully on an > impressive list of configurations by kbuild test robot, but > apparently, none of those has PCI disabled. Well, it has been found by looking at the patch itself and since none of defconfigs contains such configuration currently the issue is rather minor one. [ Also sorry for the late report but this is the first time I see these patches. They were never posted to linux-fbdev or me. ] > Ingo, since you have queued this already, how would you like to > proceed? I don't think we need anything beyond I see that Ingo fixed the patch himself so it is all fine now, thanks! > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c > index 758960b6aec9..b827a8113e26 100644 > --- a/drivers/video/fbdev/efifb.c > +++ b/drivers/video/fbdev/efifb.c > @@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = { > > builtin_platform_driver(efifb_driver); > > -#ifndef CONFIG_X86 > +#if defined(CONFIG_PCI) && !defined(CONFIG_X86) > > static bool pci_bar_found; /* did we find a BAR matching the efifb base? */ Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [GIT PULL 0/2] EFI fixes for v4.11 @ 2017-04-05 10:44 ` Bartlomiej Zolnierkiewicz 0 siblings, 0 replies; 23+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2017-04-05 10:44 UTC (permalink / raw) To: Ard Biesheuvel Cc: Ingo Molnar, linux-efi-u79uwXL29TY76Z2rM5mHXA, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Eugene Cohen, Matt Fleming, Peter Jones On Wednesday, April 05, 2017 11:14:06 AM Ard Biesheuvel wrote: > On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz > <b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote: > > > > Hi, > > > > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote: > >> Hello all, > >> > >> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems. > >> > >> The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe: > >> > >> efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +0000) > >> > >> are available in the git repository at: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent > >> > >> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e: > >> > >> efifb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-04 15:56:43 +0100) > >> > >> ---------------------------------------------------------------- > >> Two fixes related to the EFI framebuffer driver: > >> - Ignore Graphics Output Protocol (GOP) implementations that are marked as > >> BLT-only -- the framebuffer base address is invalid in this case, and the > >> Blt() method is not accessible to the kernel. > >> - If the GOP framebuffer base address coincides with a memory BAR of a PCI > >> device that has memory decoding enabled, claim the memory resource so that > >> the PCI core will not attempt to move it later on. > >> > >> ---------------------------------------------------------------- > >> Ard Biesheuvel (1): > >> efifb: Avoid reconfiguration of BAR that covers the framebuffer > > > > This patch breaks build if PCI support is not enabled: > > > > drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’: > > drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function ‘pci_claim_resource’ [-Werror=implicit-function-declaration] > > > > (x86 ifdefs are not enough, the patch should also check for PCI support) > > > > Also please cc: linux-fbdev mailing list & me on fbdev related patches. > > > > Thanks for the report. The patch was tested successfully on an > impressive list of configurations by kbuild test robot, but > apparently, none of those has PCI disabled. Well, it has been found by looking at the patch itself and since none of defconfigs contains such configuration currently the issue is rather minor one. [ Also sorry for the late report but this is the first time I see these patches. They were never posted to linux-fbdev or me. ] > Ingo, since you have queued this already, how would you like to > proceed? I don't think we need anything beyond I see that Ingo fixed the patch himself so it is all fine now, thanks! > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c > index 758960b6aec9..b827a8113e26 100644 > --- a/drivers/video/fbdev/efifb.c > +++ b/drivers/video/fbdev/efifb.c > @@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = { > > builtin_platform_driver(efifb_driver); > > -#ifndef CONFIG_X86 > +#if defined(CONFIG_PCI) && !defined(CONFIG_X86) > > static bool pci_bar_found; /* did we find a BAR matching the efifb base? */ Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [GIT PULL 0/2] EFI fixes for v4.11 2017-04-05 10:44 ` Bartlomiej Zolnierkiewicz (?) @ 2017-04-05 10:45 ` Ard Biesheuvel -1 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-04-05 10:45 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz Cc: Ingo Molnar, linux-efi, Thomas Gleixner, H . Peter Anvin, Leif Lindholm, Lorenzo Pieralisi, linux-kernel, Eugene Cohen, Matt Fleming, Peter Jones On 5 April 2017 at 11:44, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote: > On Wednesday, April 05, 2017 11:14:06 AM Ard Biesheuvel wrote: >> On 5 April 2017 at 11:08, Bartlomiej Zolnierkiewicz >> <b.zolnierkie@samsung.com> wrote: >> > >> > Hi, >> > >> > On Tuesday, April 04, 2017 04:27:42 PM Ard Biesheuvel wrote: >> >> Hello all, >> >> >> >> Please pull these fixes for EFI framebuffer support on ARM/arm64 systems. >> >> >> >> The following changes since commit 822f5845f710e57d7e2df1fd1ee00d6e19d334fe: >> >> >> >> efi/esrt: Cleanup bad memory map log messages (2017-03-17 18:53:12 +0000) >> >> >> >> are available in the git repository at: >> >> >> >> git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-urgent >> >> >> >> for you to fetch changes up to e73c2811538bd36ec1340d01bafdc080af31914e: >> >> >> >> efifb: Avoid reconfiguration of BAR that covers the framebuffer (2017-04-04 15:56:43 +0100) >> >> >> >> ---------------------------------------------------------------- >> >> Two fixes related to the EFI framebuffer driver: >> >> - Ignore Graphics Output Protocol (GOP) implementations that are marked as >> >> BLT-only -- the framebuffer base address is invalid in this case, and the >> >> Blt() method is not accessible to the kernel. >> >> - If the GOP framebuffer base address coincides with a memory BAR of a PCI >> >> device that has memory decoding enabled, claim the memory resource so that >> >> the PCI core will not attempt to move it later on. >> >> >> >> ---------------------------------------------------------------- >> >> Ard Biesheuvel (1): >> >> efifb: Avoid reconfiguration of BAR that covers the framebuffer >> > >> > This patch breaks build if PCI support is not enabled: >> > >> > drivers/video/fbdev/efifb.c: In function ‘claim_efifb_bar’: >> > drivers/video/fbdev/efifb.c:386:2: error: implicit declaration of function ‘pci_claim_resource’ [-Werror=implicit-function-declaration] >> > >> > (x86 ifdefs are not enough, the patch should also check for PCI support) >> > >> > Also please cc: linux-fbdev mailing list & me on fbdev related patches. >> > >> >> Thanks for the report. The patch was tested successfully on an >> impressive list of configurations by kbuild test robot, but >> apparently, none of those has PCI disabled. > > Well, it has been found by looking at the patch itself and since > none of defconfigs contains such configuration currently the issue > is rather minor one. > > [ Also sorry for the late report but this is the first time I see > these patches. They were never posted to linux-fbdev or me. ] > Apologies for that. I did cc Peter but no other fbdev maintainers. >> Ingo, since you have queued this already, how would you like to >> proceed? I don't think we need anything beyond > > I see that Ingo fixed the patch himself so it is all fine now, > thanks! > >> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c >> index 758960b6aec9..b827a8113e26 100644 >> --- a/drivers/video/fbdev/efifb.c >> +++ b/drivers/video/fbdev/efifb.c >> @@ -364,7 +364,7 @@ static struct platform_driver efifb_driver = { >> >> builtin_platform_driver(efifb_driver); >> >> -#ifndef CONFIG_X86 >> +#if defined(CONFIG_PCI) && !defined(CONFIG_X86) >> >> static bool pci_bar_found; /* did we find a BAR matching the efifb base? */ > > Best regards, > -- > Bartlomiej Zolnierkiewicz > Samsung R&D Institute Poland > Samsung Electronics > ^ permalink raw reply [flat|nested] 23+ messages in thread
* [GIT PULL 00/12] EFI updates for v4.12 @ 2017-04-04 16:02 Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel 0 siblings, 1 reply; 23+ messages in thread From: Ard Biesheuvel @ 2017-04-04 16:02 UTC (permalink / raw) To: linux-efi, Ingo Molnar, Thomas Gleixner, H . Peter Anvin Cc: Ard Biesheuvel, linux-kernel, Andy Lutomirski, Andy Lutomirski, Baoquan He, Bhupesh Sharma, Borislav Petkov, Eugene Cohen, Evgeny Kalugin, Jeffrey Hugo, Leif Lindholm, Mark Rutland, Matt Fleming, Richard Ruigrok, Roy Franz Hello all, This is what we have queued up for v4.12 so far. Please pull it so that it gets some exposure in -next before the merge window. The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81: Linux 4.11-rc2 (2017-03-12 14:47:08 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git tags/efi-next for you to fetch changes up to efc491b0f06f65ea588f6591f0bc31db779e0594: ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region (2017-04-02 16:36:29 +0100) ---------------------------------------------------------------- EFI changes for v4.12: - move BGRT handling to drivers/acpi so it can be shared between x86 and ARM - bring the EFI stub's initrd and FDT allocation logic in line with the latest changes to the arm64 boot protocol - some changes to the EFI stub's command line parsing routines -- share more code, fix a minor buglet and add support for the 'quiet' command line parameter on ARM/arm64 (whose EFI stub is a bit noisy by default) - randomize the virtual mapping of the UEFI runtime services on ARM/arm64 - other minor enhancements and fixes ---------------------------------------------------------------- Andy Lutomirski (1): x86/efi: Clean up efi CR3 save/restore Ard Biesheuvel (7): efi: arm-stub: Correct FDT and initrd allocation rules for arm64 efi: arm-stub: Round up FDT allocation to mapping size efi/arm32-stub: Allow boottime allocations in the vmlinux region efi/libstub: Fix harmless command line parsing bug efi/libstub: Unify command line param parsing efi/libstub: arm/arm64: Disable debug prints on 'quiet' cmdline arg ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region Baoquan He (1): x86/efi: Clean up a minor mistake in code comment Bhupesh Sharma (2): x86/efi-bgrt: Move efi-bgrt handling out of arch/x86 efi: bgrt: Enable ACPI BGRT handling on arm64 Evgeny Kalugin (1): pstore: return error code (if any) from efi_pstore_write arch/arm/include/asm/efi.h | 14 +- arch/arm64/include/asm/efi.h | 24 +++- arch/arm64/kernel/acpi.c | 3 + arch/x86/include/asm/efi.h | 17 ++- arch/x86/kernel/acpi/boot.c | 6 - arch/x86/platform/efi/Makefile | 1 - arch/x86/platform/efi/efi.c | 6 +- arch/x86/platform/efi/efi_32.c | 12 +- arch/x86/platform/efi/efi_64.c | 24 ++-- drivers/acpi/Kconfig | 2 +- drivers/acpi/bgrt.c | 6 + drivers/firmware/efi/Makefile | 1 + .../platform => drivers/firmware}/efi/efi-bgrt.c | 0 drivers/firmware/efi/efi-pstore.c | 6 +- drivers/firmware/efi/libstub/arm-stub.c | 80 ++++++----- drivers/firmware/efi/libstub/arm32-stub.c | 150 ++++++++++++++++++--- drivers/firmware/efi/libstub/arm64-stub.c | 4 +- drivers/firmware/efi/libstub/efi-stub-helper.c | 32 +++-- drivers/firmware/efi/libstub/efistub.h | 9 ++ drivers/firmware/efi/libstub/fdt.c | 57 ++++---- drivers/firmware/efi/libstub/secureboot.c | 2 + include/linux/efi-bgrt.h | 5 + include/linux/efi.h | 5 +- 23 files changed, 328 insertions(+), 138 deletions(-) rename {arch/x86/platform => drivers/firmware}/efi/efi-bgrt.c (100%) ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer @ 2017-04-04 16:02 ` Ard Biesheuvel 0 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-04-04 16:02 UTC (permalink / raw) To: linux-efi, Ingo Molnar, Thomas Gleixner, H . Peter Anvin Cc: Ard Biesheuvel, linux-kernel 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 ^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer @ 2017-04-04 16:02 ` Ard Biesheuvel 0 siblings, 0 replies; 23+ messages in thread From: Ard Biesheuvel @ 2017-04-04 16:02 UTC (permalink / raw) To: linux-efi-u79uwXL29TY76Z2rM5mHXA, Ingo Molnar, Thomas Gleixner, H . Peter Anvin Cc: Ard Biesheuvel, linux-kernel-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply related [flat|nested] 23+ messages in thread
end of thread, other threads:[~2017-05-19 22:04 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-04 15:27 [GIT PULL 0/2] EFI fixes for v4.11 Ard Biesheuvel 2017-04-04 15:27 ` Ard Biesheuvel 2017-04-04 15:27 ` [PATCH 1/2] efi/libstub: Skip GOP with PIXEL_BLT_ONLY format Ard Biesheuvel 2017-04-05 7:57 ` [tip:efi/urgent] " tip-bot for Cohen, Eugene 2017-04-04 15:27 ` [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer Ard Biesheuvel 2017-04-05 7:58 ` [tip:efi/urgent] efi/fb: " tip-bot for Ard Biesheuvel 2017-04-05 10:30 ` tip-bot for Ard Biesheuvel 2017-05-19 16:27 ` [PATCH 2/2] efifb: " 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 [not found] ` <CGME20170405100833epcas1p4b5076679dc4f8644fa789b421a66f953@epcas1p4.samsung.com> 2017-04-05 10:08 ` [GIT PULL 0/2] EFI fixes for v4.11 Bartlomiej Zolnierkiewicz 2017-04-05 10:14 ` Ard Biesheuvel 2017-04-05 10:14 ` Ard Biesheuvel 2017-04-05 10:26 ` Ingo Molnar 2017-04-05 10:32 ` Ard Biesheuvel 2017-04-05 10:44 ` Bartlomiej Zolnierkiewicz 2017-04-05 10:44 ` Bartlomiej Zolnierkiewicz 2017-04-05 10:45 ` Ard Biesheuvel 2017-04-04 16:02 [GIT PULL 00/12] EFI updates for v4.12 Ard Biesheuvel 2017-04-04 16:02 ` [PATCH 2/2] efifb: Avoid reconfiguration of BAR that covers the framebuffer Ard Biesheuvel 2017-04-04 16:02 ` Ard Biesheuvel
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.