[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM5PR12MB1916D75D9526C2DB22D16CABF8C10@DM5PR12MB1916.namprd12.prod.outlook.com>
Date: Mon, 26 Feb 2018 15:46:18 +0000
From: "Ghannam, Yazen" <Yazen.Ghannam@....com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
CC: "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...e.de>,
the arch/x86 maintainers <x86@...nel.org>
Subject: RE: [PATCH 0/8] Decode IA32/X64 CPER
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@...aro.org]
> Sent: Saturday, February 24, 2018 11:47 AM
> To: Ghannam, Yazen <Yazen.Ghannam@....com>
> Cc: linux-efi@...r.kernel.org; Linux Kernel Mailing List <linux-
> kernel@...r.kernel.org>; Borislav Petkov <bp@...e.de>; the arch/x86
> maintainers <x86@...nel.org>
> Subject: Re: [PATCH 0/8] Decode IA32/X64 CPER
>
> Hi Yazen,
>
> On 23 February 2018 at 20:03, Yazen Ghannam
> <Yazen.Ghannam@....com> wrote:
> > From: Yazen Ghannam <yazen.ghannam@....com>
> >
> > This series adds decoding for the IA32/X64 Common Platform Error Record.
> >
> > Patch 1 fixes the IA32/X64 Processor Error Section definition to match
> > the UEFI spec.
> >
> > Patches 2-8 add the new decoding. The patches incrementally add the
> > decoding starting from the top-level "Error Section". Hopefully, this
> > will make reviewing a bit easier compared to one large patch.
> >
> > The formatting of the field names and options is taken from the UEFI
> > spec. I tried to keep everything the same to make searching easier.
> >
> > The patches were written to the UEFI 2.7 spec though the definition of
> > the IA32/X64 CPER seems to be the same as when it was introduced in
> > the UEFI 2.1 spec.
> >
> > Without basic decoding, users will be confused about what these
> > "Hardware Errors" mean. So I'm requesting this set to be applied to the
> > stable branches. This set applies to the v4.16. However, patch 2 will
> > have a conflict on older branches, so I'll send this set again with the
> > conflict fixed.
> >
>
> These patches look mostly fine to me, with the exception of some minor nits.
>
> I can queue this for v4.17 if you respin it, but I am not sending 400
> lines of brand new error record parsing code to Greg for inclusion in
> -stable, so please drop the cc stable tags
>
Okay, will do.
Thanks,
Yazen
Powered by blists - more mailing lists