Thank you for your contribution! Sashiko AI review found 3 potential issue(s) 
to consider:
- [High] PCI/VGA: pci_fixup_vgadev() overrides vga_is_firmware_default() on 
LoongArch
- [Medium] PCI/VGA: duplicate non-idempotent screen_info_apply_fixups() call on 
LoongArch
- [Medium] PCI/VGA: vga_is_firmware_default() fails to match Loongson 
integrated DC
--

commit 6de860408bce3c5a20f5a4c23b073eafdc942117
Author: wuqianhai <[email protected]>

PCI/VGA: Enable firmware default device detection on LoongArch

This commit enables vga_is_firmware_default() on LoongArch, selects
CONFIG_SYSFB from CONFIG_VGA_ARB for LoongArch, and calls
screen_info_apply_fixups() in vga_arb_device_init() so relocated firmware
framebuffer BARs can be matched when selecting the default boot VGA device.

> diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
> index 3e58b2c05c854..1b7e915629f97 100644
> --- a/drivers/pci/vgaarb.c
> +++ b/drivers/pci/vgaarb.c
> @@ -566,7 +566,7 @@ EXPORT_SYMBOL(vga_put);
>  
>  static bool vga_is_firmware_default(struct pci_dev *pdev)
>  {
> -#if defined CONFIG_X86
> +#if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
>       return pdev == screen_info_pci_dev(&sysfb_primary_display.screen);

[Severity: High]
On LoongArch systems with a Loongson display controller (PCI device IDs
0x7a06, 0x7a36, or 0x7a46) and one or more discrete VGA devices, will
pci_fixup_vgadev() in arch/loongarch/pci/pci.c later overwrite the firmware
default VGA device selected here?

During ACPI boot on LoongArch, PCI enumeration runs in
subsys_initcall(acpi_init), and vga_arb_device_init() runs next at
subsys_initcall_sync:

vga_arb_device_init()
  vga_arbiter_add_pci_device()
    vga_is_boot_device()
      vga_is_firmware_default()
    vga_set_default_device(pdev)

After vga_arb_device_init() finishes, pci_apply_final_quirks() in
drivers/pci/quirks.c runs at fs_initcall_sync and invokes the
DECLARE_PCI_FIXUP_FINAL hooks in arch/loongarch/pci/pci.c:

static void pci_fixup_vgadev(struct pci_dev *pdev)
{
        struct pci_dev *devp = NULL;

        while ((devp = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, devp))) {
                if (devp->vendor != PCI_VENDOR_ID_LOONGSON) {
                        vga_set_default_device(devp);
                        dev_info(&pdev->dev,
                                "Overriding boot device as %X:%X\n",
                                devp->vendor, devp->device);
                }
        }
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LOONGSON, PCI_DEVICE_ID_LOONGSON_DC1, 
pci_fixup_vgadev);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LOONGSON, PCI_DEVICE_ID_LOONGSON_DC2, 
pci_fixup_vgadev);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LOONGSON, PCI_DEVICE_ID_LOONGSON_DC3, 
pci_fixup_vgadev);

Because pci_fixup_vgadev() unconditionally calls vga_set_default_device(devp)
for every non-Loongson VGA device without checking whether a firmware default
device was already chosen, won't it clobber vga_default whenever firmware
selected a Loongson display device or the first of multiple non-Loongson
discrete GPUs as the primary display?

[Severity: Medium]
Also in vga_is_firmware_default() in drivers/pci/vgaarb.c, can this pointer
comparison ever match when the firmware framebuffer resides on Loongson
integrated graphics (such as on LS7A1000, LS7A2000, or LS2K2000)?

As shown in lsdc_get_dedicated_vram() in drivers/gpu/drm/loongson/lsdc_drv.c,
the integrated graphics subsystem is split across two PCI functions:

        /*
         * The GPU has 00:06.0 as its BDF, while the DC has 00:06.1
         * This is true for the LS7A1000, LS7A2000 and LS2K2000.
         */
        pdev_gpu = pci_get_domain_bus_and_slot(pci_domain_nr(pdev_dc->bus),
                                               pdev_dc->bus->number,
                                               PCI_DEVFN(6, 0));
        ...
        base = pci_resource_start(pdev_gpu, 2);
        size = pci_resource_len(pdev_gpu, 2);

When the firmware framebuffer is placed in integrated VRAM,
screen_info_pci_dev(&sysfb_primary_display.screen) matches BAR 2 of the
companion GPU device at 00:06.0 (PCI_DEVICE_ID_LOONGSON_GPU1/2/3).

However, vga_arb_device_init() and pci_notify() filter devices using
pci_is_vga(pdev), so only the VGA-class Display Controller function at
00:06.1 (PCI_DEVICE_ID_LOONGSON_DC1/2/3, whose BAR 0 only maps MMIO
registers) is passed to vga_is_firmware_default(pdev). Doesn't comparing
pdev (00:06.1) against screen_info_pci_dev() (00:06.0) always evaluate to
false for the integrated display controller?

>  #else
>       return false;
> @@ -1527,6 +1527,16 @@ static int __init vga_arb_device_init(void)
>       int rc;
>       struct pci_dev *pdev;
>  
> +#if defined(CONFIG_LOONGARCH)
> +     /*
> +      * On LoongArch, PCI resource assignment completes during
> +      * subsys_initcall (acpi_init), before the VGA arbiter runs.  Refresh
> +      * screen_info so vga_is_firmware_default() can match the relocated
> +      * BAR.
> +      */
> +     screen_info_apply_fixups();
> +#endif

[Severity: Medium]
With CONFIG_VGA_ARB selecting CONFIG_SYSFB on LoongArch, calling
screen_info_apply_fixups() here in vga_arb_device_init() at
subsys_initcall_sync means screen_info_apply_fixups() will be called a second
time when sysfb_init() in drivers/firmware/sysfb.c runs at device_initcall:

drivers/firmware/sysfb.c:sysfb_init() {
        ...
        screen_info_apply_fixups();

        mutex_lock(&disable_lock);
        if (disabled)
                goto unlock_mutex;
        ...
}

Looking at screen_info_apply_fixups() in drivers/video/screen_info_pci.c:

void screen_info_apply_fixups(void)
{
        struct screen_info *si = &sysfb_primary_display.screen;

        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);
                        } else {
                                pr_warn("Invalid relocating, disabling firmware 
framebuffer\n");
                        }
                }
        }
}

Because screen_info_apply_fixups() neither updates screen_info_lfb_res_start
nor clears screen_info_lfb_pdev after applying the fixup, won't the second
call in sysfb_init() re-run the relocation logic and print a duplicate
message whenever the framebuffer BAR was relocated, or emit a spurious
warning if a built-in GPU driver probed earlier in device_initcall and
resized the BAR after calling sysfb_disable()?

-- 
Sashiko AI review ยท 
https://sashiko.dev/#/patchset/[email protected]?part=1

Reply via email to