[PATCH 5/5] PCI/quirks: Avoid certain BAR 0 address with igb

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

While testing the resource placement changes, my tests hit a case where
igb fails to probe when BAR 0 is placed at 0x9c000000:

   90000000-9cffffff : PCI Bus 0000:a0
  -  90000000-902fffff : PCI Bus 0000:a1
  -    90000000-900fffff : 0000:a1:00.0
  -      90000000-900fffff : igb
  -    90100000-901fffff : 0000:a1:00.0
  -    90200000-90203fff : 0000:a1:00.0
  -      90200000-90203fff : igb
  +  9be00000-9c0fffff : PCI Bus 0000:a1
  +    9be00000-9befffff : 0000:a1:00.0
  +    9bf00000-9bf03fff : 0000:a1:00.0
  +    9c000000-9c0fffff : 0000:a1:00.0
     9c100000-9c17ffff : amd_iommu
     9c180000-9c1803ff : IOAPIC 8

  -       Region 0: Memory at 90000000 (32-bit, non-prefetchable) [size=1M]
  -       Region 3: Memory at 90200000 (32-bit, non-prefetchable) [size=16K]
  -       Expansion ROM at 90100000 [disabled] [size=1M]
  +       Region 0: Memory at 9c000000 (32-bit, non-prefetchable) [size=1M]
  +       Region 3: Memory at 9bf00000 (32-bit, non-prefetchable) [size=16K]
  +       Expansion ROM at 9be00000 [disabled] [size=1M]

igb 0000:a1:00.0 0000:a1:00.0 (uninitialized): PCIe link lost
------------[ cut here ]------------
igb: Failed to read reg 0x18!
WARNING: drivers/net/ethernet/intel/igb/igb_main.c:724 at igb_rd32.cold+0x3c/0x4f [igb], CPU#32: kworker/32:1/706
...
 igb_get_invariants_82575+0xff/0xf00 [igb]
 igb_probe+0x3c8/0x1190 [igb]
 local_pci_probe+0x3b/0x80

Apparently, the igb driver bails out, after its initial sanity check
detects an unexpected ~0 read. Hacking around the sanity check just
results in more failures down the road so the sanity check itself is not
the cause for the failure.

The resource placement looks valid so the actual placement patches seem
to work normally.

All other possible 1M address I could test (with a hack patch) did work.

Add quirk to reshuffle igb resources, use BAR 3 to block the problematic
address.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
---

I know this is ugly and I don't like it either but do not know better
way to avoid the regression.

I've tried with iommu=off and that did not resolve the issue.

I also managed to prove igb works with the same resource layout in
another system. So identifying the case should probably be tightened
by matching with more devices than the one used by igb. This is open
to discussion.

---
 drivers/pci/quirks.c | 56 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index de9bbccda21f..e6f3e2ab1fd4 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6288,6 +6288,62 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1536, rom_bar_overlap_defect);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1537, rom_bar_overlap_defect);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1538, rom_bar_overlap_defect);
 
+/*
+ * The igb driver probe (due to reads returning ~0 unexpected) when BAR 0
+ * appears at 0x9c000000. The cause is unknown.
+ *
+ * Use BAR 3 to block 0x9c000000 address.
+ */
+static void bar0_address_breakage(struct pci_dev *dev)
+{
+	struct resource *bar0 = pci_resource_n(dev, 0);
+	struct resource *bar3 = pci_resource_n(dev, 3);
+	resource_size_t broken_addr = 0x9c000000;
+	struct resource *res;
+	int i, ret;
+
+	if (bar0->start != broken_addr)
+		return;
+
+	/*
+	 * HW BAR sizes seems to vary. Exclude non-1M BAR 0 case and
+	 * sanity check BAR 0 & 3 before attempting this quirk.
+	 */
+	if (resource_type(bar0) != IORESOURCE_MEM ||
+	    resource_size(bar0) != SZ_1M ||
+	    resource_type(bar3) != IORESOURCE_MEM)
+		return;
+
+	pci_info(dev, "%pR: relocating BAR\n", bar0);
+
+	pci_dev_for_each_resource(dev, res, i) {
+		if (!resource_assigned(res) ||
+		    resource_type(res) != IORESOURCE_MEM)
+			continue;
+
+		pci_release_resource(dev, i);
+	}
+
+	resource_set_range(bar3, broken_addr, resource_size(bar3));
+	bar3->flags &= ~IORESOURCE_UNSET;
+	pci_claim_resource(dev, 3);
+	if (!resource_assigned(bar3)) {
+		bar3->flags |= IORESOURCE_UNSET;
+		pci_warn(dev, "resource relocation failed\n");
+	}
+
+	pci_dev_for_each_resource(dev, res, i) {
+		if (resource_assigned(res) ||
+		    resource_type(res) != IORESOURCE_MEM)
+			continue;
+
+		ret = pci_assign_resource(dev, i);
+		if (ret)
+			pci_warn(dev, "resource relocation failed\n");
+	}
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1533, bar0_address_breakage);
+
 #ifdef CONFIG_PCIEASPM
 /*
  * Several Intel DG2 graphics devices advertise that they can only tolerate
-- 
2.47.3