Revert "ACPI / x86: Add quirk for "CheckPoint P-20-00" to not use bridge _CRS_ info"

This reverts commit 0a290ac4 on
the basis of the following comment from Bjorn Helgaas:

  Here's my reasoning: this is a CheckPoint product, and it looks
  like an appliance, not really a general-purpose machine.  The issue
  has apparently been there from day one, and the kernel shipped on
  the machine complains noisily about the issue, but apparently
  nobody bothered to investigate it.

  This corruption will clearly break other ACPI-related things.  We
  can sort of work around this one (though the workaround does
  prevent us from doing any PCI resource reassignment), but we have
  no idea what the other lurking ACPI issues are (and we have no
  assurance that *only* ACPI things are broken -- maybe the
  memory corruption affects other unknown things).  It may take
  significant debugging effort to identify the next problem.

  The only report I've seen (this one) is apparently from a
  CheckPoint employee, so it's not clear that anybody else is trying
  to run upstream Linux on it.  Being a CheckPoint employee, [...]
  is probably in a position to get the BIOS fixed.

  You might still be able to convince me, but it seems like the
  benefit to a quirk for this platform is small, and it does cost
  everybody else something in code size and complexity.

References: https://bugzilla.kernel.org/show_bug.cgi?id=47981#c36Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

arch/x86/pci/acpi.c

@@ -98,16 +98,6 @@ static const struct dmi_system_id pci_use_crs_table[] __initconst = {
 			DMI_MATCH(DMI_BIOS_VERSION, "6JET85WW (1.43 )"),
 		},
 	},
-	/* https://bugzilla.kernel.org/show_bug.cgi?id=47981 */
-	{
-		.callback = set_nouse_crs,
-		.ident = "CheckPoint P-20-00",
-		.matches = {
-			DMI_MATCH(DMI_SYS_VENDOR, "CheckPoint"),
-			DMI_MATCH(DMI_PRODUCT_NAME, "P-20-00"),
-			DMI_MATCH(DMI_BOARD_NAME, "Bridgeport"),
-		},
-	},
 	{}
 };