On Fri, Jun 01, 2018 at 01:14:22PM +0300, Mathias Nyman wrote: > On 01.06.2018 11:23, Greg KH wrote: > > On Wed, May 23, 2018 at 06:41:35PM +0100, Marc Zyngier wrote: > > > Back around the 4.13 timeframe, we tried to address a rather bad issue > > > with the Renesas uPD72020x USB3 controller family. They have trouble > > > with the programming of the base addresses which tend to stick on XHCI > > > reset. This makes transitionning from 64bit to 32bit addresses > > > completely unsafe. This was observed on a fairly popular arm64 > > > platform (AMD Opteron 1100, which has all of its memory above 4GB). > > > > > > The fix was to perform a PCI reset of the device, but we have had > > > multiple reports that this generated regressions (the controller not > > > being usable after the patch was applied). > > > > > > This series reverts the problematic patch, and tries to address it in > > > a more constrained way. If the controller is behind an IOMMU (and only > > > in that case), we zero its base addresses before reseting it. In the > > > affected configuration, this has the effect of putting the device in a > > > state where the XHCI reset will be effective. > > > > > > It must be noted that in the absence of an IOMMU (and maybe even in > > > its presence), this device is completely unsafe, and may silently > > > corrupt memory. > > > > Mathias, any objections for me queueing these up now for 4.18-rc1? > > > > Nope, 4.18-rc1 is fine for me. > Didn't want to bother you with anything this late in the cycle. > The following patch is also ready for 4.18-rc1: > "[PATCH v2] usb: xhci: force all memory allocations to node" > https://marc.info/?l=linux-usb&m=152701535103950&w=2 > > Feel free to pick it as well. If not then I'll re-send it after 4.18-rc1 > > For both the Renesas series, and memory allocation to node patch: > > Acked-by: Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> Great, will go queue them up now, thanks. greg k-h -- 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
