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

[Sinan Kaya]

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.

-- 
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.