All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: "Josh Boyer" <jwboyer@fedoraproject.org>,
	"Môshe van der Sterre" <me@moshe.nl>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	"Colin Ian King" <colin.king@canonical.com>,
	"Ricardo Neri" <ricardo.neri-calderon@linux.intel.com>
Subject: Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT
Date: Sat, 30 Apr 2016 16:13:41 -0700	[thread overview]
Message-ID: <20160430231341.GA18955@x> (raw)
In-Reply-To: <20160430223514.GP2839@codeblueprint.co.uk>

On Sat, Apr 30, 2016 at 11:35:14PM +0100, Matt Fleming wrote:
> (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.

Fine.  What's the highest priority message that will *not* cause splash
screens to go into text mode?  With the default boot argument of
"quiet", pr_notice or pr_info should still remain hidden, right?  So,
could we make these pr_notice, rather than pr_debug?  That way they'll
at least show up in logs, even though they don't show up on the console.

> 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.

BITS doesn't, but should; I've added it to the TODO list.

- Josh Triplett

WARNING: multiple messages have this Message-ID (diff)
From: Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>
To: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Cc: "Josh Boyer"
	<jwboyer-rxtnV0ftBwyoClj4AeEUq9i2O/JbrIOy@public.gmane.org>,
	"Môshe van der Sterre" <me-A/3C56C7qwM@public.gmane.org>,
	"linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Linux-Kernel@Vger. Kernel. Org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Colin Ian King"
	<colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	"Ricardo Neri"
	<ricardo.neri-calderon-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Subject: Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT
Date: Sat, 30 Apr 2016 16:13:41 -0700	[thread overview]
Message-ID: <20160430231341.GA18955@x> (raw)
In-Reply-To: <20160430223514.GP2839-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>

On Sat, Apr 30, 2016 at 11:35:14PM +0100, Matt Fleming wrote:
> (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.

Fine.  What's the highest priority message that will *not* cause splash
screens to go into text mode?  With the default boot argument of
"quiet", pr_notice or pr_info should still remain hidden, right?  So,
could we make these pr_notice, rather than pr_debug?  That way they'll
at least show up in logs, even though they don't show up on the console.

> 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.

BITS doesn't, but should; I've added it to the TODO list.

- Josh Triplett

  parent reply	other threads:[~2016-04-30 23:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-27 12:50 [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT Josh Boyer
2016-04-27 13:26 ` Môshe van der Sterre
2016-04-27 13:26   ` Môshe van der Sterre
2016-04-27 13:56   ` Josh Boyer
2016-04-27 14:57     ` Môshe van der Sterre
2016-04-27 15:20       ` Josh Boyer
2016-04-27 17:05         ` Josh Triplett
2016-04-27 17:05           ` Josh Triplett
2016-04-27 17:23           ` Josh Boyer
2016-04-27 17:23             ` Josh Boyer
2016-04-30 22:35             ` Matt Fleming
2016-04-30 22:35               ` Matt Fleming
2016-04-30 22:42               ` Colin Ian King
2016-04-30 22:42                 ` Colin Ian King
2016-04-30 23:13               ` Josh Triplett [this message]
2016-04-30 23:13                 ` Josh Triplett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160430231341.GA18955@x \
    --to=josh@joshtriplett.org \
    --cc=colin.king@canonical.com \
    --cc=jwboyer@fedoraproject.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=me@moshe.nl \
    --cc=ricardo.neri-calderon@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.