On Sat, Apr 19, 2014 at 10:32:50AM -0400, Santosh Shilimkar wrote: > From: Grygorii Strashko <[email protected]> > > In most of cases DMA addresses can be performed using offset value of > Bus address space relatively to physical address space as following: > > PFN->DMA: > __pfn_to_phys(pfn + [-]dma_pfn_offset) > > DMA->PFN: > __phys_to_pfn(dma_addr) + [-]dma_pfn_offset > > Cc: Greg Kroah-Hartman <[email protected]> > Cc: Russell King <[email protected]> > Cc: Arnd Bergmann <[email protected]> > Cc: Olof Johansson <[email protected]> > Cc: Grant Likely <[email protected]> > Cc: Rob Herring <[email protected]> > Cc: Catalin Marinas <[email protected]> > Cc: Linus Walleij <[email protected]> > Signed-off-by: Grygorii Strashko <[email protected]> > Signed-off-by: Santosh Shilimkar <[email protected]> > --- > arch/arm/include/asm/dma-mapping.h | 17 +++++++++++++---- > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/include/asm/dma-mapping.h > b/arch/arm/include/asm/dma-mapping.h > index e701a4d..8c12149 100644 > --- a/arch/arm/include/asm/dma-mapping.h > +++ b/arch/arm/include/asm/dma-mapping.h > @@ -58,22 +58,31 @@ static inline int dma_set_mask(struct device *dev, u64 > mask) > #ifndef __arch_pfn_to_dma > static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn) > { > - return (dma_addr_t)__pfn_to_bus(pfn); > + if (!dev) > + return DMA_ERROR_CODE; > + return (dma_addr_t)__pfn_to_bus(pfn - dev->dma_pfn_offset);
How do ISA devices (iow, those which pass a NULL device) work with this? This looks to me like it ends up breaking some drivers. I've also seen some drivers (such as the Freescale FEC driver) which perform DMA coherent allocations with a NULL device - technically, that's a bug in the driver, but the above change will cause them to regress. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
