Linux-PCI Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH v13 0/2] ACPI / APEI: Add support to notify the vendor specific HW errors
@ 2020-07-22 10:39 Shiju Jose
  2020-07-22 10:39 ` [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records Shiju Jose
  0 siblings, 1 reply; 11+ messages in thread
From: Shiju Jose @ 2020-07-22 10:39 UTC (permalink / raw)
  To: linux-acpi, linux-pci, linux-kernel, rjw, helgaas, bp,
	james.morse, lenb, tony.luck, dan.carpenter, zhangliguang,
	andriy.shevchenko, wangkefeng.wang, jroedel
  Cc: linuxarm, yangyicong, jonathan.cameron, tanxiaofei

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).

patch set
1. add a notifier chain for these non-standard/vendor-records
   in the ghes driver.

2. add a driver to handle HiSilicon HIP PCIe controller's errors.
   
Changes:

V13:
1. Following changes in the HIP PCIe error handling driver.
1.1 Add Bjorn's acked-by.
1.2. Address the comments and macros order Bjorn mentioned.
     Fix the words in the commit.

V12:
1. Changed the Signed-off-by tag to Co-developed-by tag in the patch
   "ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records"

V11:
1. Following modifications made by James Morse in the APEI patch
   for the vendor error record.
   - Removed kfifo and ghes_gdata_pool. Expanded commit message.
   
2. Changes in the HIP PCIe error handling driver
   for the comments by Andy Shevchenko.

V10:
1. Changes for Bjorn's comments on HIP PCIe error handler driver
   and APEI patch.
   
2. Changes in the HIP PCIe error handler driver
   for the feedbacks by Andy Shevchenko.
   
V9:
1. Fixed 2 improvements suggested by the kbuild test robot. 
1.1 Change ghes_gdata_pool_init() as static function.
1.2. Removed using buffer to store the error data for
     logging in the hisi_pcie_handle_error()

V8:
1. Removed reporting the standard errors through the interface
   because of the conflict with the recent patches in the
   memory error handling path.
2. Fix comments by Dan Carpenter.
   
V7:
1. Add changes in the APEI driver suggested by Borislav Petkov, for
   queuing up all the non-fatal HW errors to the work queue and
   notify the registered kernel drivers from the bottom half using
   blocking notifier, common interface for both standard and
   vendor-spcific errors.
2. Fix for further feedbacks in v5 HIP PCIe error handler driver
   by Bjorn Helgaas.

V6:
1. Fix few changes in the patch subject line suggested by Bjorn Helgaas.

V5:
1. Fix comments from James Morse.
1.1 Changed the notification method to use the atomic_notifier_chain.
1.2 Add the error handled status for the user space.  

V4:
1. Fix for the following smatch warning in the PCIe error driver,
   reported by kbuild test robot<lkp@intel.com>:
   warn: should '((((1))) << (9 + i))' be a 64 bit type?
   if (err->val_bits & BIT(HISI_PCIE_LOCAL_VALID_ERR_MISC + i))
	^^^ This should be BIT_ULL() because it goes up to 9 + 32.

V3:
1. Fix the comments from Bjorn Helgaas.

V2:
1. Changes in the HiSilicon PCIe controller's error handling driver
   for the comments from Bjorn Helgaas.
   
2. Changes in the APEI interface to support reporting the vendor error
   for module with multiple devices, but use the same section type.
   In the error handler will use socket id/sub module id etc to distinguish
   the device.

V1:  
1. Fix comments from James Morse.

2. add driver to handle HiSilicon hip08 PCIe controller's errors,
   which is an application of the above interface.

Shiju Jose (1):
  ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records

Yicong Yang (1):
  PCI: hip: Add handling of HiSilicon HIP PCIe controller errors

 drivers/acpi/apei/ghes.c                 |  63 +++++
 drivers/pci/controller/Kconfig           |   8 +
 drivers/pci/controller/Makefile          |   1 +
 drivers/pci/controller/pcie-hisi-error.c | 327 +++++++++++++++++++++++
 include/acpi/ghes.h                      |  27 ++
 5 files changed, 426 insertions(+)
 create mode 100644 drivers/pci/controller/pcie-hisi-error.c

-- 
2.17.1



^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records
  2020-07-22 10:39 [PATCH v13 0/2] ACPI / APEI: Add support to notify the vendor specific HW errors Shiju Jose
@ 2020-07-22 10:39 ` Shiju Jose
  2020-07-22 11:01   ` Andy Shevchenko
  2020-07-23 23:20   ` Bjorn Helgaas
  0 siblings, 2 replies; 11+ messages in thread
