[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200714205500.GA418237@bjorn-Precision-5520>
Date: Tue, 14 Jul 2020 15:55:00 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Shiju Jose <shiju.jose@...wei.com>
Cc: linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, rjw@...ysocki.net, bp@...en8.de,
james.morse@....com, lenb@...nel.org, tony.luck@...el.com,
dan.carpenter@...cle.com, zhangliguang@...ux.alibaba.com,
andriy.shevchenko@...ux.intel.com, wangkefeng.wang@...wei.com,
jroedel@...e.de, linuxarm@...wei.com, yangyicong@...ilicon.com,
jonathan.cameron@...wei.com, tanxiaofei@...wei.com
Subject: Re: [PATCH v12 1/2] ACPI / APEI: Add a notifier chain for unknown
(vendor) CPER records
On Mon, Jul 13, 2020 at 03:09:00PM +0100, Shiju Jose wrote:
> CPER records describing a firmware-first error are identified by GUID.
Does the spec really connect "firmware-first" and CPER records? Are
there non-firmware-first CPER records?
This sentence suggests that firmware-first CPER records are identified
by GUID, and that there are non-firmware-first CPER records that might
not be identified by GUID.
I suspect this would be better as simply:
CPER records are identified by a Notification Type GUID.
(Or maybe it's a Section Type GUID?)
> The ghes driver currently logs, but ignores any unknown CPER records.
> This prevents describing errors that can't be represented by a standard
> entry, that would otherwise allow a driver to recover from an error.
> The UEFI spec calls these 'Non-standard Section Body' (N.2.3 of
> version 2.8).
>
> Add a notifier chain for these non-standard/vendor-records. Callers
> must identify their type of records by GUID.
>
> Record data is copied to memory from the ghes_estatus_pool to allow
> us to keep it until after the notifier has run.
Powered by blists - more mailing lists