(remove most cc's) Hi all, Apologies for digging up this old thread. I am currently looking into whether it is feasible to refactor some of the ACPI PCI quirk code we have so it can apply to more instances of the Synopsys Designware PCIe (i.e., for Marvell and Socionext SOCs), which all suffer from the same issue that type 0 config TLPs are not filtered before being sent out on the link, resulting in devices appearing multiple times. The pci-hisi.c quirk already appears to do exactly what would solve the problem on other SoCs as well. So I will try to refactor this code into something that I could propose for upstream, while probably getting the ARM SBSA authors to offer some guidance that this IP must not be used for new designs. In any case, the chances of any such changes being acceptable upstream are probably higher if we can reuse the exact same quirk as we have already implemented for HiSilicon, so I wonder if anyone from Huawei could comment on some questions I have: - Why does the config space accessor override use 32-bit accesses only for bus #0? Is that really necessary? - Why does the Hisi quirk use different config base addresses for bus #0 and the other buses? Is this simply because the firmware does not use contiguous iATU windows for bus #0 and buses #1 and up? So is there anything mapped in the 1 MB slice at the base of the respective 256 MB mappings that generate type1 config cycles? Having just a shared set of config space accessor overrides would already be an improvement, given that they can be shared with a DT based driver for this IP in ECAM mode as well. Thanks, Ard. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
