From: james.morse@arm.com (James Morse)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH V1 v4.10-rc3 1/1] acpi: apei: handle GSIV notification type
Date: Tue, 28 Feb 2017 13:22:41 +0000 [thread overview]
Message-ID: <58B579A1.90109@arm.com> (raw)
In-Reply-To: <86258A5CC0A3704780874CF6004BA8A62DCAB57E@lhreml502-mbs>
Hi Shiju,
On 27/02/17 18:19, Shiju Jose wrote:
> Add a new GHES error source handling function for
> GSIV(Global System Interrupt Vector).
> If an error source's notification type is GSIV,
> then this handling function can be registered
> into the GSIV handler and it can parse
> and report error information when they occur.
I'm missing some of the story here, but how is GSIV different from 'External
Interrupt'? I'm guessing something other than the CPU takes this 'interrupt'...
The GHES GSIV code below is identical to the behaviour of the SCI Notification
type... are these two names for the same thing? (I'm confused!)
Thanks,
James
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index e53bef6..e1611d2 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -721,6 +721,58 @@ static struct notifier_block ghes_notifier_sci = {
> .notifier_call = ghes_notify_sci,
> };
>
> +#ifdef CONFIG_HAVE_ACPI_APEI_GSIV
> +static LIST_HEAD(ghes_gsiv);
> +
> +static int ghes_notify_gsiv(struct notifier_block *this,
> + unsigned long event, void *data)
> +{
> + struct ghes *ghes;
> + int ret = NOTIFY_DONE;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(ghes, &ghes_gsiv, list) {
> + if (!ghes_proc(ghes))
> + ret = NOTIFY_OK;
> + }
> + rcu_read_unlock();
> + return ret;
> +}
> +static struct notifier_block ghes_notifier_gsiv = {
> + .notifier_call = ghes_notify_gsiv,
> +};
> +
> +static void ghes_gsiv_add(struct ghes *ghes)
> +{
> + mutex_lock(&ghes_list_mutex);
> + if (list_empty(&ghes_gsiv))
> + register_acpi_hed_notifier(&ghes_notifier_gsiv);
> + list_add_rcu(&ghes->list, &ghes_gsiv);
> + mutex_unlock(&ghes_list_mutex);
> +}
> +
> +static void ghes_gsiv_remove(struct ghes *ghes)
> +{
> + mutex_lock(&ghes_list_mutex);
> + list_del_rcu(&ghes->list);
> + if (list_empty(&ghes_gsiv))
> + unregister_acpi_hed_notifier(&ghes_notifier_gsiv);
> + mutex_unlock(&ghes_list_mutex);
> +}
> +#else /* CONFIG_HAVE_ACPI_APEI_GSIV */
> +static inline void ghes_gsiv_add(struct ghes *ghes)
> +{
> + pr_err(GHES_PFX "ID: %d, trying to add GSIV notification which is not supported\n",
> + ghes->generic->header.source_id);
> +}
> +
> +static inline void ghes_gsiv_remove(struct ghes *ghes)
> +{
> + pr_err(GHES_PFX "ID: %d, trying to remove GSIV notification which is not supported\n",
> + ghes->generic->header.source_id);
> +}
> +#endif /* CONFIG_HAVE_ACPI_APEI_GSIV */
> +
> #ifdef CONFIG_HAVE_ACPI_APEI_NMI
> /*
> * printk is not safe in NMI context. So in NMI handler, we allocate
> @@ -973,6 +1025,14 @@ static int ghes_probe(struct platform_device *ghes_dev)
> goto err;
> }
> break;
> + case ACPI_HEST_NOTIFY_GSIV:
> + if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_GSIV)) {
> + pr_warn(GHES_PFX "Generic hardware error source: %d notified via notification GSIV is not supported\n",
> + generic->header.source_id);
> + rc = -ENOTSUPP;
> + goto err;
> + }
> + break;
> case ACPI_HEST_NOTIFY_LOCAL:
> pr_warning(GHES_PFX "Generic hardware error source: %d notified via local interrupt is not supported!\n",
> generic->header.source_id);
> @@ -1034,6 +1094,9 @@ static int ghes_probe(struct platform_device *ghes_dev)
> case ACPI_HEST_NOTIFY_NMI:
> ghes_nmi_add(ghes);
> break;
> + case ACPI_HEST_NOTIFY_GSIV:
> + ghes_gsiv_add(ghes);
> + break;
> default:
> BUG();
> }
> @@ -1076,6 +1139,9 @@ static int ghes_remove(struct platform_device *ghes_dev)
> case ACPI_HEST_NOTIFY_NMI:
> ghes_nmi_remove(ghes);
> break;
> + case ACPI_HEST_NOTIFY_GSIV:
> + ghes_gsiv_remove(ghes);
> + break;
> default:
> BUG();
> break;
>
next prev parent reply other threads:[~2017-02-28 13:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-27 18:19 [RFC PATCH V1 v4.10-rc3 1/1] acpi: apei: handle GSIV notification type Shiju Jose
2017-02-27 18:58 ` Paul Gortmaker
2017-02-27 20:39 ` Steven Rostedt
2017-02-28 13:22 ` James Morse [this message]
2017-03-01 8:27 ` Hanjun Guo
2017-03-01 17:04 ` James Morse
2017-03-02 13:45 ` Shiju Jose
2017-03-03 4:20 ` Hanjun Guo
2017-03-03 12:48 ` Shiju Jose
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=58B579A1.90109@arm.com \
--to=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).