lkml.org 
[lkml]   [2018]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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.

\
 
 \ /
  Last update: 2018-03-30 13:25    [W:0.099 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site