Thread (41 messages) 41 messages, 9 authors, 2018-08-06
DORMANTno replies
Revisions (3)
  1. v2 [diff vs current]
  2. v2 [diff vs current]
  3. v2 current

[PATCH v2 0/7] Stop losing firmware-set DMA masks

From: arnd@arndb.de (Arnd Bergmann)
Date: 2018-08-06 12:13:45
Also in: linux-acpi, linux-iommu

On Mon, Aug 6, 2018 at 2:08 PM Christoph Hellwig [off-list ref] wrote:
On Mon, Aug 06, 2018 at 12:01:34PM +0200, Arnd Bergmann wrote:
quoted
There are a few subtle corner cases here, in particular in which cases
the new dma_set_mask() behavior on arm64 reports success or
failure when truncating the mask to the bus_dma_mask.
Going forward my plan was to make dma_set_mask() never fail.  The idea
is that it sets the mask that the device is capable of, and the core
dma code is responsible for also looking at bus_dma_mask and otherwise
make things just work.

Robin brought up the case where a platform can't handle a given limitation
ever, e.g. a PCI(e) device with a 24-bit dma mask on a device with a dma
offset that means we'll never have any physical memory reachable in that
range.  So we'll either still need to allow it to fail for such corner
cases or delay such error until later, e.g. when dma_alloc_* (or in the
corner case of the corner case dma_map_*) is called.  I'm still undecided
which way to go, but not allowing error returns from dma_set_mask and
its variants sounds very tempting.
Another case that I think can happen in practice are devices that need a
DMA mask smaller than 32-bit wide (either asked for by the driver
or according to bus limitations) on a platform that has no ZONE_DMA.

However, IIRC there was no reason to ever fail a dma_set_mask()
to something wider than 32 bit even if the resulting mask still stays
at the default 32-bit mask or something inbetween.

      Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help