[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140924131822.GN18635@console-pimps.org>
Date: Wed, 24 Sep 2014 14:18:22 +0100
From: Matt Fleming <matt@...sole-pimps.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@...onical.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Matt Fleming <matt.fleming@...el.com>,
Leif Lindholm <leif.lindholm@...aro.org>,
Roy Franz <roy.franz@...aro.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Josh Boyer <jwboyer@...hat.com>
Subject: Re: [GIT PULL] x86 fixes
On Wed, 24 Sep, at 03:08:16PM, Ingo Molnar wrote:
>
> * Matt Fleming <matt@...sole-pimps.org> wrote:
>
> > +/*
> > + * There's no way to return an informative status from this function,
> > + * because any analysis (and printing of error messages) needs to be
> > + * done directly at the EFI function call-site.
> > + *
> > + * For example, EFI_INVALID_PARAMETER could indicate a bug or maybe we
> > + * just didn't find any PCI devices, but there's no way to tell outside
> > + * the context of the call.
> > + */
> > +static void setup_efi_pci(struct boot_params *params)
>
> Btw., do we print proper complaints at the EFI call sites if such
> failures do happen (and if that failure is unexpected/bad)?
Not yet, but I've got a patch queued up for v3.18 that does this.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists