patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

[Marc Zyngier <marc.zyngier@arm.com>]

On 03/05/18 11:41, Ard Biesheuvel wrote:
> On 3 May 2018 at 11:41, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 03/05/18 09:42, Faiz Abbas wrote:
>>> Hi Marc,
>>>
>>> On Thursday 03 May 2018 01:44 PM, Marc Zyngier wrote:
>>>> On 03/05/18 05:49, Faiz Abbas wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> On Wednesday 11 April 2018 07:32 PM, Marc Zyngier wrote:
>>>>>> On Wed, 11 Apr 2018 14:11:52 +0100,
>>>>>> Bockholdt Arne wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> is there anything new, I've just tried the new stable 4.16.1 kernel
>>>>>>> without any change. The Renesys USB3 controller is still not
>>>>>>> functional. I'm willing to test any patch that is based on a stable
>>>>>>> kernel version because the machine is in production use.
>>>>>>
>>>>>> Have you tested the branch[1] I mentioned in my previous email?
>>>>>> Without your feedback, I cannot really make much progress on this.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>    M.
>>>>>>
>>>>>> [1] https://www.spinics.net/lists/linux-usb/msg167301.html
>>>>>>
>>>>>
>>>>> I was also having problems with a Renesas card (01:00.0 USB controller
>>>>> [0c03]: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller
>>>>> [1912:0014]) on a dra72x-evm. The kernel would just hang because of the
>>>>> xhci reset.
>>>>>
>>>>> Log:https://pastebin.ubuntu.com/p/dYYV9DZMwx/
>>>>>
>>>>> The patches on Marc's branch have fixed this for me as well. Thanks for
>>>>> the fix.
>>>> OK. I'll rebase this on a more recent version of the kernel, make it
>>>> conditional on having an iommu (as it seems to be the only affected
>>>> configuration), and post that to a wider audience.
>>>
>>> Just to be sure, you are talking about the original 32 bit DMA issue
>>> being conditional on iommu right? Because dra72x doesn't use iommu.
>>
>> I'm talking about making the whole workaround dependent on the USB
>> controller being behind an iommu. No iommu, no workaround (because it is
>> likely that there is no problem in that case).
>>
> 
> That is still only a partial solution, unfortunately.
> 
> On non-x86 systems with memory above and below the 4 GB mark, it is
> undefined which side the firmware will choose and which side the
> kernel will choose (although I suppose the kernel may attempt to
> preserve 32-bit addressable memory for peripherals that are only
> 32-bit capable)
> 
> This would be much easier to fix at the UEFI stub level (but still in
> kernel code, not firmware), by checking for PCI I/O protocol instances
> with the correct VID/PID and check whether the
> EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is set, but that is
> also only a partial solution.

Unfortunately, I'm not sure there is a full solution that works for
everyone, and doesn't introduce regression. The reset method is proving
to be bad for a number of platform, so I'd rather have something that
narrowly matches the one broken case we know about.

Without knowing more about the internals of that controller, I'm not
convinced we can do much more...

	M.