On 01/14/2015 06:16 PM, al.stone@linaro.org wrote:
From: Al Stone ahs3@redhat.com
The use of the ACPI _OSI method in Linux has a long and sordid history. Instead of perpetuating the complications on new architectures, the consensus appears to be to deprecate the use of _OSI. I will be proposing such a change to the ACPI specification in the near future.
These patches rearrange the implementation of _OSI so that it can be deprecated on arm64 platforms. For x86, there should be no change in functionality. For ia64, there is no longer any connection to the ACPI blacklist code that is only used by x86. For arm64, any use of the _OSI method generates a warning that it has been deprecated, and then always returns false; i.e., that the capability being queried for, whether OS name or functionality, is not supported. This is the first four of the patches.
The final patch changes the _OS method for arm64 only. Since there is no need to pretend to be older versions of Windows, or any other OS, the _OS method will return "Linux" on arm64.
I have only done simple boot testing with these patches on arm64 and x86 (AMD Seattle and a Lenovo t440s ThinkPad, respectively). Things seem to work as they should, but this is a very small sample of possible machines. The ia64 patches compile, but I have no way to test them.
These patches also rely on having already applied Hanjun's patches for ACPI 5.1 on arm64 [0]. The x86 and ia64 parts are not dependent on that patch set, though, and could be used independently.
[0] https://lkml.org/lkml/2015/1/14/586
Al Stone (4): ia64: ACPI: move kernel acpi files to a directory arm64: ACPI: move kernel acpi files to a directory ACPI: arm64/x86/ia64: make acpi_osi_handler() arch-dependent ACPI: x86/ia64/arm64: move _OSI support functions to arch-dependent locations
Hanjun Guo (1): ACPI: use Linux as ACPI_OS_NAME for _OS on ARM64
A couple of things I forgot to mention, and will put in the next version of the cover letter:
-- This needs testing! I've tried a few things, but those were by no means exhaustive. I'm more concerned about non-ARM machines, in this case.
-- This only handles part of the problem from the TODO list. There are really several issues:
-- How does the OS identify itself to ACPI? Firmware should not change behavior on this basis, but you know someone will in the future. This is what the _OSI and _OS methods handle, and what this patch set fixes.
-- How do the OS and firmware negotiate the capabilities that can be used, and who has control over them? This is what _OSC is for. For global capabilities, there's well-defined processes for defining them, so that's a non-issue. For device-specific capabilities (other than PCI), _OSC has the same issues as _DSD -- there needs to be something more formal to handle changes and additions to the bindings. These patches do NOT deal with this part at all; that's TBD.