> On Wed, Jul 01, 2015 at 11:06:06AM -0500, Bjorn Helgaas wrote:
> > On Fri, May 29, 2015 at 12:14:42PM -0500, wdavis@... wrote:
> > > From: Will Davis <wdavis@...>
> > >
> > > Simply route these through to the new dma_(un)map_resource APIs.
> > >
> > > Signed-off-by: Will Davis <wdavis@...>
> > > Reviewed-by: Terence Ripperda <tripperda@...>
> > > Reviewed-by: John Hubbard <jhubbard@...>
> > > ---
> > > 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
> > > <at> <at> -61,6 +61,20 <at> <at> 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)
> >
> > After 3a9ad0b4fdcd ("PCI: Add pci_bus_addr_t"), which will appear in
> > v4.2-rc1, there is a pci_bus_addr_t, and I think you need that instead
> > of dma_addr_t.
> >
> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3a9ad0b4fdcd
>
> This wasn't a very good response, sorry. I don't think just
> changing dma_addr_t to pci_bus_addr_t is a good resolution.
>
> Isn't there an implicit assumption here that either you're using an IOMMU
> driver that always returns bus addresses that fit in a dma_addr_t, or
> you're not using an IOMMU and dma_addr_t is big enough for any bus address?
>
> What happens on a system with 64-bit PCI bus addresses, 32-bit dma_addr_t,
> and no IOMMU? Would this return failure somehow?
>
I think I see your point. Even if pci_map_resource() were changed to return
a pci_bus_addr_t, we would have the same problem again where the dma_addr_t
would either need to expand (a non-starter as already discussed) or replace
the return type of dma_map_resource() with something wider to accommodate,
or prevent such platforms from attempting to return a valid address that
will be truncated.
PCI devices on the platform in question (64-bit PCI bus addresses, 32-bit
dma_addr_t, and no IOMMU) should theoretically still be capable of PCI
peer-to-peer traffic, but would only be limited by the API, which we do not
want.
What about introducing another always-64-bit type, like peer_dma_addr_t,
for use with the new DMA APIs?
> > > +{
> > > + return dma_map_resource(hwdev == NULL ? NULL : &hwdev->dev, resource, offset, size, (enum dma_data_direction)direction);
> > > +}
> > > +
> > > +static inline void
> > > +pci_unmap_resource(struct pci_dev *hwdev, dma_addr_t dma_address, size_t size,
> > > + int direction)
> > > +{
> > > + dma_unmap_resource(hwdev == NULL ? NULL : &hwdev->dev, dma_address, size, (enum dma_data_direction)direction);
> > > +}
> > > +
> > > static inline int
> > > pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
> > > int nents, int direction)
> > > --
> > > 2.4.0
> > >
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
