On Wed, Oct 23, 2019 at 1:41 AM Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2019-10-23 at 16:42 +1100, Michael Ellerman wrote: > > > > Right, it seems of_dma_is_coherent() has baked in the assumption that > > devices are non-coherent unless explicitly marked as coherent. > > > > Which is wrong on all or at least most existing powerpc systems > > according to Ben. > > This is probably broken on sparc(64) as well and whatever else uses > DT and is an intrinsicly coherent architecture (did we ever have > DT enabled x86s ? Wasn't OLPC such a beast ?). Only if those platforms use one of the 5 drivers that call this function: drivers/ata/ahci_qoriq.c: qoriq_priv->is_dmacoherent = of_dma_is_coherent(np); drivers/crypto/ccree/cc_driver.c: new_drvdata->coherent = of_dma_is_coherent(np); drivers/iommu/arm-smmu-v3.c: if (of_dma_is_coherent(dev->of_node)) drivers/iommu/arm-smmu.c: if (of_dma_is_coherent(dev->of_node)) drivers/mmc/host/sdhci-of-esdhc.c: if (of_dma_is_coherent(dev->of_node)) Curious that a PPC specific driver (ahci_qoriq) calls it... Note that the value is also passed to arch_setup_dma_ops(), but only arc, arm, arm64, and mips implement arch_setup_dma_ops. > I think this should have been done the other way around and default to > coherent since most traditional OF platforms are coherent, and you > can't just require those DTs to change. You can blame me. This was really only intended for cases where coherency is configurable on a per peripheral basis and can't be determined in other ways. The simple solution here is simply to use the compatible string for the device to determine coherent or not. Rob