[RFC PATCH V1 v4.10-rc3 1/1] acpi: apei: handle GSIV notification type

[James Morse]

Hi Hanjun,

On 01/03/17 08:27, Hanjun Guo wrote:
> On 2017/2/28 21:22, James Morse wrote:
>> 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'...
> 
> 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 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.

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.


> For example, if we are using SPI (ARM GIC) 100 to report errors, there
> is a ACPI0013 driver in drivers/acpi/evged.c to register the irq, when

Aha, this is where the interrupt-magic happens.


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


>> 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 used for HW-reduced platform which has no GPEs.

> 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? 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 thing we would lose is the name
'GSIV' in the not-supported error message which we don't need if its always
supported.


Thanks,

James