On 23/09/15 10:39, Arnd Bergmann wrote:
On Wednesday 23 September 2015 10:15:42 Sudeep Holla wrote:
On 15/09/15 09:34, Viresh Kumar wrote:
global_lock is defined as an unsigned long and accessing only its lower
32 bits from sysfs is incorrect, as we need to consider other 32 bits
for big endian 64 bit systems.
Fix that by making global_lock an u32 instead.
Cc: <stable@xxxxxxxxxxxxxxx> # v4.1+
Signed-off-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
---
Its marked just for # v4.1+, because arm64 has the first 64 big-endian
platform with ACPI. And ACPI support for that is mainlined recently
only (Arnd Bergmann).
Just to clarify, we don't support big-endian with ACPI on ARM64.
We mandate use of EFI for ACPI on ARM64 and EFI spec mandates only
little endian.
EFI doesn't care what endianess the kernel has, as long as the
data structures are interpreted in the same way that the firmware
defines them, and I thought that at least UEFI on ARM64 with big-endian
is working in principle (if not, that is a bug that should be fixed).
If ACPI is broken with big-endian kernels, we should probably add a
Kconfig statement to forbid it, like this:
The diff looks sensible thing to have to avoid enabling ACPI with BE
though I am not sure if this can be regarded as broken as it could be
case of just not supported(my guess as I am not completely aware of the
history).
Also I am not against the $subject patch as such, just added
clarification so that it shouldn't be assumed that BE + ACPI works on
ARM64.
Regards,
Sudeep
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 5d1015c26ff4..06cacc13e3d2 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -6,6 +6,7 @@ menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support"
depends on !IA64_HP_SIM
depends on IA64 || X86 || (ARM64 && EXPERT)
+ depends on !ARM64 || !CPU_BIG_ENDIAN || BROKEN
depends on PCI
select PNP
default y
Arnd
--
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