From: Shiju Jose @ 2020-07-22 10:39 UTC (permalink / raw)
  To: linux-acpi, linux-pci, linux-kernel, rjw, helgaas, bp,
	james.morse, lenb, tony.luck, dan.carpenter, zhangliguang,
	andriy.shevchenko, wangkefeng.wang, jroedel
  Cc: linuxarm, yangyicong, jonathan.cameron, tanxiaofei

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).

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.

Co-developed-by: James Morse <james.morse@arm.com>
Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
---
 drivers/acpi/apei/ghes.c | 63 ++++++++++++++++++++++++++++++++++++++++
 include/acpi/ghes.h      | 27 +++++++++++++++++
 2 files changed, 90 insertions(+)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 81bf71b10d44..99df00f64306 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -79,6 +79,12 @@
 	((struct acpi_hest_generic_status *)				\
 	 ((struct ghes_estatus_node *)(estatus_node) + 1))
 
+#define GHES_VENDOR_ENTRY_LEN(gdata_len)                               \
+	(sizeof(struct ghes_vendor_record_entry) + (gdata_len))
+#define GHES_GDATA_FROM_VENDOR_ENTRY(vendor_entry)                     \
+	((struct acpi_hest_generic_data *)                              \
+	((struct ghes_vendor_record_entry *)(vendor_entry) + 1))
+
 /*
  *  NMI-like notifications vary by architecture, before the compiler can prune
  *  unused static functions it needs a value for these enums.
@@ -123,6 +129,12 @@ static DEFINE_MUTEX(ghes_list_mutex);
  */
 static DEFINE_SPINLOCK(ghes_notify_lock_irq);
 
+struct ghes_vendor_record_entry {
+	struct work_struct work;
+	int error_severity;
+	char vendor_record[];
+};
+
 static struct gen_pool *ghes_estatus_pool;
 static unsigned long ghes_estatus_pool_size_request;
 
@@ -511,6 +523,56 @@ static void ghes_handle_aer(struct acpi_hest_generic_data *gdata)
 #endif
 }
 
