]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
Revert "ACPI / x86: Add quirk for "CheckPoint P-20-00" to not use bridge _CRS_ info"
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>
Fri, 16 Nov 2012 10:08:31 +0000 (11:08 +0100)
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>
Fri, 16 Nov 2012 10:08:31 +0000 (11:08 +0100)
commitbacaf7cd092a2c42a904bce437e64690e04aaa10
tree4cbd70b1e2c4188052dd8905e3e21687cb15ec40
parentbb74ac23b10820d8722c3e1f4add9ef59e703f63
Revert "ACPI / x86: Add quirk for "CheckPoint P-20-00" to not use bridge _CRS_ info"

This reverts commit 0a290ac4252c85205cb924ff7f6da10cfd20fb01 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#c36
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
arch/x86/pci/acpi.c