On Sun, 25 Mar 2018 11:48:35 +0100, Ard Biesheuvel wrote: Hi Ard, [...] > > I finally found some time to work on this, and came up with an > > alternative approach (it turns out that this chip is even more > > braindead than I thought). > > > > It is slightly scary, in the sense that the USB controller seems to > > perform memory accesses even when halted, and can generate faults, > > but it works just fine on my system. And with this, we can drop the > > hard reset at boot time. I'm still on the fence to limit it to systems > > with an iommu though. > > > > Hi Marc, > > I take it you tested this on Cello? Tested on Cello indeed (I should have mentioned that the first place). > There, it might make sense to > limit this to systems with an IOMMU, but not in the general case, I > think. The reason is that it is not guaranteed that the firmware will > use 32-bit addressable allocations for these data structures, even if > the kernel is able to without an IOMMU. (UEFI on arm64 will not prefer > 32-bit addressable memory for PCI DMA if it is available, and usually > serves heap allocations [such as the ones used for these data > structures] starting at the top of DRAM) My main worry is that this controller will happily try and DMA from zero as we wipe the 64bit registers, even when halted. On Seattle (and thus Cello), this is just fine as there is nothing there, and the controller aborts with the HSE bit set. On other systems, where memory actually exists at 0, who knows what this is going to do? On the other hand, this is not worse than the current situation, where we could end-up with any odd address... M. -- Jazz is not dead, it just smell funny. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
