Message ID | c604b3eae4103ee0ad6da84baa1bc893a81ef5f8.1531239284.git.robin.murphy@arm.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Tue, Jul 10, 2018 at 06:17:17PM +0100, Robin Murphy wrote: > When an explicit DMA limit is described by firmware, we need to remember > it regardless of how drivers might subsequently update their devices' > masks. The new bus_dma_mask field does that. Shouldn't we also stop presetting the dma mask after this?
On 10/07/18 19:04, Christoph Hellwig wrote: > On Tue, Jul 10, 2018 at 06:17:17PM +0100, Robin Murphy wrote: >> When an explicit DMA limit is described by firmware, we need to remember >> it regardless of how drivers might subsequently update their devices' >> masks. The new bus_dma_mask field does that. > > Shouldn't we also stop presetting the dma mask after this? I guess initialising the device masks here only really has any effect if drivers fail to set their own, so if we're getting stricter about that then it would make sense to stop; I'll add a couple of patches on top to clean that up. Robin.
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index 4a66896e2aa3..bc51cff5505e 100644 --- a/drivers/acpi/arm64/iort.c +++ b/drivers/acpi/arm64/iort.c @@ -1014,6 +1014,7 @@ void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size) * Limit coherent and dma mask based on size * retrieved from firmware. */ + dev->bus_dma_mask = mask; dev->coherent_dma_mask = mask; *dev->dma_mask = mask; }
When an explicit DMA limit is described by firmware, we need to remember it regardless of how drivers might subsequently update their devices' masks. The new bus_dma_mask field does that. Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- drivers/acpi/arm64/iort.c | 1 + 1 file changed, 1 insertion(+)