On 4/10/2017 12:53 PM, Lorenzo Pieralisi wrote: > Do we want to enforce it on ARM ? I do not know to be honest (and it > still would not solve the DT firmware case). > Yes for ACPI on ARM. Probably no for DT. > Whatever we do, it is not going to be clean cut IMO. I think that > what x86 does is sensible (well, minus the link ordering dependency we > discovered), I can do it for ARM64 but get ready for regressions and > I still think we have no real FW binding support that would make this > behaviour robust. Is it possible to move the code from arch/x86 into drivers/acpi directory so that the code is shared across multiple ACPI based archs. We get more coverage this way. Can we fallback to the allocate everything behavior if we can't use the stuff from FW or would it be too late to recover? We can prevent regressions this way and issue a lot of warnings. We can sit down and fix those warnings over time whether the issue is in UEFI BIOS or the code itself. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
