From: sashiko-bot@kernel.org
To: wuqianhai@loongson.cn
Cc: linux-pci@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] PCI/VGA: Fix boot device detection after framebuffer relocation
Date: Wed, 28 Oct 2026 10:11:18 +0000 [thread overview]
Message-ID: <sashiko-outbox-187730@kernel.org> (raw)
In-Reply-To: <20261028094634.766723-1-wuqianhai@loongson.cn>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] PCI/VGA: premature and duplicate screen_info_apply_fixups() in vga_arb_device_init()
- [Medium] PCI/VGA: undefined reference to screen_info_apply_fixups() when !SCREEN_INFO
--
commit da40d2d05299ef123ed4789d2ecb58829165fbe3
Author: wuqianhai <wuqianhai@loongson.cn>
PCI/VGA: Fix boot device detection after framebuffer relocation
This commit calls screen_info_apply_fixups() in vga_arb_device_init() so that
screen_info's lfb_base is updated before VGA devices are registered and
checked by vga_is_firmware_default().
> diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
> index 3e58b2c05c854..aca594651f580 100644
> --- a/drivers/pci/vgaarb.c
> +++ b/drivers/pci/vgaarb.c
> @@ -1527,6 +1527,14 @@ static int __init vga_arb_device_init(void)
> int rc;
> struct pci_dev *pdev;
>
> + /*
> + * PCI resource assignment may have relocated the firmware
> + * framebuffer BAR. Update screen_info's lfb_base so that
> + * vga_is_firmware_default() can match it against the boot
> + * device's relocated resource.
> + */
> + screen_info_apply_fixups();
[Severity: Medium]
Will calling screen_info_apply_fixups() unconditionally in
vga_arb_device_init() fail to link when CONFIG_PCI=y, CONFIG_VGA_ARB=y, and
CONFIG_SCREEN_INFO=n?
In drivers/pci/Kconfig, VGA_ARB only selects SCREEN_INFO on x86:
drivers/pci/Kconfig:
config VGA_ARB
bool "VGA Arbitration" if EXPERT
default y
depends on !S390
select SCREEN_INFO if X86
which matches the CONFIG_X86 guard in vga_is_firmware_default():
drivers/pci/vgaarb.c:vga_is_firmware_default() {
#if defined CONFIG_X86
return pdev == screen_info_pci_dev(&sysfb_primary_display.screen);
#else
return false;
#endif
}
However, include/linux/screen_info.h declares screen_info_apply_fixups() as an
external function whenever CONFIG_PCI is enabled, while
drivers/video/Makefile only builds screen_info_pci.o when CONFIG_SCREEN_INFO
is enabled:
include/linux/screen_info.h:
#if defined(CONFIG_PCI)
void screen_info_apply_fixups(void);
struct pci_dev *screen_info_pci_dev(const struct screen_info *si);
#else
static inline void screen_info_apply_fixups(void)
{ }
drivers/video/Makefile:
obj-$(CONFIG_SCREEN_INFO) += screen_info.o
...
screen_info-$(CONFIG_PCI) += screen_info_pci.o
On non-x86 architectures with CONFIG_PCI=y, CONFIG_VGA_ARB=y, and
CONFIG_SCREEN_INFO=n, doesn't this result in an undefined reference to
screen_info_apply_fixups()?
[Severity: High]
Also, is subsys_initcall_sync(vga_arb_device_init) the right place in the
initcall sequence to call screen_info_apply_fixups()?
Upstream vga_is_firmware_default() in drivers/pci/vgaarb.c only calls
screen_info_pci_dev() under CONFIG_X86. On x86, subsys_initcall(pci_subsys_init)
runs pcibios_resource_survey() -> pcibios_allocate_dev_resources(). When the
firmware framebuffer BAR has a resource conflict and awaits reassignment,
pcibios_allocate_dev_resources() saves the firmware address and resets
r->start to 0 while keeping resource_size(r) intact:
arch/x86/pci/i386.c:pcibios_allocate_dev_resources() {
...
/* We'll assign a new address later */
pcibios_save_fw_addr(dev, idx, r->start);
r->end -= r->start;
r->start = 0;
...
}
The new BAR address on x86 is not assigned until
fs_initcall(pcibios_assign_resources) -> pci_assign_unassigned_resources(),
which runs after subsys_initcall_sync(vga_arb_device_init).
When screen_info_apply_fixups() runs at subsys_initcall_sync while a
conflicting BAR has pr->start == 0, pr->start != screen_info_lfb_res_start is
true and __screen_info_relocation_is_valid(si, pr) succeeds because
resource_size(pr) is unchanged:
drivers/video/screen_info_pci.c:screen_info_apply_fixups() {
if (screen_info_lfb_pdev) {
struct resource *pr = &screen_info_lfb_pdev->resource[screen_info_lfb_bar];
if (pr->start != screen_info_lfb_res_start) {
if (__screen_info_relocation_is_valid(si, pr)) {
__screen_info_set_lfb_base(si, pr->start + screen_info_lfb_offset);
pr_info("Relocating firmware framebuffer to offset %pa[d] within %pr\n",
&screen_info_lfb_offset, pr);
}
...
}
}
}
Wouldn't this clobber si->lfb_base to 0 + screen_info_lfb_offset with a
[mem 0x00000000-...] message before fs_initcall(pcibios_assign_resources)
assigns the actual BAR address, while still failing to match in
vga_is_firmware_default()?
Similarly, for PCI host bridges probed at device_initcall via
pci_host_probe(), vga_arb_device_init() runs before the PCI bus is scanned
and before VGA devices are added via pci_notify().
Finally, since screen_info_apply_fixups() does not update
screen_info_lfb_res_start or clear screen_info_lfb_pdev after applying the
fixup, won't calling it in both vga_arb_device_init() and
device_initcall(sysfb_init) in drivers/firmware/sysfb.c cause the relocation
and log messages to run twice?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261028094634.766723-1-wuqianhai@loongson.cn?part=1
next prev parent reply other threads:[~2026-10-28 10:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 9:46 [PATCH] PCI/VGA: Fix boot device detection after framebuffer relocation wuqianhai
2026-10-28 10:11 ` sashiko-bot [this message]
2026-10-28 23:15 ` Bjorn Helgaas
2026-10-29 3:39 ` wuqianhai
2026-10-29 7:54 ` Thomas Zimmermann
2026-10-29 3:34 ` [PATCH v2] PCI/VGA: Enable firmware default device detection on LoongArch wuqianhai
2026-10-29 3:58 ` sashiko-bot
2026-10-29 8:10 ` Thomas Zimmermann
2026-10-29 7:00 ` [PATCH] PCI/VGA: Fix boot device detection after framebuffer relocation kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-187730@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-pci@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wuqianhai@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox