search for: dma_noop_op

We'll need a bit of a wieder audience for this I think.. On Wed, Dec 07, 2016 at 05:11:28PM -0800, Bart Van Assche wrote: > Additionally, introduce set_dma_ops(). A later patch will introduce a > call to that function in the RDMA drivers that will be modified to use > dma_noop_ops. This looks good to me, and we had a lot of talk about this for other purposes for a while.

We'll need a bit of a wieder audience for this I think.. On Wed, Dec 07, 2016 at 05:11:28PM -0800, Bart Van Assche wrote: > Additionally, introduce set_dma_ops(). A later patch will introduce a > call to that function in the RDMA drivers that will be modified to use > dma_noop_ops. This looks good to me, and we had a lot of talk about this for other purposes for a while.

...ions(+) create mode 100644 lib/dma-noop.c diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index ac07ff0..7912f54 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -66,6 +66,8 @@ struct dma_map_ops { int is_phys; }; +extern struct dma_map_ops dma_noop_ops; + #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) #define DMA_MASK_NONE 0x0ULL diff --git a/lib/Makefile b/lib/Makefile index 13a7c6a..92d6135 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -18,6 +18,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ obj-$(CONFIG_AR...

...tion(-) create mode 100644 lib/dma-noop.c diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index ac07ff0..7912f54 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -66,6 +66,8 @@ struct dma_map_ops { int is_phys; }; +extern struct dma_map_ops dma_noop_ops; + #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) #define DMA_MASK_NONE 0x0ULL diff --git a/lib/Makefile b/lib/Makefile index 13a7c6a..b04ba71 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -13,7 +13,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ sha1.o md5.o...

...ions(+) create mode 100644 lib/dma-noop.c diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index ac07ff0..7912f54 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -66,6 +66,8 @@ struct dma_map_ops { int is_phys; }; +extern struct dma_map_ops dma_noop_ops; + #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) #define DMA_MASK_NONE 0x0ULL diff --git a/lib/Makefile b/lib/Makefile index 13a7c6a..92d6135 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -18,6 +18,7 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ obj-$(CONFIG_AR...

...ms to work. We will also need a fixup for powerc and QEMU changes to make virtio work with iommu on power and x86. TODO: - future add-on patches to also fold in x86 no iommu - dma_mask - checking? - make compilation of dma-noop dependent on something v1->v2: - initial testing - always use dma_noop_ops if device has no private dma_ops - get rid of setup in virtio_ccw,kvm_virtio - set CONFIG_HAS_DMA(ATTRS) for virtio (fixes compile for !PCI) - rename s390_dma_ops to s390_pci_dma_ops Christian Borntraeger (3): Provide simple noop dma ops alpha: use common noop dma ops s390/dma: Allow per de...

...ms to work. We will also need a fixup for powerc and QEMU changes to make virtio work with iommu on power and x86. TODO: - future add-on patches to also fold in x86 no iommu - dma_mask - checking? - make compilation of dma-noop dependent on something v1->v2: - initial testing - always use dma_noop_ops if device has no private dma_ops - get rid of setup in virtio_ccw,kvm_virtio - set CONFIG_HAS_DMA(ATTRS) for virtio (fixes compile for !PCI) - rename s390_dma_ops to s390_pci_dma_ops Christian Borntraeger (3): Provide simple noop dma ops alpha: use common noop dma ops s390/dma: Allow per de...

...set from Andy Lutomirski this seems to work. We will also need a fixup for powerc and QEMU changes to make virtio work with iommu on power and x86. ---- v2->v3: - make dma-noop depend on HAS_DMA - do not do memset on alloc - prefix patches with *dma* v1->v2: - initial testing - always use dma_noop_ops if device has no private dma_ops - get rid of setup in virtio_ccw,kvm_virtio - set CONFIG_HAS_DMA(ATTRS) for virtio (fixes compile for !PCI) - rename s390_dma_ops to s390_pci_dma_ops Christian Borntraeger (3): dma: Provide simple noop dma ops alpha/dma: use common noop dma ops s390/dma: Al...

