Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752404AbcD3WfU (ORCPT ); Sat, 30 Apr 2016 18:35:20 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:35927 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752341AbcD3WfR (ORCPT ); Sat, 30 Apr 2016 18:35:17 -0400 Date: Sat, 30 Apr 2016 23:35:14 +0100 From: Matt Fleming To: Josh Boyer Cc: Josh Triplett , =?iso-8859-1?Q?M=F4she?= van der Sterre , "linux-efi@vger.kernel.org" , "Linux-Kernel@Vger. Kernel. Org" , Colin Ian King , Ricardo Neri Subject: Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT Message-ID: <20160430223514.GP2839@codeblueprint.co.uk> References: <1461761412-16046-1-git-send-email-jwboyer@fedoraproject.org> <5720BE0B.8080605@moshe.nl> <5720D365.5080601@moshe.nl> <20160427170525.GA1965@jtriplet-mobl2.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1493 Lines: 31 (Adding Colin and Ricardo) On Wed, 27 Apr, at 01:23:55PM, Josh Boyer wrote: > > How is an end user supposed to see such a message and report it to the > people that can fix it? They can't. So they report it in their > distributions bug tracker and it either gets closed as "yeah, firmware > sucks" or it sits there and rots in the hope that some day someone > will do something. > > I understand where you're coming from in a pre-production, development > environment but to be quite clear that is not the default environment > Linux is run in most of the time. If this were a kernel warning, that > could be fixed with a kernel patch, then maybe it would be worth it. > It isn't though. If the error messages in the BGRT driver make it impossible for end users to achieve a pretty boot experience then I agree, that is a kernel bug. BGRT is an exception to the usual rule about complaining loudly when we encounter firmware bugs simply because we're dealing with UIs in this case. That's not to say we should give up reporting these kinds of invalid table issues to firmware developers altogether. There are other means of doing it, and comprising the wants of many end users for the benefit of few firmware developers (relatively) is just not sensible. Colin, Ricardo, I haven't checked recently, are there ACPI BGRT validations tests in FWTS and LUV? Josh (Triplett), BITS would seem like a very good place to include these tests since it already has a bunch of ACPI table checks.