[+cc Dave for sparc64, Yinghai] On Fri, May 01, 2015 at 01:32:15PM -0500, [email protected] wrote: > From: Will Davis <[email protected]> > > Simply route these through to the new dma_(un)map_resource APIs. > > Signed-off-by: Will Davis <[email protected]> > Reviewed-by: Terence Ripperda <[email protected]> > Reviewed-by: John Hubbard <[email protected]> > --- > include/asm-generic/pci-dma-compat.h | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/include/asm-generic/pci-dma-compat.h > b/include/asm-generic/pci-dma-compat.h > index c110843..ac4a4ad 100644 > --- a/include/asm-generic/pci-dma-compat.h > +++ b/include/asm-generic/pci-dma-compat.h > @@ -61,6 +61,20 @@ pci_unmap_page(struct pci_dev *hwdev, dma_addr_t > dma_address, > dma_unmap_page(hwdev == NULL ? NULL : &hwdev->dev, dma_address, size, > (enum dma_data_direction)direction); > } > > +static inline dma_addr_t > +pci_map_resource(struct pci_dev *hwdev, struct resource *resource, > + unsigned long offset, size_t size, int direction) > +{ > + return dma_map_resource(hwdev == NULL ? NULL : &hwdev->dev, resource, > offset, size, (enum dma_data_direction)direction); > +}
On sparc64, PCI bus addresses, e.g., raw BAR values, can be 64 bits wide, but dma_addr_t is only 32 bits [1]. So dma_addr_t is a bit of a problem here. It's likely that we will add a pci_bus_addr_t, but that hasn't happened yet [2]. We do have existing problems already, e.g,. pci_bus_address() returns a dma_addr_t, so it has the same problem. So I guess this is just a heads-up that this needs to be fixed eventually. Bjorn [1] http://lkml.kernel.org/r/[email protected] [2] http://lkml.kernel.org/r/[email protected] _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
