On Thu, Aug 08, 2019 at 10:58:11AM +0200, Greg KH wrote: > But the main issue here is what exactly is this "fixing"? What is wrong > with the existing code that non-x86 systems have such a problem with? > Shouldn't all of these dma issues be handled by the platform with the > remap_pfn_range() call itself?
remap_pfn_range() takes a PFN. virt_to_phys() converts a kernel *direct mapped* virtual address to a physical address. That much is fine. The question is - what is usbm->mem? If that is anything other than an address returned by kmalloc() or from the normal page allocator, then virt_to_phys() will return garbage. In other words, if it comes from dma_alloc_coherent(), vmalloc() or ioremap(), using virt_to_phys() on it results in garbage. This aspect of virt_to_phys() has been well known about for ages; it's one of the fundamentals of kernel programming. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
