diff options
| author | Michael S. Tsirkin | 2021-07-27 11:18:47 +0200 |
|---|---|---|
| committer | Michael S. Tsirkin | 2021-08-03 22:32:34 +0200 |
| commit | 40c3472a29c9a1fd65255fc196aa6feb99aaec9e (patch) | |
| tree | ed97d161ca901b63e759ac539d29a0a1ecc32c73 /tests/data/acpi/virt | |
| parent | arm/acpi: allow DSDT changes (diff) | |
| download | qemu-40c3472a29c9a1fd65255fc196aa6feb99aaec9e.tar.gz qemu-40c3472a29c9a1fd65255fc196aa6feb99aaec9e.tar.xz qemu-40c3472a29c9a1fd65255fc196aa6feb99aaec9e.zip | |
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>
Diffstat (limited to 'tests/data/acpi/virt')
0 files changed, 0 insertions, 0 deletions