[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0927fb9f-1044-38b3-d6f3-76edffefd99c@arm.com>
Date: Thu, 27 Aug 2020 19:46:37 +0100
From: Robin Murphy <robin.murphy@....com>
To: Manish Narani <manish.narani@...inx.com>,
gregkh@...uxfoundation.org, robh+dt@...nel.org,
michal.simek@...inx.com, balbi@...nel.org, p.zabel@...gutronix.de
Cc: devicetree@...r.kernel.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, git@...inx.com,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/2] usb: dwc3: Add driver for Xilinx platforms
On 2020-08-26 19:44, Manish Narani wrote:
[...]
> + /*
> + * This routes the usb dma traffic to go through CCI path instead
> + * of reaching DDR directly. This traffic routing is needed to
> + * make SMMU and CCI work with USB dma.
> + */
> + if (of_dma_is_coherent(dev->of_node) || dev->iommu_group) {
> + reg = readl(priv_data->regs + XLNX_USB_COHERENCY);
> + reg |= XLNX_USB_COHERENCY_ENABLE;
> + writel(reg, priv_data->regs + XLNX_USB_COHERENCY);
> + }
This looks rather suspect - coherency should be based on coherency, not
on whether an IOMMU group is present. If the device isn't described as
coherent in the DT, then any SMMU mappings will end up using attributes
that will downgrade traffic to be non-snooping anyway. And if the SMMU
is enabled but not translating (e.g. "iommu.passthrough=1") then
enabling hardware coherency when the DMA layer hasn't been told about it
can potentially lead to nasty subtle problems and data loss.
Robin.
Powered by blists - more mailing lists