On 12/14/20 5:08 PM, Lorenzo Pieralisi wrote:
On Sat, Dec 12, 2020 at 08:13:54PM +0100, Marek Vasut wrote:
On 12/10/20 7:11 PM, Lorenzo Pieralisi wrote:
[...]
diff --git a/drivers/pci/controller/pcie-rcar-host.c b/drivers/pci/controller/pcie-rcar-host.c
index 1194d5f3341b..ac5c7d7573a6 100644
--- a/drivers/pci/controller/pcie-rcar-host.c
+++ b/drivers/pci/controller/pcie-rcar-host.c
@@ -753,7 +753,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie_host *host)
}
/* setup MSI data target */
- msi->pages = __get_free_pages(GFP_KERNEL, 0);
+ msi->pages = __get_free_pages(GFP_KERNEL | GFP_DMA32, 0);
This does not do what you want on !CONFIG_ZONE_DMA32 (ie arm LPAE).
How come? I would expect GFP_DMA32 allocates a buffer below 4 GiB in any
case.
For ARM LPAE allocation falls back to ZONE_NORMAL that happens to work
because if there is memory > 4GB it ends up in ZONE_HIGHMEM, so this
patch should still work on ARM LPAE too.
Regardless, thoughts above the alternative approach (that saves you
a page allocation) ?
Since this is a bugfix, I would prefer it to be minimal.
Also, in case there was some yet undiscovered hardware bug which would
let the MSI write through, having unused memory as the MSI destination
address would only lead to write into that memory -- instead of a write
into some other address.
Changing this to some hard-coded address (any suggestions?) can be a
subsequent patch.
