Re: RFC: APEI hardware reduced profile

[Mauro Carvalho Chehab <m.chehab@samsung.com>]

Em Wed, 26 Mar 2014 15:55:07 +0100
"Rafael J. Wysocki" <rjw@rjwysocki.net> 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.

Regards,
Mauro