Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

Christoph Hellwig
2017-01-10T14:57:22Z

On Tue, Jan 10, 2017 at 01:25:12PM +0000, Robin Murphy wrote:
> We still need a way for drivers to communicate a device's probed
> addressing capability to SWIOTLB, so there's always going to have to be
> *some* sort of public interface. Personally, the change in semantics I'd
> like to see is to make dma_set_mask() only fail if DMA is entirely
> disallowed - in the normal case it would always succeed, but the DMA API
> implementation would be permitted to set a smaller mask than requested
> (this is effectively what the x86 IOMMU ops do already).

Yes, this sounds reasonable.

> The significant
> work that would require, though, is changing all the drivers currently
> using this sort of pattern:
>
> if (!dma_set_mask(dev, DMA_BIT_MASK(64))
> /* put device into 64-bit mode */
> else if (!dma_set_mask(dev, DMA_BIT_MASK(32))
> /* put device into 32-bit mode */
> else
> /* error */

While we have this pattern in a lot of places it's already rather
pointless on most architectures as the first dma_set_mask call
won't ever fail for the most common dma_ops implementations.

> to something like this:
>
> if (!dma_set_mask(dev, DMA_BIT_MASK(64))
> /* error */
> if (dma_get_mask(dev) > DMA_BIT_MASK(32))
> /* put device into 64-bit mode */
> else
> /* put device into 32-bit mode */
>
> Which would be a pretty major job.

I don't think it's too bad. Also for many modern devices there is no
need to put the device into a specific mode. It's mostly a historic
issue from the PCI/PCI-X days with the less efficient DAC addressing
scheme.