On 3 May 2018 at 11:41, Marc Zyngier <marc.zyng...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
