Messages in this thread | | | From | Ard Biesheuvel <> | Date | Fri, 30 Mar 2018 12:25:23 +0100 | Subject | Re: [PATCH v3 3/8] efi: Decode IA32/X64 Processor Error Info Structure |
| |
On 29 March 2018 at 14:53, Ghannam, Yazen <Yazen.Ghannam@amd.com> wrote: >> -----Original Message----- >> From: Borislav Petkov <bp@alien8.de> >> Sent: Thursday, March 29, 2018 6:55 AM >> To: Ghannam, Yazen <Yazen.Ghannam@amd.com> >> Cc: linux-efi@vger.kernel.org; linux-kernel@vger.kernel.org; >> ard.biesheuvel@linaro.org; x86@kernel.org; tony.luck@intel.com >> Subject: Re: [PATCH v3 3/8] efi: Decode IA32/X64 Processor Error Info >> Structure >> >> On Sat, Mar 24, 2018 at 01:49:35PM -0500, Yazen Ghannam wrote: >> > From: Yazen Ghannam <yazen.ghannam@amd.com> >> > >> > Print the fields in the IA32/X64 Processor Error Info Structure. >> > >> > Based on UEFI 2.7 Table 253. IA32/X64 Processor Error Information >> > Structure. >> > >> > Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> >> > --- >> > Link: >> > https://lkml.kernel.org/r/20180226193904.20532-4- >> Yazen.Ghannam@amd.com >> > >> > v2->v3: >> > * Fix table number in commit message. >> > * Don't print raw validation bits. >> > >> > v1->v2: >> > * Add parantheses around "bits" expression in macro. >> > * Fix indentation on multi-line statements. >> > >> > drivers/firmware/efi/cper-x86.c | 50 >> +++++++++++++++++++++++++++++++++++++++++ >> > 1 file changed, 50 insertions(+) >> > >> > diff --git a/drivers/firmware/efi/cper-x86.c b/drivers/firmware/efi/cper- >> x86.c >> > index 863f0cd2a0ff..a9ab3bbf7986 100644 >> > --- a/drivers/firmware/efi/cper-x86.c >> > +++ b/drivers/firmware/efi/cper-x86.c >> > @@ -3,15 +3,28 @@ >> > >> > #include <linux/cper.h> >> > >> > +#define INDENT_SP " " >> >> There's that thing again. So it was a total waste of time discussing >> this last time. So let me save my time this time: >> >> NAKed-by: Borislav Petkov <bp@suse.de> >> > > IIRC, the arguments for keeping this are > 1) convention for CPER > 2) code readability > > The argument against was > 1) it's dumb > > So I decided to keep it. I don't really mind either way so I'll change it > if there's a second opinion. >
Yes, please change it.
| |