linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shiju Jose <shiju.jose@huawei.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	"helgaas@kernel.org" <helgaas@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"james.morse@arm.com" <james.morse@arm.com>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"zhangliguang@linux.alibaba.com" <zhangliguang@linux.alibaba.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	Linuxarm <linuxarm@huawei.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	tanxiaofei <tanxiaofei@huawei.com>,
	yangyicong <yangyicong@huawei.com>
Subject: RE: [PATCH v6 1/2] ACPI / APEI: Add support to notify the vendor specific HW errors
Date: Mon, 30 Mar 2020 15:44:29 +0000	[thread overview]
Message-ID: <613133075a174454a88312448b9b333c@huawei.com> (raw)
In-Reply-To: <20200330134249.GF16242@zn.tnic>

Hi Boris,

>-----Original Message-----
>From: Borislav Petkov [mailto:bp@alien8.de]
>Sent: 30 March 2020 14:43
>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;
>lenb@kernel.org; james.morse@arm.com; tony.luck@intel.com;
>gregkh@linuxfoundation.org; zhangliguang@linux.alibaba.com;
>tglx@linutronix.de; Linuxarm <linuxarm@huawei.com>; Jonathan Cameron
><jonathan.cameron@huawei.com>; tanxiaofei <tanxiaofei@huawei.com>;
>yangyicong <yangyicong@huawei.com>
>Subject: Re: [PATCH v6 1/2] ACPI / APEI: Add support to notify the vendor
>specific HW errors
>
>On Mon, Mar 30, 2020 at 11:55:35AM +0000, Shiju Jose wrote:
>> The idea was the error handled field will help the decoding part of
>> the rasdaemon to do the appropriate steps for logging the vendor error
>> information depending on whether a corresponding kernel driver has
>> handled the error or not.
>
>What's the difference for rasdaemon whether the error has been handled or
>not?
Following are some of the examples of the usage of error handled status
in the vendor specific code of the rasdaemon,
1. rasdaemon need not to print the vendor error data reported by the firmware if the 
    kernel driver already print those information. In this case rasdaemon will only need to store
    the decoded vendor error data to the SQL database.  
2. If the vendor kernel driver want to report extra error information through
    the vendor specific data (though presently we do not have any such use case) for the rasdamon to log. 
    I think the error handled status useful to indicate that the kernel driver has filled the extra information and
    rasdaemon to decode and log them after extra data specific validity check.
      
>
>--
>Regards/Gruss,
>    Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette

