On Tue, Aug 01, 2017 at 06:20:43PM +0800, Hanjun Guo wrote:
On 2017/7/31 23:23, Lorenzo Pieralisi wrote:
IORT named components provide firmware configuration describing
how many address bits a given device is capable of generating
to address memory.
Add code to the kernel to retrieve memory address limits
configuration for IORT named components and configure DMA masks
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
Cc: Will Deacon <will.deacon@xxxxxxx>
Cc: Robin Murphy <robin.murphy@xxxxxxx>
Cc: Nate Watterson <nwatters@xxxxxxxxxxxxxx>
drivers/acpi/arm64/iort.c | 40 ++++++++++++++++++++++++++++++----------
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 67b85ae..b85d19f 100644
@@ -680,6 +680,24 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
return ret ? NULL : ops;
+static int nc_dma_get_range(struct device *dev, u64 *size)
+ struct acpi_iort_node *node;
+ struct acpi_iort_named_component *ncomp;
+ node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
+ iort_match_node_callback, dev);
+ if (!node)
+ return -ENODEV;
+ ncomp = (struct acpi_iort_named_component *)node->node_data;
+ *size = ncomp->memory_address_limit >= 64 ? ~0ULL :
Just a question here, if the IORT table didn't configure this
value properly, will the device working properly? I'm asking this
because in the table of IORT of D05, this value is set to 0 so far
(SAS and network), but I can boot D05 OK with your patch set, not
sure if any further issues.
Then you wonder why I wrote it as a separate patch. Why is that
value set to 0 (is that because that's the insane default ?) ?
It is a firmware bug and if things work ok with this patch applied
either this patch contains a bug or drivers override the DMA masks
to cancel out this patch effects.
Please fix the firmware.