[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 30 March 2017 at 14:50, Sinan Kaya <okaya at codeaurora.org> wrote:
> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> 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.