Revert "acpi/gpex: Inform os to keep firmware resource map"
commit40c3472a29c9a1fd65255fc196aa6feb99aaec9e
authorMichael S. Tsirkin <mst@redhat.com>
Tue, 27 Jul 2021 09:18:47 +0000 (27 05:18 -0400)
committerMichael S. Tsirkin <mst@redhat.com>
Tue, 3 Aug 2021 20:32:34 +0000 (3 16:32 -0400)
treeed97d161ca901b63e759ac539d29a0a1ecc32c73
parent5cd4a8d4e567a6d52553c2133bf1c9b008d80481
Revert "acpi/gpex: Inform os to keep firmware resource map"

This reverts commit 0cf8882fd06ba0aeb1e90fa6f23fce85504d7e14.

Which this commit, with aarch64 when using efi PCI devices with IO ports
do not work.  The reason is that EFI creates I/O port mappings below
0x1000 (in fact, at 0). However Linux, for legacy reasons, does not
support I/O ports <= 0x1000 on PCI, so the I/O assignment created by EFI
is rejected.

EFI creates the mappings primarily for itself, and up until DSM #5
started to be enforced, all PCI resource allocations that existed at
boot were ignored by Linux and recreated from scratch.

Also, the commit in question looks dubious - it seems unlikely that
Linux would fail to create a resource tree. What does
happen is that BARs get moved around, which may cause trouble in some
cases: for instance, Linux had to add special code to the EFI framebuffer
driver to copy with framebuffer BARs being relocated.

DSM #5 has a long history of debate and misinterpretation.

Link: https://lore.kernel.org/r/20210724185234.GA2265457@roeck-us.net/
Fixes: 0cf8882fd06 ("acpi/gpex: Inform os to keep firmware resource map")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
hw/pci-host/gpex-acpi.c