Thanks,
Shiju

  reply	other threads:[~2020-03-30 15:44 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Shiju Jose>
2019-08-12 10:11 ` [PATCH RFC 0/4] ACPI: APEI: Add support to notify the vendor specific HW errors Shiju Jose
2019-08-12 10:11   ` [PATCH RFC 1/4] " Shiju Jose
2019-08-21 17:23     ` James Morse
2019-08-22 16:57       ` Shiju Jose
2019-08-12 10:11   ` [PATCH RFC 2/4] ACPI: APEI: Add ghes_handle_memory_failure to the new notification method Shiju Jose
2019-08-21 17:22     ` James Morse
2019-08-22 16:57       ` Shiju Jose
2019-08-12 10:11   ` [PATCH RFC 3/4] ACPI: APEI: Add ghes_handle_aer " Shiju Jose
2019-08-12 10:11   ` [PATCH RFC 4/4] ACPI: APEI: Add log_arm_hw_error " Shiju Jose
2019-08-21 17:22   ` [PATCH RFC 0/4] ACPI: APEI: Add support to notify the vendor specific HW errors James Morse
2019-08-22 16:56     ` Shiju Jose
2019-10-03 17:21       ` James Morse
2020-01-15 11:01 ` [RFC PATCH 0/2] " Shiju Jose
2020-01-15 11:01   ` [RFC PATCH 1/2] " Shiju Jose
2020-01-15 11:01   ` [RFC PATCH 2/2] PCI:hip08:Add driver to handle HiSilicon hip08 PCIe controller's errors Shiju Jose
2020-01-15 14:13     ` Bjorn Helgaas
2020-01-17  9:40       ` Shiju Jose
2020-01-24 12:39 ` [PATCH v2 0/2] ACPI: APEI: Add support to notify the vendor specific HW errors Shiju Jose
2020-01-24 12:39   ` [PATCH v2 1/2] " Shiju Jose
2020-01-24 12:39   ` [PATCH v2 2/2] PCI: hip: Add handling of HiSilicon hip PCIe controller's errors Shiju Jose
2020-01-24 14:30     ` Bjorn Helgaas
2020-01-26 18:12     ` kbuild test robot
2020-01-26 18:12     ` [RFC PATCH] PCI: hip: hisi_pcie_sec_type can be static kbuild test robot
2020-02-03 16:51 ` [PATCH v3 0/2] ACPI: APEI: Add support to notify the vendor specific HW errors Shiju Jose
2020-02-03 16:51   ` [PATCH v3 1/2] " Shiju Jose
2020-02-03 16:51   ` [PATCH v3 2/2] PCI: HIP: Add handling of HiSilicon HIP PCIe controller's errors Shiju Jose
2020-02-04 14:31     ` Dan Carpenter
2020-02-07 10:31 ` [PATCH v4 0/2] ACPI: APEI: Add support to notify the vendor specific HW errors Shiju Jose
2020-02-07 10:31   ` [PATCH v4 1/2] " Shiju Jose
2020-03-11 17:29     ` James Morse
2020-03-12 12:10       ` Shiju Jose
2020-03-13 15:17         ` James Morse
2020-03-13 17:08           ` Shiju Jose
2020-02-07 10:31   ` [PATCH v4 2/2] PCI: HIP: Add handling of HiSilicon HIP PCIe controller errors Shiju Jose
2020-03-09  9:23   ` [PATCH v4 0/2] ACPI: APEI: Add support to notify the vendor specific HW errors Shiju Jose
2020-03-11 17:27     ` James Morse
2020-03-25 16:42 ` [PATCH v6 0/2] ACPI / " Shiju Jose
2020-03-25 16:42   ` [PATCH v6 1/2] " Shiju Jose
2020-03-27 18:22     ` Borislav Petkov
2020-03-30 10:14       ` Shiju Jose
2020-03-30 10:33         ` Borislav Petkov
2020-03-30 11:55           ` Shiju Jose
2020-03-30 13:42             ` Borislav Petkov
2020-03-30 15:44               ` Shiju Jose [this message]
2020-03-31  9:09                 ` Borislav Petkov
2020-04-08  9:20                   ` Shiju Jose
2020-04-08 10:03       ` James Morse
2020-04-21 13:18         ` Shiju Jose
2020-05-11 11:20         ` Shiju Jose
2020-03-25 16:42   ` [PATCH v6 2/2] PCI: hip: Add handling of HiSilicon HIP PCIe controller errors Shiju Jose
2020-03-27 15:07   ` [PATCH v6 0/2] ACPI / APEI: Add support to notify the vendor specific HW errors Bjorn Helgaas
2020-04-07 12:00 ` [v7 PATCH 0/6] ACPI / APEI: Add support to notify non-fatal " Shiju Jose
2020-04-07 12:00   ` [v7 PATCH 1/6] ACPI / APEI: Add support to queuing up the non-fatal HW errors and notify Shiju Jose
2020-04-08 19:41     ` kbuild test robot
2020-04-08 19:41     ` [RFC PATCH] ACPI / APEI: ghes_gdata_pool_init() can be static kbuild test robot
2020-04-07 12:00   ` [v7 PATCH 2/6] ACPI / APEI: Add callback for memory errors to the GHES notifier Shiju Jose
2020-04-07 12:00   ` [v7 PATCH 3/6] ACPI / APEI: Add callback for AER " Shiju Jose
2020-04-07 12:00   ` [v7 PATCH 4/6] ACPI / APEI: Add callback for ARM HW errors " Shiju Jose
2020-04-07 12:00   ` [v7 PATCH 5/6] ACPI / APEI: Add callback for non-standard " Shiju Jose
2020-04-07 12:00   ` [v7 PATCH 6/6] PCI: hip: Add handling of HiSilicon HIP PCIe controller errors Shiju Jose
2020-04-21 13:21 ` [RESEND PATCH v7 0/6] ACPI / APEI: Add support to notify non-fatal HW errors Shiju Jose
2020-04-21 13:21   ` [RESEND PATCH v7 1/6] ACPI / APEI: Add support to queuing up the non-fatal HW errors and notify Shiju Jose
2020-04-21 14:12     ` Dan Carpenter
2020-04-21 13:21   ` [RESEND PATCH v7 2/6] ACPI / APEI: Add callback for memory errors to the GHES notifier Shiju Jose
2020-04-21 13:21   ` [RESEND PATCH v7 3/6] ACPI / APEI: Add callback for AER " Shiju Jose
2020-04-21 13:21   ` [RESEND PATCH v7 4/6] ACPI / APEI: Add callback for ARM HW errors " Shiju Jose
2020-04-21 14:14     ` Dan Carpenter
2020-04-21 15:18       ` Shiju Jose
2020-04-21 13:21   ` [RESEND PATCH v7 5/6] ACPI / APEI: Add callback for non-standard " Shiju Jose
2020-04-21 13:21   ` [RESEND PATCH v7 6/6] PCI: hip: Add handling of HiSilicon HIP PCIe controller errors Shiju Jose
2020-04-21 14:20     ` Dan Carpenter

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=613133075a174454a88312448b9b333c@huawei.com \
    --to=shiju.jose@huawei.com \
    --cc=bp@alien8.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=helgaas@kernel.org \
    --cc=james.morse@arm.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=rjw@rjwysocki.net \
    --cc=tanxiaofei@huawei.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=yangyicong@huawei.com \
    --cc=zhangliguang@linux.alibaba.com \
    /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).