On Tue, Jul 31, 2018 at 1:30 PM Robin Murphy [off-list ref] wrote:

On 29/07/18 13:32, Arnd Bergmann wrote:

quoted

On Tue, Jul 24, 2018 at 12:16 AM, Robin Murphy [off-list ref] wrote:

quoted

Thanks a lot for working on this, this has bugged me for many years,
and I've discussed possible solutions with lots of people over time.

I /think/ all your patches are good, but I'm currently travelling and don't
have a chance to review the resulting overall implementation.
Could you summarize what happens in the following corner cases of
DT dma-ranges after your changes (with a driver not setting a mask,
setting a 64-bit mask and setting a 24-bit mask, respectively)?

a) a device with no dma-ranges property anywhere in its parents
b) a device with with a 64-bit dma-ranges translation in its parent
    but none in its grandparent
c) a device with no dma-ranges in its parent but a 64-bit mask
    in its grandparent
d) a device with a 24-bit mask in its parent.

In terms of the actual dma-ranges parsing, nothing should be changed by
these patches, so the weirdness and inconsistency that I'm pretty sure
exists for some of those cases will still be there for the moment - I'm
starting on actually fixing of_dma_get_range() now.

Right, but I'm interested in the combination of of_dma_get_range()
with dma_set_mask(), which is the part that was traditionally broken
on arm64 and should be fixed now.

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.

The effect after these patches is that a device with a "valid" (per the
current of_dma_get_range() implementation) dma-ranges translation gets
it bus_dma_mask set to cover the given range, whereas a device with no
valid dma-ranges effectively gets a 32-bit bus_dma_mask. That's slightly
different from the ACPI default behaviour, due to subtle spec
differences, but I think it's in line with what you've proposed before
for DT, and it's certainly still flexible if anyone has a different
view. The bus_dma_mask in itself should also be low-impact, since it
will only currently be enforced in the generic dma-direct and iommu-dma
paths, so the likes of powerpc shouldn't see any change at all just yet.

Ok.

      Arnd