Hi Hanjun,

-----Original Message-----
From: Hanjun Guo [mailto:hanjun.guo at linaro.org]
Sent: 03 March 2017 04:20
To: Shiju Jose; James Morse
Cc: christoffer.dall at linaro.org; marc.zyngier at arm.com;
pbonzini at redhat.com; rkrcmar at redhat.com; linux at armlinux.org.uk;
catalin.marinas at arm.com; will.deacon at arm.com; rjw at rjwysocki.net;
lenb at kernel.org; matt at codeblueprint.co.uk; robert.moore at intel.com;
lv.zheng at intel.com; nkaje at codeaurora.org; zjzhang at codeaurora.org;
mark.rutland at arm.com; akpm at linux-foundation.org;
eun.taik.lee at samsung.com; sandeepa.s.prabhu at gmail.com;
labbott at redhat.com; shijie.huang at arm.com; rruigrok at codeaurora.org;
paul.gortmaker at windriver.com; tn at semihalf.com; fu.wei at linaro.org;
rostedt at goodmis.org; bristot at redhat.com; linux-arm-
kernel at lists.infradead.org; kvmarm at lists.cs.columbia.edu;
kvm at vger.kernel.org; linux-kernel at vger.kernel.org; linux-
acpi at vger.kernel.org; linux-efi at vger.kernel.org; devel at acpica.org;
Suzuki.Poulose at arm.com; punit.agrawal at arm.com; astone at redhat.com;
harba at codeaurora.org; Tyler Baicar; joe at perches.com; John Garry;
Gabriele Paoloni; Guohanjun (Hanjun Guo); wangxiongfeng (C); Zhengqiang
(turing)
Subject: Re: [RFC PATCH V1 v4.10-rc3 1/1] acpi: apei: handle GSIV
notification type

On 2017/3/2 21:45, Shiju Jose wrote:

quoted

Hi James,

quoted

Hi Hanjun,

On 01/03/17 08:27, Hanjun Guo wrote:

quoted

On 2017/2/28 21:22, James Morse wrote:

quoted

On 27/02/17 18:19, Shiju Jose wrote:

quoted

Add a new GHES error source handling function for GSIV(Global

System

quoted

quoted

quoted

Interrupt Vector).
If an error source's notification type is GSIV, then this

handling

quoted

quoted

quoted

quoted

quoted

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

quoted

Yes, it's the same from CPU side (they are interrupts!), but there
is history behind them and the usage is different.

I think External Interrupt was introduced before ACPI is available
on ARM (hardware reduced platforms), so I guess it was used for
errors reported to OS which were not using SCI mechanism, for
example, some IO error reporting.

For External Interrupt, we don't use the ACPI event system, so for

the

quoted

firmware, it just report the errors associate with the interrupt
number, the kernel map the interrupt number and install the irq
handler for it.

For GSIV based event, it was introduced for hardware reduced
platform in recent ACPI revision, and ARM64 is one of its consumers.
When errors are reported via GSIV, ACPI event notification needs to
be implemented and requires the platform to define a hardware error
device
(PNP0C33) in ACPI namespace, and also a generic event device

ACPI0013.

quoted

quoted

Okay, so for APEI this really means PNP0C33 was Notify()d. 'SCI'
means the same but the route they take to get into APEI is different.

quoted

For example, if we are using SPI (ARM GIC) 100 to report errors,

there

quoted

is a ACPI0013 driver in drivers/acpi/evged.c to register the irq,

when

Aha, this is where the interrupt-magic happens.

quoted

error happened and trigger the interrupt, ACPI0013 driver will
notify the error device (PNP0C33), then error device driver
(drivers/acpi/hed.c) will process the error data form APEI table...

quoted

quoted

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

SCI is also an 'interrupt' but it's a special irq number for ACPI
event, and it has GPE (general purpose event) registers behind it,
which is used only on Intel platforms. SCI based event use
Method(\_GPE._L0x) to notify the error device (PNP0C33), but GSIV

is

quoted

quoted

quoted

used for HW-reduced platform which has no GPEs.

quoted

Hope it can clarify something :)

Yes thanks! (the mist is slowly clearing...)

If ACPI_HEST_NOTIFY_SCI and ACPI_HEST_NOTIFY_GSIV both mean 'receive
notification from PNP0C33', is there any point having separate lists
and add/remove functions for them?

Instead, could we rename Linux's ghes_notifier_sci() and ghes_sci
list to describe 'hed' instead, then group the two case statements

together?

quoted

quoted

There would be no need to add a selectable CONFIG_ACPI_APEI_GSIV, as
SCI is already built-in and this way the code added is tiny. The

only

quoted

quoted

thing we would lose is the name 'GSIV' in the not-supported error
message which we don't need if its always supported.

This method was tested ok. However we were not sure about
reusing/changing the existing ghes_notifier_sci() for gsiv will be

accepted.

For now a notify (SCI/GSIV/GPIO) will trigger the process of all the
ghes data even they are on different list, so add them on a single list
and process them will have the same effect.

quoted

Thus added a separate handling function ghes_notifier_gsiv() for gsiv.

I think we can prepare the patch and send out for review.

Ok. I will do this.

Thanks
Hanjun