On Mon, Feb 27, 2023 at 10:12:21AM +0800, Shawn Guo wrote: > Commit 8fd4391ee717 ("arm64: PCI: Exclude ACPI "consumer" resources from > host bridge windows") introduced a check to remove host bridge register > resources for all arm64 platforms, with the assumption that the PNP0A03 > _CRS resources would always be host bridge registers and never as windows > on arm64. > > The assumption stands true until Qualcomm Snapdragon Windows laptops > emerge. These laptops describe host bridge windows in PNP0A03 _CRS > resources instead. For example, the Microsoft Surface Pro X has host > bridges defined as > > Name (_HID, EisaId ("PNP0A08") /* PCI Express Bus */) // _HID: Hardware ID > Name (_CID, EisaId ("PNP0A03") /* PCI Bus */) // _CID: Compatible ID > > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings > { > Name (RBUF, ResourceTemplate () > { > Memory32Fixed (ReadWrite, > 0x60200000, // Address Base > 0x01DF0000, // Address Length > ) > WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, > 0x0000, // Granularity > 0x0000, // Range Minimum > 0x0001, // Range Maximum > 0x0000, // Translation Offset > 0x0002, // Length > ,, ) > }) > Return (RBUF) /* \_SB_.PCI0._CRS.RBUF */ > } > > The Memory32Fixed holds a host bridge window, but it's not properly > defined as a "producer" resource. Consequently the resource gets > removed by kernel, and the BAR allocation fails later on: > > [ 0.150731] pci 0002:00:00.0: BAR 14: no space for [mem size 0x00100000] > [ 0.150744] pci 0002:00:00.0: BAR 14: failed to assign [mem size 0x00100000] > [ 0.150758] pci 0002:01:00.0: BAR 0: no space for [mem size 0x00004000 64bit] > [ 0.150769] pci 0002:01:00.0: BAR 0: failed to assign [mem size 0x00004000 64bit] > > This eventually prevents the PCIe NVME drive from being accessible. > > Add a quirk for these platforms to avoid the resource being removed. > > Signed-off-by: Shawn Guo <shawn.guo@xxxxxxxxxx> > --- > We are running into the issue on more devices than just Surface Pro X > now, so trying to sort it out with a quirk as suggested by Lorenzo [1]. One thing I don't like about this application of quirks is that the list of affected platforms is likely to grow, which is an ongoing burden for users and developers. Can we have a conversation with Qualcomm about how they *intend* this to work? Linux is probably doing something wrong (interpreting something differently than Windows does), and if we could fix that, we have a better chance of future platforms working without quirks. > [1] https://lore.kernel.org/all/20210527093200.GA16444@lpieralisi/ > > arch/arm64/kernel/pci.c | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c > index 2276689b5411..896dbd028b67 100644 > --- a/arch/arm64/kernel/pci.c > +++ b/arch/arm64/kernel/pci.c > @@ -109,16 +109,42 @@ int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge) > return 0; > } > > +#define QCOM_DSDT_QUIRK "Host bridge windows in PNP0A03 _CRS" > + > +static struct acpi_platform_list qcom_platlist[] = { > + /* Thinkpad X13s */ > + { "LENOVO", "SDM8280 ", 0, ACPI_SIG_DSDT, all_versions, QCOM_DSDT_QUIRK }, > + /* Microsoft Surface Pro 9 (5G) and Windows Dev Kit 2023 */ > + { "QCOMM ", "SDM8280 ", 0, ACPI_SIG_DSDT, all_versions, QCOM_DSDT_QUIRK }, > + /* Microsoft Surface Pro X */ > + { "QCOMM ", "SDM8180 ", 0, ACPI_SIG_DSDT, all_versions, QCOM_DSDT_QUIRK }, > + { } > +}; > + > static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci) > { > struct resource_entry *entry, *tmp; > int status; > + int idx; > > status = acpi_pci_probe_root_resources(ci); > + > + /* > + * Most arm64 platforms that do not run Windows describe host bridge > + * registers in PNP0A03 _CRS resources, but some like Qualcomm > + * Snapdragon Windows laptops describe host bridge windows in there. > + * We do not want to destroy the resources for these platforms. > + */ > + idx = acpi_match_platform_list(qcom_platlist); > + if (idx >= 0) > + goto done; > + > resource_list_for_each_entry_safe(entry, tmp, &ci->resources) { > if (!(entry->res->flags & IORESOURCE_WINDOW)) > resource_list_destroy_entry(entry); > } > + > +done: > return status; > } > > -- > 2.17.1 >