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

[Ard Biesheuvel]

On 28 March 2017 at 22:49, Sinan Kaya <okaya at codeaurora.org> wrote:
> On 3/28/2017 5:39 PM, Ard Biesheuvel wrote:
>> On 28 March 2017 at 22:27, Sinan Kaya <okaya at codeaurora.org> wrote:
>>> Hi Lorenzo,
>>>
>>> On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>>>>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>>>> (or the legacy PCI bios) performed the resource assignment already.
>>>>> One could argue that this is equally the case when running arm64 in
>>>>> ACPI mode, but in general, you cannot assume the presence of firmware
>>>>> on ARM/arm64 that has already taken care of this, and so the state of
>>>>> the BARs has to be presumed invalid.
>>>> The story is a bit more convoluted than that owing to x86 (and other
>>>> arches) legacy.
>>>>
>>>> x86 tries to claim all PCI resources (in two passes - first enabled
>>>> devices, second disabled devices) and that predates ACPI/UEFI.
>>>>
>>>> Mind, x86 reassign resources that can't be claimed too, the only
>>>> difference with ARM64 is that, for the better or the worse, we
>>>> have decided not to claim the FW PCI set-up on ARM64 even if it
>>>> is sane, we do not even try, it was a deliberate choice.
>>>>
>>>> This patch should be harmless on x86 since if the FB PCI BAR is set
>>>> up sanely, claiming it again should be a nop (to be checked).
>>>>
>>>> For all the talk about PCI being arch agnostic as I said manifold
>>>> times before, that's just theory. In practice different arches
>>>> treat PCI FW set-up differently, it would be ideal to make them
>>>> uniform but legacy is huge and there is a massive risk of triggering
>>>> regressions, it is no mean feat (if achievable at all).
>>>
>>> Can we explore having a uniform behavior across ALL ACPI bases systems
>>> by trying to reuse the resources assigned by firmware first and reassign
>>> them only if something is wrong?
>>>
>>> There are protocols like hotplug reservation in UEFI. It looks like Linux
>>> is not honoring any of these protocols by being too smart.
>>>
>>
>> Could you be more specific? Which protocol do you mean exactly, and
>> how does not reusing resources interfere with it?
>>
>
> Let's assume for the moment that if ARM64 adaptation of PCIE reused the firmware
> assigned BAR addresses, would you still have this problem that you are trying to
> fix by a quirk?
>

Probably not. Although I should point out that the same issue exists
on DT systems, and so we will need this patch regardless.

> The protocol that I was looking at specifically is called hotplug reservation
> protocol.
>
> http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-hot-plug-pci-initialization-protocol-specification.html
>
> The idea is to pad the PCIe bridge window by some amount in UEFI. You boot the
> system without any cards present. when you do to hotplug, OS uses the range
> reserved by the BIOS for inserting the new card.
>
> what I see is that the bridge windows get overridden by the OS.
>
> 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.

> If there is still a legacy problem in ACPI ARM64, generic Linux code deals with
> this using some DMI/SMBIOS and setting a time bomb like products after this date
> shall follow the new behavior.
>
> We are not in a very hardened position when it comes to changes for ACPI based
> systems.
>
> Sinan
>
> --
> 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.