On Fri, Jul 27, 2018 at 12:36:00PM +0100, Robin Murphy wrote:

That is intentional. Consider a 32-bit device on a bus with an upstream DMA
range of 40 bits (which could easily happen with e.g. PCI). If the firmware
code gives that device 40-bit DMA masks and the driver doesn't change them,
then DMA is not going to work correctly. Therefore the firmware code cannot
safely make {coherent_}dma_mask larger than the default value passed in, and
if the default is 0 then that should be fixed in whatever code created the
device, not worked around later.

I think you're missing the point.

When OF creates platform devices, they are created without any DMA masks
what so ever.  It is only during device probe that dma_configure() gets
called, which then calls of_dma_configure(), where the DMA mask for any
DT declared device is setup.

What this means is that your change has broken all existing DT devices
that are trying to use DMA, because they now end up with a zero coherent
DMA mask and/or streaming DMA mask.

Your original idea behind the patch may be a sound one, but since the
implementation has caused a regression, the implementation is obviously
broken, and that needs fixing or reworking in some way.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up