On 30 March 2017 at 14:50, Sinan Kaya <okaya@xxxxxxxxxxxxxx> wrote: > 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. > OK, given the lack of feedback regarding the suitability of this patch for x86, I am going to rework it as a ARM/arm64 only patch, and queue it as a fix for v4.11. This way, we can backport it to stable (which is arguably appropriate, given that upgrading to a EFIFB enabled kernel may cause severe breakage for existing systems that implement the GOP protocol), and easily change the patch to apply to x86 going forwards, by removing the #ifdefs -- Ard.
