On 2014?12?25? 01:18, Catalin Marinas wrote:
[...]

In addition to the above and _DSD requirements/banning, I would also add
some clear statements around:

_OSC: only global/published capabilities are allowed. For
device-specific _OSC we need a process or maybe we can ban them entirely
and rely on _DSD once we clarify the process.

_OSI: firmware must not check for certain _OSI strings. Here I'm not
sure what we would have to do for ARM Linux. Reporting "Windows" does
not make any sense but not reporting anything can, as Matthew Garrett
pointed out, can be interpreted by firmware as "Linux". In addition to
any statements in this document, I suggest you patch
drivers/acpi/acpica/utosi.c accordingly, maybe report "Linux" for ARM
and print a kernel warning so that we notice earlier.

ACPI_OS_NAME: this is globally defined as "Microsoft Windows NT". It
doesn't make much sense in the ARM context. Could we change it to
"Linux" when CONFIG_ARM64?

We will work on this both on ASWG and linux ACPI driver side, as Dong
and Charles pointed out, _OSI things can be solved in ACPI spec, when
that is done, we can modify the kernel driver to fix the problems above.

Compatibility with older kernels: ACPI firmware must work, even though
not fully optimal, with the earliest kernel version implementing the
targeted ACPI spec. There may be a need for new drivers but otherwise
adding things like CPU power management should not break older kernel
versions. In addition, the ACPI firmware must also work with the latest
kernel version.

It should be, and I think that's why we need ACPI (or DT) here :)

Thanks
Hanjun