Received: by 10.223.185.116 with SMTP id b49csp5187893wrg; Tue, 27 Feb 2018 09:07:47 -0800 (PST) X-Google-Smtp-Source: AH8x2240aZdla61ybmGvQiC6cXfAO/et7v/UOP1U/XHrE7bZ6x7Z5ti+JOS+v++lAH89IFpDa9eX X-Received: by 10.99.54.196 with SMTP id d187mr11904790pga.154.1519751267828; Tue, 27 Feb 2018 09:07:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519751267; cv=none; d=google.com; s=arc-20160816; b=ORXZFNT8n0M3tn47Q0Y2+Fci6fYc0ZsfTGvqJV5buNGe4riBiSEAPh1uZO265E9a52 zIfDZB3q0iNZ3zUsReKDVMX65UQubzcU9/AxQZ3fg0PO0a1U6PcpKnHGo0f/eJUQhZoH G6abHhdABlk+jITQt0Lf/ZFfmAvQFZs2M5rjem6Tiyu9yDzdRnA54lKIEpBRSwSisC2K HSylAlSrTKFTNaNJ8XhXqRRlLr+iDpNRBSApJg7/P3Qo0CtsyOjN4WjD01Vkisyor+qO e8bZWOt9Oj28IUwdquWWsxkBa2TosiBYjNcLTMe1PbzJKvehoPKpab58e1NDEVwoOsKa LSMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=6XW3WVLJDgpXrpB8VhBAdLtbh1B12tHBkjJPskEjsns=; b=P/yiGn+sKC6TXohW16fkmxHbyazjJdrmgt/PxbKAH65aLjoKapRpm50mgmR5NOkpRI oEpGEttHwAOji6oDZ2oOfED1P4w3DcFVpp3AAqUUXAlveDfxbYYa3r51J3seH8Oy6z4O dcZOFTaq34mwe5B34ZGwVn5DOWE9oaS9SreHJR+E6HawoTZDT/hUl272GjglUCkskxNg eyXOV0FwGfAuxaB23gjnK1XhR/AM5IWjJwsNJyAuDco6lONe1Dmz8GsImmQSkMr6cv6k yfnFhDDvO/gdniIArCmMQwAI+wgWV7+KtuiUac0diKLcxp38G9r/wwHFIZ5trDuqIY9m /80A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j10si7294677pgn.571.2018.02.27.09.07.26; Tue, 27 Feb 2018 09:07:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752217AbeB0RFA (ORCPT + 99 others); Tue, 27 Feb 2018 12:05:00 -0500 Received: from mx2.suse.de ([195.135.220.15]:47605 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752003AbeB0REp (ORCPT ); Tue, 27 Feb 2018 12:04:45 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id E671BAD39; Tue, 27 Feb 2018 17:04:43 +0000 (UTC) Date: Tue, 27 Feb 2018 18:04:23 +0100 From: Borislav Petkov To: "Ghannam, Yazen" Cc: "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "ard.biesheuvel@linaro.org" , "x86@kernel.org" Subject: Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure Message-ID: <20180227170423.GK26382@pd.tnic> References: <20180226193904.20532-1-Yazen.Ghannam@amd.com> <20180226193904.20532-4-Yazen.Ghannam@amd.com> <20180227142531.GF26382@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) --