Re: [PATCH] PCI/VGA: Fix boot device detection after framebuffer relocation

[Bjorn Helgaas <helgaas@kernel.org>]

[+ Loongson folks]

On Thu, Oct 29, 2026 at 11:39:14AM +0800, wuqianhai@loongson.cn wrote:
> Hi Bjorn,
> 
> Thanks for the detailed analysis.
> 
> You're right that screen_info_fixup_lfb()/screen_info_apply_fixups()
> stores a PCI bus address in screen_info_lfb_res_start and compares it
> with the CPU address in pdev->resource[].start, which is broken on
> systems where bus and CPU addresses differ.
> 
> On LoongArch, though, bus and CPU addresses are identical: with modern
> firmware, acpi_prepare_root_resources() takes the PCIH path and leaves
> the window offset at 0 (see commit 49f33840dcc9).  

This is a tangent from the framebuffer question, but what in the world
is 49f33840dcc9 ("LoongArch: Use per-root-bridge PCIH flag to skip mem
resource fixup") doing?  I see that if "PCIH" is non-zero, it skips
some mem resource "fixup" that was added by 57fc7323a8e7 ("LoongArch:
Add PCI controller support").

But I don't understand why that fixup is there in the first place.
Evidently it takes the upper 24 bits of the MCFG address and ORs it
into window addresses from host bridge _CRS?  That sounds nuts.  It
sounds like the ACPI _CRS is just broken.

The struct resource_entry.offset is the offset between PCI bus
addresses and CPU addresses, so entry->offset being non-zero implies
they are NOT identical, at least on non-PCIH platforms.  And if you
have to hack up the offset from the MCFG address, it sounds like the
_CRS entries are missing the _TRA that is supposed to provide the
offset.