search for: is_phys

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

As partiter doesn't deallocate itself after finish (anymore), it should be deleted after each loop iteration. diff --git a/com32/chain/chain.c b/com32/chain/chain.c index c08ec6e..f86cd7d 100644 --- a/com32/chain/chain.c +++ b/com32/chain/chain.c @@ -64,27 +64,23 @@ static int is_phys(uint8_t sdifs) static int find_by_sig(uint32_t mbr_sig, struct part_iter **_boot_part) { - struct part_iter *boot_part = NULL; + struct part_iter *iter = NULL; struct disk_info diskinfo; int drive; for (drive = 0x80; drive < 0x80 + fixed_cnt; drive++) { if (disk_ge...

...++++++++++++++ 3 files changed, 78 insertions(+) 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 st...

This patchset implements PVDMA for handling DMA requests from devices assigned to the guest from the host machine. They're also available from git-pull git://git.kernel.org/pub/scm/linux/kernel/git/amit/kvm.git pvdma These patches are based on my pci-passthrough tree, which is available from git-pull git://git.kernel.org/pub/scm/linux/kernel/git/amit/kvm.git and the userspace from

This patchset implements PVDMA for handling DMA requests from devices assigned to the guest from the host machine. They're also available from git-pull git://git.kernel.org/pub/scm/linux/kernel/git/amit/kvm.git pvdma These patches are based on my pci-passthrough tree, which is available from git-pull git://git.kernel.org/pub/scm/linux/kernel/git/amit/kvm.git and the userspace from

...3 files changed, 80 insertions(+), 1 deletion(-) 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 st...

...++++++++++++++ 3 files changed, 78 insertions(+) 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 st...

Andy, this is the next and hopefully last version. Seems to work fine when replacing the previous patches in your tree. I have some reviews/acks for patch 2 and 3. patch 1 still needs one ack. Can you replace the patches in your tree and carry them along with your changes? old introduction: ----- There are some attempts to unify the dma ops (Christoph) as well as some attempts to make virtio use

Andy, this is the next and hopefully last version. Seems to work fine when replacing the previous patches in your tree. I have some reviews/acks for patch 2 and 3. patch 1 still needs one ack. Can you replace the patches in your tree and carry them along with your changes? old introduction: ----- There are some attempts to unify the dma ops (Christoph) as well as some attempts to make virtio use

...tatic int __init dma_debug_do_init(void) } fs_initcall(dma_debug_do_init); -struct dma_map_ops s390_dma_ops = { +struct dma_map_ops s390_pci_dma_ops = { .alloc = s390_dma_alloc, .free = s390_dma_free, .map_sg = s390_dma_map_sg, @@ -506,7 +506,7 @@ struct dma_map_ops s390_dma_ops = { .is_phys = 0, /* dma_supported is unconditionally true without a callback */ }; -EXPORT_SYMBOL_GPL(s390_dma_ops); +EXPORT_SYMBOL_GPL(s390_pci_dma_ops); static int __init s390_iommu_setup(char *str) { -- 2.4.3

...tatic int __init dma_debug_do_init(void) } fs_initcall(dma_debug_do_init); -struct dma_map_ops s390_dma_ops = { +struct dma_map_ops s390_pci_dma_ops = { .alloc = s390_dma_alloc, .free = s390_dma_free, .map_sg = s390_dma_map_sg, @@ -506,7 +506,7 @@ struct dma_map_ops s390_dma_ops = { .is_phys = 0, /* dma_supported is unconditionally true without a callback */ }; -EXPORT_SYMBOL_GPL(s390_dma_ops); +EXPORT_SYMBOL_GPL(s390_pci_dma_ops); static int __init s390_iommu_setup(char *str) { -- 2.4.3

...tatic int __init dma_debug_do_init(void) } fs_initcall(dma_debug_do_init); -struct dma_map_ops s390_dma_ops = { +struct dma_map_ops s390_pci_dma_ops = { .alloc = s390_dma_alloc, .free = s390_dma_free, .map_sg = s390_dma_map_sg, @@ -555,7 +555,7 @@ struct dma_map_ops s390_dma_ops = { .is_phys = 0, /* dma_supported is unconditionally true without a callback */ }; -EXPORT_SYMBOL_GPL(s390_dma_ops); +EXPORT_SYMBOL_GPL(s390_pci_dma_ops); static int __init s390_iommu_setup(char *str) { -- 2.5.0

...tatic int __init dma_debug_do_init(void) } fs_initcall(dma_debug_do_init); -struct dma_map_ops s390_dma_ops = { +struct dma_map_ops s390_pci_dma_ops = { .alloc = s390_dma_alloc, .free = s390_dma_free, .map_sg = s390_dma_map_sg, @@ -506,7 +506,7 @@ struct dma_map_ops s390_dma_ops = { .is_phys = 0, /* dma_supported is unconditionally true without a callback */ }; -EXPORT_SYMBOL_GPL(s390_dma_ops); +EXPORT_SYMBOL_GPL(s390_pci_dma_ops); static int __init s390_iommu_setup(char *str) { -- 2.4.3

here is the 2nd version of providing an DMA API for s390. There are some attempts to unify the dma ops (Christoph) as well as some attempts to make virtio use the dma API (Andy). At kernel summit we concluded that we want to use the same code on all platforms, whereever possible, so having a dummy dma_op might be the easiest solution to keep virtio-ccw as similar as possible to

here is the 2nd version of providing an DMA API for s390. There are some attempts to unify the dma ops (Christoph) as well as some attempts to make virtio use the dma API (Andy). At kernel summit we concluded that we want to use the same code on all platforms, whereever possible, so having a dummy dma_op might be the easiest solution to keep virtio-ccw as similar as possible to

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