On 01/15/2015 02:46 PM, Arnd Bergmann wrote:
On Wednesday 14 January 2015 18:16:19 al.stone@linaro.org wrote:
From: Al Stone ahs3@redhat.com
ACPI_OS_NAME is globally defined as "Microsoft Windows NT" for now. That doesn't make much sense in the ARM context, so set it to "Linux" when CONFIG_ARM64.
So do we expect Microsoft to identify WindowsRT as "Linux" on these machines?
Nope. _OS (and \OSI and others) are supplied by the operating system; they are predefined methods within the spec. When an ACPI method invokes one of these predefined methods, the ACPICA code calls some OS-specific routine. So, in this case, this change is only in Linux code, not the firmware, and Windows can provide whatever implementation they want returning whatever string they would like.
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 3e3bd35..024c5f0 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -369,6 +369,14 @@ config ACPI_REDUCED_HARDWARE_ONLY If you are unsure what to do, do not enable this option. +config ACPI_OS_NAME_LINUX
bool "Using Linux for _OS method" if EXPERTdef_bool nWhen used, this option makes sure the _OS method returnsthe value "Linux".If you are unsure what to do, do not enable this option.source "drivers/acpi/apei/Kconfig" config ACPI_EXTLOG
With this Kconfig statement, expert users on x86 can choose between the two strings, but while expert users on arm64 will see an option they cannot disable, and non-expert users cannot change the default.
Is that what you intended?
Yes. X86 will need to have both options available for backwards compatibility. And if you're not an expert user, you really should not be messing with this string; I don't know that it would be harmful, but I don't know that it would not be harmful, either.
On arm64, we want there to only be one option. Expert is the only way ACPI has been allowed, in discussions so far.
I would see more value in a boot-time option than a compile-time option: If you have a broken BIOS that depends on a particular string, you shouldn't have to rebuild the kernel.
Hrm. I agree. I'll modify the patch accordingly.