PNPACPI, x86/PCI: handle _CRS windows like Windows does
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest2 patches 2 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | PNPACPI: compute Address Space length rather than using _LENdrivers/ | +4 | 0 replies | |
| 2/2 | x86/PCI: compute Address Space length rather than using _LENarch/ | +2 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] PNPACPI, x86/PCI: handle _CRS windows like Windows does
These patches simplify the way we handle Address Space descriptors and make Linux do it more like Windows does.
The PNPACPI change is definitely .35 material, since I don't think anybody uses this information via PNP yet.
My first thought was that the x86/PCI change is for .35, too, but it does make a difference in some cases, so maybe it should go in .34.
Here's an example where it matters. ACPI _CRS could have an MMIO Address Space descriptor like this:
_MIN 0xE0000000
_MAX 0xFEBFFFFF
_LEN 0x10000000,
which doesn't satisfy the spec requirement that:
_MAX == _MIN + _LEN - 1,
but obviously we can't rely on spec compliance. These are the ways we could interpret it:
[mem 0xe0000000-0xefffffff] current Linux way (end is _MIN + _LEN - 1) [mem 0xe0000000-0xfebfffff] new Linux way (end is _MAX) [mem 0xe0000000-0xfebfffff] Windows way (end is _MAX)
The risk is that BIOS might have placed a PCI device in the area that we used to think was illegal, i.e., anywhere in [mem 0xf0000000-0xfebfffff], and Linux will try to move the device unnecessarily, and that move might fail.
---
Bjorn Helgaas (2):
PNPACPI: compute Address Space length rather than using _LEN x86/PCI: compute Address Space length rather than using _LEN
arch/x86/pci/acpi.c | 40 ++-------------------------------------- drivers/pnp/pnpacpi/rsparser.c | 26 ++++---------------------- 2 files changed, 6 insertions(+), 60 deletions(-)