On 22 March 2017 at 19:49, Sinan Kaya [off-list ref] wrote:

On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:

quoted

quoted

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.

quoted

quoted

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?

quoted

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.