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

[Hanjun Guo]

On 2017/3/2 21:45, Shiju Jose wrote:
> Hi James,
>
>>
>> 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.
>
> 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.

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

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

Thanks
Hanjun