linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Cc: "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure
Date: Tue, 27 Feb 2018 18:04:23 +0100	[thread overview]
Message-ID: <20180227170423.GK26382@pd.tnic> (raw)
In-Reply-To: <DM5PR12MB191637C1857C5D9499D08D66F8C00@DM5PR12MB1916.namprd12.prod.outlook.com>

On Tue, Feb 27, 2018 at 03:25:06PM +0000, Ghannam, Yazen wrote:
> This is the same as the other CPER code.

Dude, turn on brain!

So if it is in the other CPER code, we should copy it, no matter how
dumb it is?!?

> Also, the spec allows platform-defined GUIDs. So we should always print this
> even if the GUID is not defined by the spec.

We need to have a way to map the GUID to a hw part. Dumb numbers mean shit
because the error record is worthless.

> The Check Information will be decoded further in another patch.
> 
> I don't think there's much else to decode for the ID fields.

Again, those numbers can't help decoding the error, no need to dump
them. Or we find a way to make sense out of that info.

> Other tables may have the same fields but the offsets are usually different.
> So it may be more trouble than it's worth trying to unify the different tables.

If the structs are the same, you can use generic functions for dumping -
the offsets are meaningless then.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

  reply	other threads:[~2018-02-27 17:05 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26 19:38 [PATCH v2 0/8] Decode IA32/X64 CPER Yazen Ghannam
2018-02-26 19:38 ` [PATCH v2 1/8] efi: Fix IA32/X64 Processor Error Record definition Yazen Ghannam
2018-02-27 10:47   ` Borislav Petkov
2018-02-27 15:05     ` Ghannam, Yazen
2018-02-26 19:38 ` [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section Yazen Ghannam
2018-02-27 11:22   ` Borislav Petkov
2018-02-27 15:13     ` Ghannam, Yazen
2018-02-27 17:00       ` Borislav Petkov
2018-02-27 17:27         ` Ghannam, Yazen
2018-02-27 17:44           ` Borislav Petkov
2018-02-27 18:06             ` Ghannam, Yazen
2018-02-27 18:34               ` Borislav Petkov
2018-02-26 19:38 ` [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure Yazen Ghannam
2018-02-27 14:25   ` Borislav Petkov
2018-02-27 15:25     ` Ghannam, Yazen
2018-02-27 17:04       ` Borislav Petkov [this message]
2018-02-27 17:46         ` Ghannam, Yazen
2018-02-27 18:02           ` Borislav Petkov
2018-02-27 18:40             ` Ghannam, Yazen
2018-02-27 19:09               ` Borislav Petkov
2018-02-27 21:32                 ` Ghannam, Yazen
2018-02-27 22:10                   ` Borislav Petkov
2018-02-26 19:39 ` [PATCH v2 4/8] efi: Decode UEFI-defined IA32/X64 Error Structure GUIDs Yazen Ghannam
2018-02-27 14:30   ` Borislav Petkov
2018-02-27 15:28     ` Ghannam, Yazen
2018-02-27 15:31       ` Ard Biesheuvel
2018-02-26 19:39 ` [PATCH v2 5/8] efi: Decode IA32/X64 Cache, TLB, and Bus Check structures Yazen Ghannam
2018-02-27 15:03   ` Borislav Petkov
2018-02-27 15:33     ` Ghannam, Yazen
2018-02-27 17:06       ` Borislav Petkov
2018-02-26 19:39 ` [PATCH v2 6/8] efi: Decode additional IA32/X64 Bus Check fields Yazen Ghannam
2018-02-26 19:39 ` [PATCH v2 7/8] efi: Decode IA32/X64 MS Check structure Yazen Ghannam
2018-02-26 19:39 ` [PATCH v2 8/8] efi: Decode IA32/X64 Context Info structure Yazen Ghannam
2018-02-28  8:43 ` [PATCH v2 0/8] Decode IA32/X64 CPER Borislav Petkov
2018-02-28 15:12   ` Ghannam, Yazen
2018-02-28 16:35     ` Borislav Petkov
2018-02-28 20:58       ` Ghannam, Yazen
2018-03-01 11:59         ` Borislav Petkov
2018-03-23  0:19           ` Ghannam, Yazen
2018-03-23 15:29             ` Borislav Petkov
2018-03-01 16:38   ` Luck, Tony

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=20180227170423.GK26382@pd.tnic \
    --to=bp@suse.de \
    --cc=Yazen.Ghannam@amd.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).