[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b76444fed0a2468983b2a2c45d7d31b2@huawei.com>
Date: Fri, 24 Jul 2020 09:00:41 +0000
From: Shiju Jose <shiju.jose@...wei.com>
To: Bjorn Helgaas <helgaas@...nel.org>
CC: "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"rjw@...ysocki.net" <rjw@...ysocki.net>,
"bp@...en8.de" <bp@...en8.de>,
"james.morse@....com" <james.morse@....com>,
"lenb@...nel.org" <lenb@...nel.org>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"dan.carpenter@...cle.com" <dan.carpenter@...cle.com>,
"zhangliguang@...ux.alibaba.com" <zhangliguang@...ux.alibaba.com>,
"andriy.shevchenko@...ux.intel.com"
<andriy.shevchenko@...ux.intel.com>,
"Wangkefeng (OS Kernel Lab)" <wangkefeng.wang@...wei.com>,
"jroedel@...e.de" <jroedel@...e.de>,
Linuxarm <linuxarm@...wei.com>,
yangyicong <yangyicong@...wei.com>,
Jonathan Cameron <jonathan.cameron@...wei.com>,
tanxiaofei <tanxiaofei@...wei.com>
Subject: RE: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown
(vendor) CPER records
Hi Bjorn,
Thanks for reviewing.
>-----Original Message-----
>From: Bjorn Helgaas [mailto:helgaas@...nel.org]
>Sent: 24 July 2020 00:21
>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 (OS Kernel Lab)
><wangkefeng.wang@...wei.com>; jroedel@...e.de; Linuxarm
><linuxarm@...wei.com>; yangyicong <yangyicong@...wei.com>; Jonathan
>Cameron <jonathan.cameron@...wei.com>; tanxiaofei
><tanxiaofei@...wei.com>
>Subject: Re: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown
>(vendor) CPER records
>
>On Wed, Jul 22, 2020 at 11:39:51AM +0100, Shiju Jose wrote:
>> CPER records describing a firmware-first error are identified by 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).
>
>> +#ifdef CONFIG_ACPI_APEI_GHES
>> +/**
>> + * ghes_register_vendor_record_notifier - register a notifier for
>> +vendor
>> + * records that the kernel would otherwise ignore.
>> + * @nb: pointer to the notifier_block structure of the event handler.
>> + *
>> + * return 0 : SUCCESS, non-zero : FAIL */ int
>> +ghes_register_vendor_record_notifier(struct notifier_block *nb);
>> +
>> +/**
>> + * ghes_unregister_vendor_record_notifier - unregister the previously
>> + * registered vendor record notifier.
>> + * @nb: pointer to the notifier_block structure of the vendor record
>handler.
>> + */
>> +void ghes_unregister_vendor_record_notifier(struct notifier_block
>> +*nb); #else static inline int
>> +ghes_register_vendor_record_notifier(struct notifier_block *nb) {
>> + return -ENODEV;
>> +}
>> +
>> +static inline void ghes_unregister_vendor_record_notifier(struct
>> +notifier_block *nb) { }
>
>If you made CONFIG_PCIE_HISI_ERR depend on CONFIG_ACPI_APEI_GHES,
>you'd be able to get rid of these stubs, wouldn't you? It doesn't look like
>there's any point in building pcie-hisi-error.c at all unless
>CONFIG_ACPI_APEI_GHES is enabled.
The stub is added because this interface is expected to use by the other drivers as well.
Some drivers may not want add the build depend on the CONFIG_ACPI_APEI_GHES
if the error reporting has less priority in the driver.
However we can add dependency on CONFIG_ACPI_APEI_GHES for building pcie-hisi-error.c.
>
>> +#endif
>> +
>> int ghes_estatus_pool_init(int num_ghes);
>>
>> /* From drivers/edac/ghes_edac.c */
>> --
>> 2.17.1
>>
>>
Thanks,
Shiju
Powered by blists - more mailing lists