From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932993AbbHIKYZ (ORCPT ); Sun, 9 Aug 2015 06:24:25 -0400 Received: from terminus.zytor.com ([198.137.202.10]:36050 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932977AbbHIKYW (ORCPT ); Sun, 9 Aug 2015 06:24:22 -0400 Date: Sun, 9 Aug 2015 03:23:40 -0700 From: tip-bot for Matt Fleming Message-ID: Cc: mjg59@srcf.ucam.org, tglx@linutronix.de, mingo@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org, josh@joshtriplett.org, tom.ty89@gmail.com, torvalds@linux-foundation.org, matt.fleming@intel.com, peterz@infradead.org Reply-To: josh@joshtriplett.org, linux-kernel@vger.kernel.org, peterz@infradead.org, matt.fleming@intel.com, torvalds@linux-foundation.org, tom.ty89@gmail.com, tglx@linutronix.de, mjg59@srcf.ucam.org, hpa@zytor.com, mingo@kernel.org In-Reply-To: <1438936621-5215-2-git-send-email-matt@codeblueprint.co.uk> References: <1438936621-5215-2-git-send-email-matt@codeblueprint.co.uk> To: linux-tip-commits@vger.kernel.org Subject: [tip:core/efi] x86/efi-bgrt: Switch pr_err() to pr_debug() for invalid BGRT Git-Commit-ID: 248fbcd5aee00f6519a12c5ed3bc3dc0f5e84de5 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 248fbcd5aee00f6519a12c5ed3bc3dc0f5e84de5 Gitweb: http://git.kernel.org/tip/248fbcd5aee00f6519a12c5ed3bc3dc0f5e84de5 Author: Matt Fleming AuthorDate: Fri, 7 Aug 2015 09:36:55 +0100 Committer: Ingo Molnar CommitDate: Sat, 8 Aug 2015 10:37:39 +0200 x86/efi-bgrt: Switch pr_err() to pr_debug() for invalid BGRT It's totally legitimate, per the ACPI spec, for the firmware to set the BGRT 'status' field to zero to indicate that the BGRT image isn't being displayed, and we shouldn't be printing an error message in that case because it's just noise for users. So swap pr_err() for pr_debug(). However, Josh points that out it still makes sense to test the validity of the upper 7 bits of the 'status' field, since they're marked as "reserved" in the spec and must be zero. If firmware violates this it really *is* an error. Reported-by: Tom Yan Tested-by: Tom Yan Signed-off-by: Matt Fleming Reviewed-by: Josh Triplett Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Matthew Garrett Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1438936621-5215-2-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar --- arch/x86/platform/efi/efi-bgrt.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c index d7f997f..ea48449 100644 --- a/arch/x86/platform/efi/efi-bgrt.c +++ b/arch/x86/platform/efi/efi-bgrt.c @@ -50,11 +50,16 @@ void __init efi_bgrt_init(void) bgrt_tab->version); return; } - if (bgrt_tab->status != 1) { - pr_err("Ignoring BGRT: invalid status %u (expected 1)\n", + if (bgrt_tab->status & 0xfe) { + pr_err("Ignoring BGRT: reserved status bits are non-zero %u\n", bgrt_tab->status); return; } + if (bgrt_tab->status != 1) { + pr_debug("Ignoring BGRT: invalid status %u (expected 1)\n", + bgrt_tab->status); + return; + } if (bgrt_tab->image_type != 0) { pr_err("Ignoring BGRT: invalid image type %u (expected 0)\n", bgrt_tab->image_type);