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. Regards, Mauro -- 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