+static BLOCKING_NOTIFIER_HEAD(vendor_record_notify_list);
+
+int ghes_register_vendor_record_notifier(struct notifier_block *nb)
+{
+	return blocking_notifier_chain_register(&vendor_record_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(ghes_register_vendor_record_notifier);
+
+void ghes_unregister_vendor_record_notifier(struct notifier_block *nb)
+{
+	blocking_notifier_chain_unregister(&vendor_record_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(ghes_unregister_vendor_record_notifier);
+
+static void ghes_vendor_record_work_func(struct work_struct *work)
+{
+	struct ghes_vendor_record_entry *entry;
+	struct acpi_hest_generic_data *gdata;
+	u32 len;
+
+	entry = container_of(work, struct ghes_vendor_record_entry, work);
+	gdata = GHES_GDATA_FROM_VENDOR_ENTRY(entry);
+
+	blocking_notifier_call_chain(&vendor_record_notify_list,
+				     entry->error_severity, gdata);
+
+	len = GHES_VENDOR_ENTRY_LEN(acpi_hest_get_record_size(gdata));
+	gen_pool_free(ghes_estatus_pool, (unsigned long)entry, len);
+}
+
+static void ghes_defer_non_standard_event(struct acpi_hest_generic_data *gdata,
+					  int sev)
+{
+	struct acpi_hest_generic_data *copied_gdata;
+	struct ghes_vendor_record_entry *entry;
+	u32 len;
+
+	len = GHES_VENDOR_ENTRY_LEN(acpi_hest_get_record_size(gdata));
+	entry = (void *)gen_pool_alloc(ghes_estatus_pool, len);
+	if (!entry)
+		return;
+
+	copied_gdata = GHES_GDATA_FROM_VENDOR_ENTRY(entry);
+	memcpy(copied_gdata, gdata, acpi_hest_get_record_size(gdata));
+	entry->error_severity = sev;
+
+	INIT_WORK(&entry->work, ghes_vendor_record_work_func);
+	schedule_work(&entry->work);
+}
+
 static bool ghes_do_proc(struct ghes *ghes,
 			 const struct acpi_hest_generic_status *estatus)
 {
@@ -549,6 +611,7 @@ static bool ghes_do_proc(struct ghes *ghes,
 		} else {
 			void *err = acpi_hest_get_payload(gdata);
 
+			ghes_defer_non_standard_event(gdata, sev);
 			log_non_standard_event(sec_type, fru_id, fru_text,
 					       sec_sev, err,
 					       gdata->error_data_length);
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 517a5231cc1b..491bd8c6d600 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -53,6 +53,33 @@ enum {
 	GHES_SEV_PANIC = 0x3,
 };
 
+#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)
+{
+}
+#endif
+
 int ghes_estatus_pool_init(int num_ghes);
 
 /* From drivers/edac/ghes_edac.c */
-- 
2.17.1



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records
  2020-07-22 10:39 ` [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records Shiju Jose
@ 2020-07-22 11:01   ` Andy Shevchenko
  2020-07-22 12:34     ` Shiju Jose
  2020-07-23 23:20   ` Bjorn Helgaas
  1 sibling, 1 reply; 11+ messages in thread
From: Andy Shevchenko @ 2020-07-22 11:01 UTC (permalink / raw)
  To: Shiju Jose
  Cc: linux-acpi, linux-pci, linux-kernel, rjw, helgaas, bp,
	james.morse, lenb, tony.luck, dan.carpenter, zhangliguang,
	wangkefeng.wang, jroedel, linuxarm, yangyicong, jonathan.cameron,
	tanxiaofei

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).
> 
> 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.
> 
> Co-developed-by: James Morse <james.morse@arm.com>

Co-developed-by: is going _in conjunction with_ SoB tag which is missing here.

> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records
  2020-07-22 11:01   ` Andy Shevchenko
@ 2020-07-22 12:34     ` Shiju Jose
  2020-07-22 12:50       ` Andy Shevchenko
  0 siblings, 1 reply; 11+ messages in thread
From: Shiju Jose @ 2020-07-22 12:34 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: linux-acpi, linux-pci, linux-kernel, rjw, helgaas, bp,
	james.morse, lenb, tony.luck, dan.carpenter, zhangliguang,
	Wangkefeng (OS Kernel Lab),
	jroedel, Linuxarm, yangyicong, Jonathan Cameron, tanxiaofei

Hi Andy,

>-----Original Message-----
>From: Andy Shevchenko [mailto:andriy.shevchenko@linux.intel.com]
>Sent: 22 July 2020 12:02
>To: Shiju Jose <shiju.jose@huawei.com>
>Cc: linux-acpi@vger.kernel.org; linux-pci@vger.kernel.org; linux-
>kernel@vger.kernel.org; rjw@rjwysocki.net; helgaas@kernel.org;
>bp@alien8.de; james.morse@arm.com; lenb@kernel.org;
>tony.luck@intel.com; dan.carpenter@oracle.com;
>zhangliguang@linux.alibaba.com; Wangkefeng (OS Kernel Lab)
><wangkefeng.wang@huawei.com>; jroedel@suse.de; Linuxarm
><linuxarm@huawei.com>; yangyicong <yangyicong@huawei.com>; Jonathan
>Cameron <jonathan.cameron@huawei.com>; tanxiaofei
><tanxiaofei@huawei.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).
>>
>> 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.
>>
>> Co-developed-by: James Morse <james.morse@arm.com>
>
>Co-developed-by: is going _in conjunction with_ SoB tag which is missing
>here.
This tag was added as per instruction from Rafael.
I was told that I cannot add SoB tag for others unless specifically given.
Probably I will leave it with Rafael/James to help on this SoB tag
as Rafael was ok to merge this patch.
>
>> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
>
>--
>With Best Regards,
>Andy Shevchenko
>
Thanks,
Shiju



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records
  2020-07-22 12:34     ` Shiju Jose
@ 2020-07-22 12:50       ` Andy Shevchenko
  2020-07-31 13:47         ` James Morse
  0 siblings, 1 reply; 11+ messages in thread
From: Andy Shevchenko @ 2020-07-22 12:50 UTC (permalink / raw)
  To: Shiju Jose
  Cc: linux-acpi, linux-pci, linux-kernel, rjw, helgaas, bp,
	james.morse, lenb, tony.luck, dan.carpenter, zhangliguang,
	Wangkefeng (OS Kernel Lab),
	jroedel, Linuxarm, yangyicong, Jonathan Cameron, tanxiaofei

On Wed, Jul 22, 2020 at 12:34:23PM +0000, Shiju Jose wrote:
> >-----Original Message-----
> >From: Andy Shevchenko [mailto:andriy.shevchenko@linux.intel.com]
> >Sent: 22 July 2020 12:02
> >To: Shiju Jose <shiju.jose@huawei.com>
> >Cc: linux-acpi@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> >kernel@vger.kernel.org; rjw@rjwysocki.net; helgaas@kernel.org;
> >bp@alien8.de; james.morse@arm.com; lenb@kernel.org;
> >tony.luck@intel.com; dan.carpenter@oracle.com;
> >zhangliguang@linux.alibaba.com; Wangkefeng (OS Kernel Lab)
> ><wangkefeng.wang@huawei.com>; jroedel@suse.de; Linuxarm
> ><linuxarm@huawei.com>; yangyicong <yangyicong@huawei.com>; Jonathan
> >Cameron <jonathan.cameron@huawei.com>; tanxiaofei
> ><tanxiaofei@huawei.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).
> >>
> >> 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.
> >>
> >> Co-developed-by: James Morse <james.morse@arm.com>
> >
> >Co-developed-by: is going _in conjunction with_ SoB tag which is missing
> >here.
> This tag was added as per instruction from Rafael.
> I was told that I cannot add SoB tag for others unless specifically given.
> Probably I will leave it with Rafael/James to help on this SoB tag
> as Rafael was ok to merge this patch.

I think it's a misunderstanding somewhere. According to [1]:
"Since Co-developed-by: denotes authorship, every Co-developed-by: must be
immediately followed by a Signed-off-by: of the associated co-author."

It means either both or none.

[1]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records
  2020-07-22 10:39 ` [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records Shiju Jose
  2020-07-22 11:01   ` Andy Shevchenko
@ 2020-07-23 23:20   ` Bjorn Helgaas
  2020-07-24  9:00     ` Shiju Jose
  1 sibling, 1 reply; 11+ messages in thread
From: Bjorn Helgaas @ 2020-07-23 23:20 UTC (permalink / raw)
  To: Shiju Jose
  Cc: linux-acpi, linux-pci, linux-kernel, rjw, bp, james.morse, lenb,
	tony.luck, dan.carpenter, zhangliguang, andriy.shevchenko,
	wangkefeng.wang, jroedel, linuxarm, yangyicong, jonathan.cameron,
	tanxiaofei

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.

> +#endif
> +
>  int ghes_estatus_pool_init(int num_ghes);
>  
>  /* From drivers/edac/ghes_edac.c */
> -- 
> 2.17.1
> 
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records
  2020-07-23 23:20   ` Bjorn Helgaas
@ 2020-07-24  9:00     ` Shiju Jose
  2020-07-24 12:53       ` Bjorn Helgaas
  0 siblings, 1 reply; 11+ messages in thread
From: Shiju Jose @ 2020-07-24  9:00 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: linux-acpi, linux-pci, linux-kernel, rjw, bp, james.morse, lenb,
	tony.luck, dan.carpenter, zhangliguang, andriy.shevchenko,
	Wangkefeng (OS Kernel Lab),
	jroedel, Linuxarm, yangyicong, Jonathan Cameron, tanxiaofei

Hi Bjorn,

Thanks for reviewing.

>-----Original Message-----
>From: Bjorn Helgaas [mailto:helgaas@kernel.org]
>Sent: 24 July 2020 00:21
>To: Shiju Jose <shiju.jose@huawei.com>
>Cc: linux-acpi@vger.kernel.org; linux-pci@vger.kernel.org; linux-
>kernel@vger.kernel.org; rjw@rjwysocki.net; bp@alien8.de;
>james.morse@arm.com; lenb@kernel.org; tony.luck@intel.com;
>dan.carpenter@oracle.com; zhangliguang@linux.alibaba.com;
>andriy.shevchenko@linux.intel.com; Wangkefeng (OS Kernel Lab)
><wangkefeng.wang@huawei.com>; jroedel@suse.de; Linuxarm
><linuxarm@huawei.com>; yangyicong <yangyicong@huawei.com>; Jonathan
>Cameron <jonathan.cameron@huawei.com>; tanxiaofei
><tanxiaofei@huawei.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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records
  2020-07-24  9:00     ` Shiju Jose
@ 2020-07-24 12:53       ` Bjorn Helgaas
  2020-07-24 13:32         ` Shiju Jose
  0 siblings, 1 reply; 11+ messages in thread
From: Bjorn Helgaas @ 2020-07-24 12:53 UTC (permalink / raw)
  To: Shiju Jose
  Cc: linux-acpi, linux-pci, linux-kernel, rjw, bp, james.morse, lenb,
	tony.luck, dan.carpenter, zhangliguang, andriy.shevchenko,
	Wangkefeng (OS Kernel Lab),
	jroedel, Linuxarm, yangyicong, Jonathan Cameron, tanxiaofei

On Fri, Jul 24, 2020 at 09:00:41AM +0000, Shiju Jose wrote:
> >-----Original Message-----
> >From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> >Sent: 24 July 2020 00:21
> >To: Shiju Jose <shiju.jose@huawei.com>
> >Cc: linux-acpi@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> >kernel@vger.kernel.org; rjw@rjwysocki.net; bp@alien8.de;
> >james.morse@arm.com; lenb@kernel.org; tony.luck@intel.com;
> >dan.carpenter@oracle.com; zhangliguang@linux.alibaba.com;
> >andriy.shevchenko@linux.intel.com; Wangkefeng (OS Kernel Lab)
> ><wangkefeng.wang@huawei.com>; jroedel@suse.de; Linuxarm
> ><linuxarm@huawei.com>; yangyicong <yangyicong@huawei.com>; Jonathan
> >Cameron <jonathan.cameron@huawei.com>; tanxiaofei
> ><tanxiaofei@huawei.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.  

The usual route is to add stubs when they're needed, not just in
anticipation of some need that may never materialize.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records
  2020-07-24 12:53       ` Bjorn Helgaas
@ 2020-07-24 13:32         ` Shiju Jose
  0 siblings, 0 replies; 11+ messages in thread
From: Shiju Jose @ 2020-07-24 13:32 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: linux-acpi, linux-pci, linux-kernel, rjw, bp, james.morse, lenb,
	tony.luck, dan.carpenter, zhangliguang, andriy.shevchenko,
	Wangkefeng (OS Kernel Lab),
	jroedel, Linuxarm, yangyicong, Jonathan Cameron, tanxiaofei

>-----Original Message-----
>From: Bjorn Helgaas [mailto:helgaas@kernel.org]
>Sent: 24 July 2020 13:54
>To: Shiju Jose <shiju.jose@huawei.com>
>Cc: linux-acpi@vger.kernel.org; linux-pci@vger.kernel.org; linux-
>kernel@vger.kernel.org; rjw@rjwysocki.net; bp@alien8.de;
>james.morse@arm.com; lenb@kernel.org; tony.luck@intel.com;
>dan.carpenter@oracle.com; zhangliguang@linux.alibaba.com;
>andriy.shevchenko@linux.intel.com; Wangkefeng (OS Kernel Lab)
><wangkefeng.wang@huawei.com>; jroedel@suse.de; Linuxarm
><linuxarm@huawei.com>; yangyicong <yangyicong@huawei.com>; Jonathan
>Cameron <jonathan.cameron@huawei.com>; tanxiaofei
><tanxiaofei@huawei.com>
>Subject: Re: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown
>(vendor) CPER records
>
>On Fri, Jul 24, 2020 at 09:00:41AM +0000, Shiju Jose wrote:
>> >-----Original Message-----
>> >From: Bjorn Helgaas [mailto:helgaas@kernel.org]
>> >Sent: 24 July 2020 00:21
>> >To: Shiju Jose <shiju.jose@huawei.com>
>> >Cc: linux-acpi@vger.kernel.org; linux-pci@vger.kernel.org; linux-
>> >kernel@vger.kernel.org; rjw@rjwysocki.net; bp@alien8.de;
>> >james.morse@arm.com; lenb@kernel.org; tony.luck@intel.com;
>> >dan.carpenter@oracle.com; zhangliguang@linux.alibaba.com;
>> >andriy.shevchenko@linux.intel.com; Wangkefeng (OS Kernel Lab)
>> ><wangkefeng.wang@huawei.com>; jroedel@suse.de; Linuxarm
>> ><linuxarm@huawei.com>; yangyicong <yangyicong@huawei.com>;
>Jonathan
>> >Cameron <jonathan.cameron@huawei.com>; tanxiaofei
>> ><tanxiaofei@huawei.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.
>
>The usual route is to add stubs when they're needed, not just in anticipation
>of some need that may never materialize.
ok. I will change in the next version.

Thanks,
Shiju

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records
  2020-07-22 12:50       ` Andy Shevchenko
@ 2020-07-31 13:47         ` James Morse
  2020-07-31 14:07           ` Shiju Jose
  0 siblings, 1 reply; 11+ messages in thread
From: James Morse @ 2020-07-31 13:47 UTC (permalink / raw)
  To: Shiju Jose
  Cc: Andy Shevchenko, linux-acpi, linux-pci, linux-kernel, rjw,
	helgaas, bp, lenb, tony.luck, dan.carpenter, zhangliguang,
	Wangkefeng (OS Kernel Lab),
	jroedel, Linuxarm, yangyicong, Jonathan Cameron, tanxiaofei

Hi Shiju,

On 22/07/2020 13:50, Andy Shevchenko wrote:
> On Wed, Jul 22, 2020 at 12:34:23PM +0000, Shiju Jose wrote:

>>>> Co-developed-by: James Morse <james.morse@arm.com>
>>>
>>> Co-developed-by: is going _in conjunction with_ SoB tag which is missing
>>> here.
>> This tag was added as per instruction from Rafael.
>> I was told that I cannot add SoB tag for others unless specifically given.
>> Probably I will leave it with Rafael/James to help on this SoB tag
>> as Rafael was ok to merge this patch.
> 
> I think it's a misunderstanding somewhere. According to [1]:
> "Since Co-developed-by: denotes authorship, every Co-developed-by: must be
> immediately followed by a Signed-off-by: of the associated co-author."
> 
> It means either both or none.
> 
> [1]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html

Sorry for this mess! My intention was to summarise my suggestion in the form of a patch,
I wasn't expecting you to pick it up. (and I didn't post it because there was ongoing
discussion on the second part)

I'll repost this with the Co-Developed-by stuff. You'll need to re-post it with the
series, you'll need to move your Signed-Off-By to be last when you do that.


Thanks,

James

^ permalink raw reply	[flat|nested] 11+ messages in thread

* RE: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records
  2020-07-31 13:47         ` James Morse
@ 2020-07-31 14:07           ` Shiju Jose
  0 siblings, 0 replies; 11+ messages in thread
From: Shiju Jose @ 2020-07-31 14:07 UTC (permalink / raw)
  To: James Morse
  Cc: Andy Shevchenko, linux-acpi, linux-pci, linux-kernel, rjw,
	helgaas, bp, lenb, tony.luck, dan.carpenter, zhangliguang,
	Wangkefeng (OS Kernel Lab),
	jroedel, Linuxarm, yangyicong, Jonathan Cameron, tanxiaofei

Hi James, 

>-----Original Message-----
>From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>owner@vger.kernel.org] On Behalf Of James Morse
>Sent: 31 July 2020 14:48
>To: Shiju Jose <shiju.jose@huawei.com>
>Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>; linux-
>acpi@vger.kernel.org; linux-pci@vger.kernel.org; linux-
>kernel@vger.kernel.org; rjw@rjwysocki.net; helgaas@kernel.org;
>bp@alien8.de; lenb@kernel.org; tony.luck@intel.com;
>dan.carpenter@oracle.com; zhangliguang@linux.alibaba.com; Wangkefeng
>(OS Kernel Lab) <wangkefeng.wang@huawei.com>; jroedel@suse.de;
>Linuxarm <linuxarm@huawei.com>; yangyicong <yangyicong@huawei.com>;
>Jonathan Cameron <jonathan.cameron@huawei.com>; tanxiaofei
><tanxiaofei@huawei.com>
>Subject: Re: [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown
>(vendor) CPER records
>
>Hi Shiju,
>
>On 22/07/2020 13:50, Andy Shevchenko wrote:
>> On Wed, Jul 22, 2020 at 12:34:23PM +0000, Shiju Jose wrote:
>
>>>>> Co-developed-by: James Morse <james.morse@arm.com>
>>>>
>>>> Co-developed-by: is going _in conjunction with_ SoB tag which is
>>>> missing here.
>>> This tag was added as per instruction from Rafael.
>>> I was told that I cannot add SoB tag for others unless specifically given.
>>> Probably I will leave it with Rafael/James to help on this SoB tag as
>>> Rafael was ok to merge this patch.
>>
>> I think it's a misunderstanding somewhere. According to [1]:
>> "Since Co-developed-by: denotes authorship, every Co-developed-by:
>> must be immediately followed by a Signed-off-by: of the associated co-
>author."
>>
>> It means either both or none.
>>
>> [1]:
>> https://www.kernel.org/doc/html/latest/process/submitting-patches.html
>
>Sorry for this mess! My intention was to summarise my suggestion in the
>form of a patch, I wasn't expecting you to pick it up. (and I didn't post it
>because there was ongoing discussion on the second part)
>
>I'll repost this with the Co-Developed-by stuff. You'll need to re-post it with
>the series, you'll need to move your Signed-Off-By to be last when you do
>that.

Sure. Thanks.
Also please consider make you as the author of this patch 
because it has more changes from you.

>
>
>Thanks,
>
>James

Thanks,
Shiju

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, back to index

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-22 10:39 [PATCH v13 0/2] ACPI / APEI: Add support to notify the vendor specific HW errors Shiju Jose
2020-07-22 10:39 ` [PATCH v13 1/2] ACPI / APEI: Add a notifier chain for unknown (vendor) CPER records Shiju Jose
2020-07-22 11:01   ` Andy Shevchenko
2020-07-22 12:34     ` Shiju Jose
2020-07-22 12:50       ` Andy Shevchenko
2020-07-31 13:47         ` James Morse
2020-07-31 14:07           ` Shiju Jose
2020-07-23 23:20   ` Bjorn Helgaas
2020-07-24  9:00     ` Shiju Jose
2020-07-24 12:53       ` Bjorn Helgaas
2020-07-24 13:32         ` Shiju Jose

Linux-PCI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-pci/0 linux-pci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pci linux-pci/ https://lore.kernel.org/linux-pci \
		linux-pci@vger.kernel.org
	public-inbox-index linux-pci

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pci


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git