On 3/30/2017 9:38 AM, Ard Biesheuvel wrote: > On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: >> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> wrote: >>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote: >>> >>> [...] >>> >>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead >>>>> of working around it by quirks. >>>>> >>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems. >>>>> >>>>> Legacy only applies to DT based systems. >>>>> >>>> >>>> I fully agree with this point: ACPI implies firmware, and so we should >>>> be able to rely on firmware to have initialized the PCIe subsystem by >>>> the time the kernel gets to access it. >>> >>> https://lkml.org/lkml/2016/3/3/458 >>> >> >> I don't think the fact that at least one system existed over a year >> ago whose UEFI assigned resources incorrectly should prevent us from >> being normative in this case. > > In any case, given that EFIFB is enabled by default on some distros, > and the fact that DT boot is affected as well, I should get this patch > in to prevent serious potential issues that could arise when someone > with a graphical UEFI stack updates to such a new kernel. > > So I think we are in agreement that this is needed on both ARM and > arm64, since their PCI configuration is usually not preserved. The > open question is whether there is any harm in enabling it for x86 as > well. > Agreed, the other issue is about compatibility with UEFI and future proofing Linux for other potential issues like hotplug reservation. -- 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
