* [PATCH] dma-direct: don't truncate dma_required_mask to bus addressing capabilities
@ 2019-08-05 15:51 Lucas Stach
2019-08-06 5:23 ` Christoph Hellwig
0 siblings, 1 reply; 3+ messages in thread
From: Lucas Stach @ 2019-08-05 15:51 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Robin Murphy
Cc: iommu, linux-kernel, kernel, patchwork-lst
The dma required_mask needs to reflect the actual addressing capabilities
needed to handle the whole system RAM. When truncated down to the bus
addressing capabilities dma_addressing_limited() will incorrectly signal
no limitations for devices which are restricted by the bus_dma_mask.
Fixes: b4ebe6063204 (dma-direct: implement complete bus_dma_mask handling)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
kernel/dma/direct.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 59bdceea3737..7ba3480fc546 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -47,9 +47,6 @@ u64 dma_direct_get_required_mask(struct device *dev)
{
u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
- if (dev->bus_dma_mask && dev->bus_dma_mask < max_dma)
- max_dma = dev->bus_dma_mask;
-
return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] dma-direct: don't truncate dma_required_mask to bus addressing capabilities
2019-08-05 15:51 [PATCH] dma-direct: don't truncate dma_required_mask to bus addressing capabilities Lucas Stach
@ 2019-08-06 5:23 ` Christoph Hellwig
2019-08-06 20:16 ` Atish Patra
0 siblings, 1 reply; 3+ messages in thread
From: Christoph Hellwig @ 2019-08-06 5:23 UTC (permalink / raw)
To: Lucas Stach
Cc: Christoph Hellwig, Marek Szyprowski, Robin Murphy, iommu,
linux-kernel, kernel, patchwork-lst, Atish Patra
On Mon, Aug 05, 2019 at 05:51:53PM +0200, Lucas Stach wrote:
> The dma required_mask needs to reflect the actual addressing capabilities
> needed to handle the whole system RAM. When truncated down to the bus
> addressing capabilities dma_addressing_limited() will incorrectly signal
> no limitations for devices which are restricted by the bus_dma_mask.
>
> Fixes: b4ebe6063204 (dma-direct: implement complete bus_dma_mask handling)
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Yeah, this looks sensible. Atish, can you check if this helps on the
HiFive board as well?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] dma-direct: don't truncate dma_required_mask to bus addressing capabilities
2019-08-06 5:23 ` Christoph Hellwig
@ 2019-08-06 20:16 ` Atish Patra
0 siblings, 0 replies; 3+ messages in thread
From: Atish Patra @ 2019-08-06 20:16 UTC (permalink / raw)
To: hch, l.stach
Cc: robin.murphy, m.szyprowski, kernel, patchwork-lst, linux-kernel,
Alistair Francis, iommu
On Tue, 2019-08-06 at 07:23 +0200, Christoph Hellwig wrote:
> On Mon, Aug 05, 2019 at 05:51:53PM +0200, Lucas Stach wrote:
> > The dma required_mask needs to reflect the actual addressing
> > capabilities
> > needed to handle the whole system RAM. When truncated down to the
> > bus
> > addressing capabilities dma_addressing_limited() will incorrectly
> > signal
> > no limitations for devices which are restricted by the
> > bus_dma_mask.
> >
> > Fixes: b4ebe6063204 (dma-direct: implement complete bus_dma_mask
> > handling)
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
>
> Yeah, this looks sensible. Atish, can you check if this helps on the
> HiFive board as well?
Yes. It fixes the nvme issue on HiFive Unleashed + Microsemi expansion
board.
FWIW,
Tested-by: Atish Patra <atish.patra@wdc.com>
Regards,
Atish
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-08-06 20:16 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-05 15:51 [PATCH] dma-direct: don't truncate dma_required_mask to bus addressing capabilities Lucas Stach
2019-08-06 5:23 ` Christoph Hellwig
2019-08-06 20:16 ` Atish Patra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).