Re: RFC: APEI hardware reduced profile

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/26/14 16:10, Mauro Carvalho Chehab wrote:
Em Wed, 26 Mar 2014 15:55:07 +0100
"Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx> escreveu:

On Wednesday, March 26, 2014 01:08:10 PM Tomasz Nowicki wrote:
Hi,

Hi,

This is a question for Tony, Boris and Mauro (CCed now).

Currently APEI depends on x86 architecture. It is because of many x86
specific features like "IA-32 Architecture Corrected Machine Check
" error source or NMI hardware error notification. However, many other
features like "PCI Express Device AER Structure" or GHES via external
interrupt can be still used perfectly by other architectures. So my idea
is to move x86 dependency away form Kconfig to APEI areas where it
really applies to.

I have started refactoring ghes.c driver in that direction. And here
comes my confusion, how should we treat x86 related parts, as fixed
profile? (which means we could use ACPI_REDUCED_HARDWARE or
CONFIG_ACPI_REDUCED_HARDWARE_ONLY define). I would like to ask for your
opinion.

That's a good question, and probably depends on how are you mapping the
ACPI changes. For example, are you moving acpi out of /arch?

As I answered to a similar questioning, IMHO, the better would be to
have the hardware error report mechanisms on /drivers/ras, and have
there some Kconfig items that would depend on X86 to enable certain
drivers.

Also, I don't like to have something like ACPI_REDUCED_foo. IMHO, the
better would be to do the reverse: to have Kconfig symbols enabling the
extra X86-specific functionality, and have them mapped into separate
files/drivers, with proper KConfig names, like ACPI_X86 or ACPI_X86_NMI.

Yet, it would be better if you could be a little more specific about
what are your plans and what are the common/not-common features that
you're mapping.

Yes and sorry, I should have been more specific here.

After scanning APEI code it seems like NMI notification of GHES implies APEI x86 dependency for Kconfig, so I am targeting ghes.c.

I agree that ACPI_REDUCED_foo is not suitable for that purpose. However, ACPI_X86_NMI sounds good to me. I also have been thinking of moving NMI code (from ghes.c) to separate file but NMI and IRQ context are tightly coupled. That convinced me to leave it in ghes.c for now but I need to look at it closer.

Thanks,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux