Hello, On Fri, 6 Jan 2017 14:44:56 +0000, Robin Murphy wrote: > >> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT > >> + dma_addr_t dma_addr = > >> + rx_desc->pp22.buf_phys_addr_key_hash & DMA_BIT_MASK(40); > >> + phys_addr_t phys_addr = > >> + dma_to_phys(port->dev->dev.parent, dma_addr); > > Ugh, this looks bogus. dma_to_phys(), in the arm64 case at least, is > essentially a SWIOTLB internal helper function which has to be > implemented in architecture code because reasons. Calling it from a > driver is almost certainly wrong (it doesn't even exist on most > architectures). Besides, if this is really a genuine dma_addr_t obtained > from a DMA API call, you cannot infer it to be related to a CPU physical > address, or convertible to one at all. So do you have a better suggestion? The descriptors only have enough space to store a 40-bit virtual address, which is not enough to fit the virtual addresses used by Linux for SKBs. This is why I'm instead relying on the fact that the descriptors can store the 40-bit physical address, and convert it back to a virtual address, which should be fine on ARM64 because the entire physical memory is part of the kernel linear mapping. > >> + return (unsigned long)phys_to_virt(phys_addr); > >> +#else > >> + return rx_desc->pp22.buf_cookie_misc & DMA_BIT_MASK(40); > >> +#endif > > > > I'm not sure that's the best way of selecting the difference. > > Given that CONFIG_ARCH_DMA_ADDR_T_64BIT could be enabled on 32-bit LPAE > systems, indeed it definitely isn't. Russell proposal of testing the size of a virtual address pointer instead would solve this I believe, correct? Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
