[GIT PULL 0/3] EFI urgent fixes

[GIT PULL 0/3] EFI urgent fixes

[Matt Fleming]

Folks, here are a few small fixes. One from Josh to stop the ACPI BGRT
driver wrecking the splash screen even though the "quiet" kernel
parameter is passed, another to fix sysfb_efi on a ThinkPad E550, and
one to MAINTAINERS so that get_maintainer.pl finds the EFI entry for
all subdirectores of drivers/firmware/efi/.
 
The following changes since commit 04974df8049fc4240d22759a91e035082ccd18b4:

  Linux 4.6-rc6 (2016-05-01 15:52:31 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent

for you to fetch changes up to c255f4fb93d2d92527ede3f57f90b4eb1698bbec:

  x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT (2016-05-03 20:02:25 +0100)

----------------------------------------------------------------
 * Fix sysfb_efi to detect BARs starting at 0x0, which otherwise makes
   video=efifb not work on some the ThinkPad E550 - Wang YanQing

 * Update the MAINTAINERS entry for EFI by removing the trailing
   asterisk characters which was intended to denote "all
   subdirectories" but which breaks get_maintainer.pl - Matt Fleming

 * Convert ACPI BGRT driver messages from pr_err() to pr_notice() to
   avoid spewing messages all over the display and making it
   impossible for users to have a pretty boot experience - Josh Boyer

----------------------------------------------------------------
Josh Boyer (1):
      x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

Matt Fleming (1):
      MAINTAINERS: Remove asterisk from EFI directory names

Wang YanQing (1):
      x86/sysfb_efi: Fix valid BAR address range check

 MAINTAINERS                      |  4 ++--
 arch/x86/kernel/sysfb_efi.c      | 14 ++++++++++++--
 arch/x86/platform/efi/efi-bgrt.c | 18 +++++++++---------
 3 files changed, 23 insertions(+), 13 deletions(-)

[PATCH 1/3] MAINTAINERS: Remove asterisk from EFI directory names

[Matt Fleming]

Mark reported that having asterisks on the end of directory names
confuses get_maintainer.pl when it encounters subdirectories, and that
my name does not appear when run on drivers/firmware/efi/libstub.

Reported-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Signed-off-by: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 42e65d128d01..4dca3b3895ba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4223,8 +4223,8 @@ F:	Documentation/efi-stub.txt
 F:	arch/ia64/kernel/efi.c
 F:	arch/x86/boot/compressed/eboot.[ch]
 F:	arch/x86/include/asm/efi.h
-F:	arch/x86/platform/efi/*
-F:	drivers/firmware/efi/*
+F:	arch/x86/platform/efi/
+F:	drivers/firmware/efi/
 F:	include/linux/efi*.h
 
 EFI VARIABLE FILESYSTEM
-- 
2.7.3

[PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

[Matt Fleming]

From: Wang YanQing <udknight@gmail.com>

We can't just break out when meet start is equal to zero,
this will cause us to miss valid address ranges in later BARs.

On the other hand, it isn't enough to test start only
for below situation:

  0(start) <= lfb_base < end

Due to the BUG this patch fix, I can't use video=efifb:
boot parameter to get efifb on my new ThinkPad E550 for
my old linux system hard disk with 3.10 kernel. In 3.10,
efifb is the only choice due to DRM/I915 in it doesn't
support the GPU.

This patch also add a trivial optimization, break out
after we find the address range is valid without test
later BARs.

Signed-off-by: Wang YanQing <udknight@gmail.com>
Reviewed-by: Peter Jones <pjones@redhat.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: <stable@vger.kernel.org>
[ Updated changelog ]
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
 arch/x86/kernel/sysfb_efi.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/sysfb_efi.c b/arch/x86/kernel/sysfb_efi.c
index b285d4e8c68e..5da924bbf0a0 100644
--- a/arch/x86/kernel/sysfb_efi.c
+++ b/arch/x86/kernel/sysfb_efi.c
@@ -106,14 +106,24 @@ static int __init efifb_set_system(const struct dmi_system_id *id)
 					continue;
 				for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
 					resource_size_t start, end;
+					unsigned long flags;
+
+					flags = pci_resource_flags(dev, i);
+					if (!(flags & IORESOURCE_MEM))
+						continue;
+
+					if (flags & IORESOURCE_UNSET)
+						continue;
+
+					if (pci_resource_len(dev, i) == 0)
+						continue;
 
 					start = pci_resource_start(dev, i);
-					if (start == 0)
-						break;
 					end = pci_resource_end(dev, i);
 					if (screen_info.lfb_base >= start &&
 					    screen_info.lfb_base < end) {
 						found_bar = 1;
+						break;
 					}
 				}
 			}
-- 
2.7.3

Re: [PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

[Ingo Molnar]

* Matt Fleming <matt@codeblueprint.co.uk> wrote:

> From: Wang YanQing <udknight@gmail.com>
> 
> We can't just break out when meet start is equal to zero,

Hm, wot?

Thanks,

	Ingo

Re: [PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

[Matt Fleming]

On Wed, 04 May, at 08:35:24AM, Ingo Molnar wrote:
> 
> * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> 
> > From: Wang YanQing <udknight@gmail.com>
> > 
> > We can't just break out when meet start is equal to zero,
> 
> Hm, wot?

The existing code treats address 0x0 as invalid for a PCI BAR range
start address, but 0x0 is actually possible and legitimate, so we
shouldn't be breaking out of the loop.

Re: [PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

[Ingo Molnar]

* Matt Fleming <matt@codeblueprint.co.uk> wrote:

> On Wed, 04 May, at 08:35:24AM, Ingo Molnar wrote:
> > 
> > * Matt Fleming <matt@codeblueprint.co.uk> wrote:
> > 
> > > From: Wang YanQing <udknight@gmail.com>
> > > 
> > > We can't just break out when meet start is equal to zero,
> > 
> > Hm, wot?
> 
> The existing code treats address 0x0 as invalid for a PCI BAR range
> start address, but 0x0 is actually possible and legitimate, so we
> shouldn't be breaking out of the loop.

Yeah, so I just don't understand the 'when meet start is equal to zero' part - 
what does it mean?

Thanks,

	Ingo

Re: [PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

[Matt Fleming]

On Wed, 04 May, at 12:23:40PM, Ingo Molnar wrote:
> 
> * Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:
> 
> > On Wed, 04 May, at 08:35:24AM, Ingo Molnar wrote:
> > > 
> > > * Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:
> > > 
> > > > From: Wang YanQing <udknight-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > 
> > > > We can't just break out when meet start is equal to zero,
> > > 
> > > Hm, wot?
> > 
> > The existing code treats address 0x0 as invalid for a PCI BAR range
> > start address, but 0x0 is actually possible and legitimate, so we
> > shouldn't be breaking out of the loop.
> 
> Yeah, so I just don't understand the 'when meet start is equal to zero' part - 
> what does it mean?

I suspect it means "when start is equal to zero" or "when we encounter
the scenario where start is equal to zero".

Wang?

Re: [PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

[Wang YanQing]

On Wed, May 04, 2016 at 08:35:24AM +0200, Ingo Molnar wrote:
> 
> * Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:
> 
> > From: Wang YanQing <udknight-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > 
> > We can't just break out when meet start is equal to zero,
> 
> Hm, wot?
> 
> Thanks,
> 
> 	Ingo

Sorry for my poor English ,and poor commit message, this bring
trouble for more than one maintainer, I guess.

The old code use below comparion as condition to terminate valid 
range check without care whether there are more ranges in later
BARs:
"
        if (start == 0)
            break;
"

I guess original author think (or make a mistake) when we meet a 
address range begin from zero means it is a invalid address range, 
and no valid address ranges in remain BARs.

So I said:
We can't break the loop when meet range whose start address is zero,
without check it and remaining BARs' range.

Thanks.

[PATCH 3/3] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

[Matt Fleming]

From: Josh Boyer <jwboyer@fedoraproject.org>

The promise of pretty boot splashes from firmware via BGRT was at
best only that; a promise.  The kernel diligently checks to make
sure the BGRT data firmware gives it is valid, and dutifully warns
the user when it isn't.  However, it does so via the pr_err log
level which seems unnecessary.  The user cannot do anything about
this and there really isn't an error on the part of Linux to
correct.

This lowers the log level by using pr_notice instead.  Users will
no longer have their boot process uglified by the kernel reminding
us that firmware can and often is broken when the 'quiet' kernel
parameter is specified.  Ironic, considering BGRT is supposed to
make boot pretty to begin with.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Cc: Môshe van der Sterre <me@moshe.nl>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
---
 arch/x86/platform/efi/efi-bgrt.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
index a2433817c987..6a2f5691b1ab 100644
--- a/arch/x86/platform/efi/efi-bgrt.c
+++ b/arch/x86/platform/efi/efi-bgrt.c
@@ -43,40 +43,40 @@ void __init efi_bgrt_init(void)
 		return;
 
 	if (bgrt_tab->header.length < sizeof(*bgrt_tab)) {
-		pr_err("Ignoring BGRT: invalid length %u (expected %zu)\n",
+		pr_notice("Ignoring BGRT: invalid length %u (expected %zu)\n",
 		       bgrt_tab->header.length, sizeof(*bgrt_tab));
 		return;
 	}
 	if (bgrt_tab->version != 1) {
-		pr_err("Ignoring BGRT: invalid version %u (expected 1)\n",
+		pr_notice("Ignoring BGRT: invalid version %u (expected 1)\n",
 		       bgrt_tab->version);
 		return;
 	}
 	if (bgrt_tab->status & 0xfe) {
-		pr_err("Ignoring BGRT: reserved status bits are non-zero %u\n",
+		pr_notice("Ignoring BGRT: reserved status bits are non-zero %u\n",
 		       bgrt_tab->status);
 		return;
 	}
 	if (bgrt_tab->image_type != 0) {
-		pr_err("Ignoring BGRT: invalid image type %u (expected 0)\n",
+		pr_notice("Ignoring BGRT: invalid image type %u (expected 0)\n",
 		       bgrt_tab->image_type);
 		return;
 	}
 	if (!bgrt_tab->image_address) {
-		pr_err("Ignoring BGRT: null image address\n");
+		pr_notice("Ignoring BGRT: null image address\n");
 		return;
 	}
 
 	image = memremap(bgrt_tab->image_address, sizeof(bmp_header), MEMREMAP_WB);
 	if (!image) {
-		pr_err("Ignoring BGRT: failed to map image header memory\n");
+		pr_notice("Ignoring BGRT: failed to map image header memory\n");
 		return;
 	}
 
 	memcpy(&bmp_header, image, sizeof(bmp_header));
 	memunmap(image);
 	if (bmp_header.id != 0x4d42) {
-		pr_err("Ignoring BGRT: Incorrect BMP magic number 0x%x (expected 0x4d42)\n",
+		pr_notice("Ignoring BGRT: Incorrect BMP magic number 0x%x (expected 0x4d42)\n",
 			bmp_header.id);
 		return;
 	}
@@ -84,14 +84,14 @@ void __init efi_bgrt_init(void)
 
 	bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL | __GFP_NOWARN);
 	if (!bgrt_image) {
-		pr_err("Ignoring BGRT: failed to allocate memory for image (wanted %zu bytes)\n",
+		pr_notice("Ignoring BGRT: failed to allocate memory for image (wanted %zu bytes)\n",
 		       bgrt_image_size);
 		return;
 	}
 
 	image = memremap(bgrt_tab->image_address, bmp_header.size, MEMREMAP_WB);
 	if (!image) {
-		pr_err("Ignoring BGRT: failed to map image memory\n");
+		pr_notice("Ignoring BGRT: failed to map image memory\n");
 		kfree(bgrt_image);
 		bgrt_image = NULL;
 		return;
-- 
2.7.3