[PATCH 2/2] usb: dwc3: Add driver for Xilinx platforms

[Robin Murphy]

On 2020-08-28 18:53, Manish Narani wrote:
> Hi Robin,
> 
> Thanks for the review. Please find my comment below inline.
> 
>> -----Original Message-----
>> From: Robin Murphy <robin.murphy at arm.com>
>> Sent: Friday, August 28, 2020 12:17 AM
>> To: Manish Narani <MNARANI at xilinx.com>; gregkh at linuxfoundation.org;
>> robh+dt at kernel.org; Michal Simek <michals at xilinx.com>; balbi at kernel.org;
>> p.zabel at pengutronix.de
>> Cc: devicetree at vger.kernel.org; linux-usb at vger.kernel.org; linux-
>> kernel at vger.kernel.org; git <git at xilinx.com>; linux-arm-
>> kernel at lists.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.
> 
> May be the description needs to be updated in this. This is not the actual coherency enabling bit, but this is needed when coherency is enabled.
> This is a register inside Xilinx USB controller which handles USB (which is in LPD) traffic route switching from LPD (Low Power Domain) to FPD (Full Power Domain)  path in the Xilinx SoC in either of the below scenarios:
> 1. Device is described coherent in  DT.
> 2. SMMU is enabled.
> 
> I will update the same in v2.

Ah, OK, so it's just that the control bit itself has a terrible name :)

 From the available information I had assumed that this controlled the 
output attributes, and that the interconnect might then steer traffic 
based on those. Explaining a bit more clearly in the comment probably 
would be a good idea. In that case, I'd concur that the current logic is 
in fact appropriate, but please use the device_iommu_mapped() helper for 
cleanliness.

Cheers,
Robin.