...set from Andy Lutomirski this seems to work. We will also need a fixup for powerc and QEMU changes to make virtio work with iommu on power and x86. ---- v2->v3: - make dma-noop depend on HAS_DMA - do not do memset on alloc - prefix patches with *dma* v1->v2: - initial testing - always use dma_noop_ops if device has no private dma_ops - get rid of setup in virtio_ccw,kvm_virtio - set CONFIG_HAS_DMA(ATTRS) for virtio (fixes compile for !PCI) - rename s390_dma_ops to s390_pci_dma_ops Christian Borntraeger (3): dma: Provide simple noop dma ops alpha/dma: use common noop dma ops s390/dma: Al...

Andy, to make it obvious which version is the latest, here is a branch The following changes since commit 6a13feb9c82803e2b815eca72fa7a9f5561d7861: Linux 4.3 (2015-11-01 16:05:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git dma for you to fetch changes up to fc7f9754db6ce0c12281da4055281f731d36bdee: s390/dma: Allow

Andy, to make it obvious which version is the latest, here is a branch The following changes since commit 6a13feb9c82803e2b815eca72fa7a9f5561d7861: Linux 4.3 (2015-11-01 16:05:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git dma for you to fetch changes up to fc7f9754db6ce0c12281da4055281f731d36bdee: s390/dma: Allow

...l need a bit of a wieder audience for this I think.. > > On Wed, Dec 07, 2016 at 05:11:28PM -0800, Bart Van Assche wrote: > > Additionally, introduce set_dma_ops(). A later patch will introduce a > > call to that function in the RDMA drivers that will be modified to use > > dma_noop_ops. > > This looks good to me, and we had a lot of talk about this for other > purposes for a while. Hm, I'm not convinced we want per-device dma_ops. What we want is per- device IOMMU ops, and any dma_ops are just a generic or platform- specific (in some cases) wrapper around those....

...a_addr_t) 0x0) -extern struct dma_map_ops s390_dma_ops; +extern struct dma_map_ops s390_pci_dma_ops; static inline struct dma_map_ops *get_dma_ops(struct device *dev) { - return &s390_dma_ops; + if (dev && dev->archdata.dma_ops) + return dev->archdata.dma_ops; + return &dma_noop_ops; } static inline void dma_cache_sync(struct device *dev, void *vaddr, size_t size, diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c index 7ef12a3..fa41605 100644 --- a/arch/s390/pci/pci.c +++ b/arch/s390/pci/pci.c @@ -649,6 +649,7 @@ int pcibios_add_device(struct pci_dev *pdev) zdev-...

...a_addr_t) 0x0) -extern struct dma_map_ops s390_dma_ops; +extern struct dma_map_ops s390_pci_dma_ops; static inline struct dma_map_ops *get_dma_ops(struct device *dev) { - return &s390_dma_ops; + if (dev && dev->archdata.dma_ops) + return dev->archdata.dma_ops; + return &dma_noop_ops; } static inline void dma_cache_sync(struct device *dev, void *vaddr, size_t size, diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c index 7ef12a3..fa41605 100644 --- a/arch/s390/pci/pci.c +++ b/arch/s390/pci/pci.c @@ -649,6 +649,7 @@ int pcibios_add_device(struct pci_dev *pdev) zdev-...

...a_addr_t) 0x0) -extern struct dma_map_ops s390_dma_ops; +extern struct dma_map_ops s390_pci_dma_ops; static inline struct dma_map_ops *get_dma_ops(struct device *dev) { - return &s390_dma_ops; + if (dev && dev->archdata.dma_ops) + return dev->archdata.dma_ops; + return &dma_noop_ops; } static inline void dma_cache_sync(struct device *dev, void *vaddr, size_t size, diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c index 11d4f277e9f6..f5931135b9ae 100644 --- a/arch/s390/pci/pci.c +++ b/arch/s390/pci/pci.c @@ -649,6 +649,7 @@ int pcibios_add_device(struct pci_dev *pdev)...

...a_addr_t) 0x0) -extern struct dma_map_ops s390_dma_ops; +extern struct dma_map_ops s390_pci_dma_ops; static inline struct dma_map_ops *get_dma_ops(struct device *dev) { - return &s390_dma_ops; + if (dev && dev->archdata.dma_ops) + return dev->archdata.dma_ops; + return &dma_noop_ops; } static inline void dma_cache_sync(struct device *dev, void *vaddr, size_t size, diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c index 7ef12a3..fa41605 100644 --- a/arch/s390/pci/pci.c +++ b/arch/s390/pci/pci.c @@ -649,6 +649,7 @@ int pcibios_add_device(struct pci_dev *pdev) zdev-...

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too