The issue with PCIe is not a quirk, but a bug in the PCIe code that has been in the kernel since 2017. Yes we are exposing the bus in a non-standard way to work around silicon limitations but the bug we exposed is due to the code not being written to the PCIe spec, not what we are doing. The only consumer of the function that needs to be patched is the amdgpu driver. This is made worse by the amdgpu driver not respecting the ACPI tables telling it not to re-assign those resources.
Most likely not. The code was an assumption you wouldn't re-assign a bar on the device sitting on the root of the bus. Even though in our implementation this node is not actually the root controller, that assumption is still invalid since root controllers can have their own bars.
The issue with PCIe is not a quirk, but a bug in the PCIe code that has been in the kernel since 2017. Yes we are exposing the bus in a non-standard way to work around silicon limitations but the bug we exposed is due to the code not being written to the PCIe spec, not what we are doing. The only consumer of the function that needs to be patched is the amdgpu driver. This is made worse by the amdgpu driver not respecting the ACPI tables telling it not to re-assign those resources.
Huh, cool. I guess this bug might not be present in other operating systems.
Most likely not. The code was an assumption you wouldn't re-assign a bar on the device sitting on the root of the bus. Even though in our implementation this node is not actually the root controller, that assumption is still invalid since root controllers can have their own bars.
Do operating systems need to handle the NXP0016 device?
NetBSD does: github.com/NetBSD/src/commit/1a0fb...
but, hm, github doesn't find "NXP0016" in Linux.