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

[Ard Biesheuvel]

On 22 March 2017 at 19:49, Sinan Kaya <okaya at codeaurora.org> wrote:
> On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
>>> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
>>> they are correct. Kernel will reassign the resources only if something is wrong.
>>>
>> No, the kernel always reassigns all BARs on arm64.
>
> I think this is where the problem is.
>
> I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
> combination only.
>
> I see that kernel honored the resources assigned by UEFI BIOS if I compare
> the BAR addresses.
>

Well, if you are using the standard MdeModulePkg PciHostBridgeDxe
driver in UEFI, the logic is quite similar, and so you usually end up
with the same resource assignments. But the kernel does recompute them
from scratch, and ignores the existing configuration that is present
in the BARs

> I see reassignment only when something is horribly broken. Then, there would
> be a bridge configuration invalid message in the boot log to confirm this.
>
>>
>>> Will this code break other platforms/architectures?
>>>
>> Which platforms/architectures are you referring to? EFIFB on a PCI
>> device is currently broken on arm64.
>
> In general or on your particular platform?
>
>> On x86, it works, given that BARs
>> are usually not reassigned, and so the patch should be a no-op in that
>> case (although I'd argue it is still an improvement to check whether
>> the device that owns the BAR actually has memory decoding enabled
>> before we attach the framebuffer driver to it)
>>
>
> I'm fine as long as it doesn't break anything. That's why, I'm asking.
>

If you have working EFIFB on your platform, it works by accident. This
patch is needed to ensure that the BAR associated with the EFI
framebuffer is left untouched.