From: Christoph Hellwig <hch@lst.de>
To: iommu@lists.linux-foundation.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
Vladimir Murzin <vladimir.murzin@arm.com>,
linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org,
Takashi Iwai <tiwai@suse.de>,
linuxppc-dev@lists.ozlabs.org, Helge Deller <deller@gmx.de>,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-m68k@lists.linux-m68k.org,
Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/8] dma-mapping: move the dma_get_sgtable API comments from arm to common code
Date: Thu, 08 Aug 2019 15:59:59 +0000 [thread overview]
Message-ID: <20190808160005.10325-3-hch@lst.de> (raw)
In-Reply-To: <20190808160005.10325-1-hch@lst.de>
The comments are spot on and should be near the central API, not just
near a single implementation.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 11 -----------
kernel/dma/mapping.c | 11 +++++++++++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ad64d32fb39a..b4d65da76393 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -880,17 +880,6 @@ static void arm_coherent_dma_free(struct device *dev, size_t size, void *cpu_add
__arm_dma_free(dev, size, cpu_addr, handle, attrs, true);
}
-/*
- * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
- * that the intention is to allow exporting memory allocated via the
- * coherent DMA APIs through the dma_buf API, which only accepts a
- * scattertable. This presents a couple of problems:
- * 1. Not all memory allocated via the coherent DMA APIs is backed by
- * a struct page
- * 2. Passing coherent DMA memory into the streaming APIs is not allowed
- * as we will try to flush the memory through a different alias to that
- * actually being used (and the flushes are redundant.)
- */
int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t handle, size_t size,
unsigned long attrs)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 9c0f6a8eb5cb..41590d003465 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -136,6 +136,17 @@ int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
return ret;
}
+/*
+ * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
+ * that the intention is to allow exporting memory allocated via the
+ * coherent DMA APIs through the dma_buf API, which only accepts a
+ * scattertable. This presents a couple of problems:
+ * 1. Not all memory allocated via the coherent DMA APIs is backed by
+ * a struct page
+ * 2. Passing coherent DMA memory into the streaming APIs is not allowed
+ * as we will try to flush the memory through a different alias to that
+ * actually being used (and the flushes are redundant.)
+ */
int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
--
2.20.1
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: iommu@lists.linux-foundation.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Vladimir Murzin <vladimir.murzin@arm.com>,
Takashi Iwai <tiwai@suse.de>, Helge Deller <deller@gmx.de>,
Robin Murphy <robin.murphy@arm.com>,
Michal Simek <monstr@monstr.eu>,
linux-arm-kernel@lists.infradead.org,
linux-m68k@lists.linux-m68k.org, linux-parisc@vger.kernel.org,
linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org,
linuxppc-dev@lists.ozlabs.org, x86@kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 2/8] dma-mapping: move the dma_get_sgtable API comments from arm to common code
Date: Thu, 8 Aug 2019 18:59:59 +0300 [thread overview]
Message-ID: <20190808160005.10325-3-hch@lst.de> (raw)
In-Reply-To: <20190808160005.10325-1-hch@lst.de>
The comments are spot on and should be near the central API, not just
near a single implementation.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 11 -----------
kernel/dma/mapping.c | 11 +++++++++++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ad64d32fb39a..b4d65da76393 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -880,17 +880,6 @@ static void arm_coherent_dma_free(struct device *dev, size_t size, void *cpu_add
__arm_dma_free(dev, size, cpu_addr, handle, attrs, true);
}
-/*
- * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
- * that the intention is to allow exporting memory allocated via the
- * coherent DMA APIs through the dma_buf API, which only accepts a
- * scattertable. This presents a couple of problems:
- * 1. Not all memory allocated via the coherent DMA APIs is backed by
- * a struct page
- * 2. Passing coherent DMA memory into the streaming APIs is not allowed
- * as we will try to flush the memory through a different alias to that
- * actually being used (and the flushes are redundant.)
- */
int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t handle, size_t size,
unsigned long attrs)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 9c0f6a8eb5cb..41590d003465 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -136,6 +136,17 @@ int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
return ret;
}
+/*
+ * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
+ * that the intention is to allow exporting memory allocated via the
+ * coherent DMA APIs through the dma_buf API, which only accepts a
+ * scattertable. This presents a couple of problems:
+ * 1. Not all memory allocated via the coherent DMA APIs is backed by
+ * a struct page
+ * 2. Passing coherent DMA memory into the streaming APIs is not allowed
+ * as we will try to flush the memory through a different alias to that
+ * actually being used (and the flushes are redundant.)
+ */
int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
--
2.20.1
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: iommu@lists.linux-foundation.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
Vladimir Murzin <vladimir.murzin@arm.com>,
linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org,
Takashi Iwai <tiwai@suse.de>,
linuxppc-dev@lists.ozlabs.org, Helge Deller <deller@gmx.de>,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-m68k@lists.linux-m68k.org,
Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/8] dma-mapping: move the dma_get_sgtable API comments from arm to common code
Date: Thu, 8 Aug 2019 18:59:59 +0300 [thread overview]
Message-ID: <20190808160005.10325-3-hch@lst.de> (raw)
In-Reply-To: <20190808160005.10325-1-hch@lst.de>
The comments are spot on and should be near the central API, not just
near a single implementation.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 11 -----------
kernel/dma/mapping.c | 11 +++++++++++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ad64d32fb39a..b4d65da76393 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -880,17 +880,6 @@ static void arm_coherent_dma_free(struct device *dev, size_t size, void *cpu_add
__arm_dma_free(dev, size, cpu_addr, handle, attrs, true);
}
-/*
- * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
- * that the intention is to allow exporting memory allocated via the
- * coherent DMA APIs through the dma_buf API, which only accepts a
- * scattertable. This presents a couple of problems:
- * 1. Not all memory allocated via the coherent DMA APIs is backed by
- * a struct page
- * 2. Passing coherent DMA memory into the streaming APIs is not allowed
- * as we will try to flush the memory through a different alias to that
- * actually being used (and the flushes are redundant.)
- */
int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t handle, size_t size,
unsigned long attrs)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 9c0f6a8eb5cb..41590d003465 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -136,6 +136,17 @@ int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
return ret;
}
+/*
+ * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
+ * that the intention is to allow exporting memory allocated via the
+ * coherent DMA APIs through the dma_buf API, which only accepts a
+ * scattertable. This presents a couple of problems:
+ * 1. Not all memory allocated via the coherent DMA APIs is backed by
+ * a struct page
+ * 2. Passing coherent DMA memory into the streaming APIs is not allowed
+ * as we will try to flush the memory through a different alias to that
+ * actually being used (and the flushes are redundant.)
+ */
int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
--
2.20.1
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: iommu@lists.linux-foundation.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
Vladimir Murzin <vladimir.murzin@arm.com>,
linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org,
Takashi Iwai <tiwai@suse.de>,
linuxppc-dev@lists.ozlabs.org, Helge Deller <deller@gmx.de>,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-m68k@lists.linux-m68k.org,
Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/8] dma-mapping: move the dma_get_sgtable API comments from arm to common code
Date: Thu, 8 Aug 2019 18:59:59 +0300 [thread overview]
Message-ID: <20190808160005.10325-3-hch@lst.de> (raw)
In-Reply-To: <20190808160005.10325-1-hch@lst.de>
The comments are spot on and should be near the central API, not just
near a single implementation.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 11 -----------
kernel/dma/mapping.c | 11 +++++++++++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ad64d32fb39a..b4d65da76393 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -880,17 +880,6 @@ static void arm_coherent_dma_free(struct device *dev, size_t size, void *cpu_add
__arm_dma_free(dev, size, cpu_addr, handle, attrs, true);
}
-/*
- * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
- * that the intention is to allow exporting memory allocated via the
- * coherent DMA APIs through the dma_buf API, which only accepts a
- * scattertable. This presents a couple of problems:
- * 1. Not all memory allocated via the coherent DMA APIs is backed by
- * a struct page
- * 2. Passing coherent DMA memory into the streaming APIs is not allowed
- * as we will try to flush the memory through a different alias to that
- * actually being used (and the flushes are redundant.)
- */
int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t handle, size_t size,
unsigned long attrs)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 9c0f6a8eb5cb..41590d003465 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -136,6 +136,17 @@ int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
return ret;
}
+/*
+ * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
+ * that the intention is to allow exporting memory allocated via the
+ * coherent DMA APIs through the dma_buf API, which only accepts a
+ * scattertable. This presents a couple of problems:
+ * 1. Not all memory allocated via the coherent DMA APIs is backed by
+ * a struct page
+ * 2. Passing coherent DMA memory into the streaming APIs is not allowed
+ * as we will try to flush the memory through a different alias to that
+ * actually being used (and the flushes are redundant.)
+ */
int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
--
2.20.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: iommu@lists.linux-foundation.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
Vladimir Murzin <vladimir.murzin@arm.com>,
linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org,
Takashi Iwai <tiwai@suse.de>,
linuxppc-dev@lists.ozlabs.org, Helge Deller <deller@gmx.de>,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-m68k@lists.linux-m68k.org,
Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/8] dma-mapping: move the dma_get_sgtable API comments from arm to common code
Date: Thu, 8 Aug 2019 18:59:59 +0300 [thread overview]
Message-ID: <20190808160005.10325-3-hch@lst.de> (raw)
In-Reply-To: <20190808160005.10325-1-hch@lst.de>
The comments are spot on and should be near the central API, not just
near a single implementation.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 11 -----------
kernel/dma/mapping.c | 11 +++++++++++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ad64d32fb39a..b4d65da76393 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -880,17 +880,6 @@ static void arm_coherent_dma_free(struct device *dev, size_t size, void *cpu_add
__arm_dma_free(dev, size, cpu_addr, handle, attrs, true);
}
-/*
- * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
- * that the intention is to allow exporting memory allocated via the
- * coherent DMA APIs through the dma_buf API, which only accepts a
- * scattertable. This presents a couple of problems:
- * 1. Not all memory allocated via the coherent DMA APIs is backed by
- * a struct page
- * 2. Passing coherent DMA memory into the streaming APIs is not allowed
- * as we will try to flush the memory through a different alias to that
- * actually being used (and the flushes are redundant.)
- */
int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t handle, size_t size,
unsigned long attrs)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 9c0f6a8eb5cb..41590d003465 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -136,6 +136,17 @@ int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
return ret;
}
+/*
+ * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
+ * that the intention is to allow exporting memory allocated via the
+ * coherent DMA APIs through the dma_buf API, which only accepts a
+ * scattertable. This presents a couple of problems:
+ * 1. Not all memory allocated via the coherent DMA APIs is backed by
+ * a struct page
+ * 2. Passing coherent DMA memory into the streaming APIs is not allowed
+ * as we will try to flush the memory through a different alias to that
+ * actually being used (and the flushes are redundant.)
+ */
int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-08-08 15:59 UTC|newest]
Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-05 9:11 remove default fallbacks in dma_map_ops v2 Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` [PATCH 1/7] dma-mapping: move the dma_get_sgtable API comments from arm to common code Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` [PATCH 2/7] dma-mapping: explicitly wire up ->mmap and ->get_sgtable Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` [PATCH 3/7] dma-mapping: add a dma_can_mmap helper Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` [PATCH 5/7] m68knommu: add a pgprot_noncached stub Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` [PATCH 6/7] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` [PATCH 7/7] dma-mapping: provide a better default ->get_required_mask Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-08 15:59 ` remove default fallbacks in dma_map_ops v3 Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig
2019-08-08 15:59 ` [PATCH 1/8] dma-mapping: provide a better default ->get_required_mask Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig [this message]
2019-08-08 15:59 ` [PATCH 2/8] dma-mapping: move the dma_get_sgtable API comments from arm to common code Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig
2019-08-08 15:59 ` Christoph Hellwig
2019-08-08 16:00 ` [PATCH 3/8] dma-mapping: explicitly wire up ->mmap and ->get_sgtable Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` [PATCH 4/8] dma-mapping: add a dma_can_mmap helper Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` [PATCH 5/8] ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_* Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-11-04 7:26 ` youling257
2019-11-04 7:26 ` youling257
2019-11-04 7:26 ` youling257
2019-08-08 16:00 ` [PATCH 6/8] arm-nommu: call dma_mmap_from_dev_coherent directly Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-09 9:35 ` Sergei Shtylyov
2019-08-09 9:35 ` Sergei Shtylyov
2019-08-09 9:35 ` Sergei Shtylyov
2019-08-09 9:35 ` Sergei Shtylyov
2019-08-09 9:35 ` Sergei Shtylyov
2019-08-08 16:00 ` [PATCH 7/8] parisc: don't set ARCH_NO_COHERENT_DMA_MMAP Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-15 7:36 ` Christoph Hellwig
2019-08-15 7:36 ` Christoph Hellwig
2019-08-15 7:36 ` Christoph Hellwig
2019-08-15 7:36 ` Christoph Hellwig
2019-08-15 7:36 ` Christoph Hellwig
2019-08-15 9:25 ` James Bottomley
2019-08-15 9:25 ` James Bottomley
2019-08-15 9:25 ` James Bottomley
2019-08-15 9:25 ` James Bottomley
2019-08-15 9:25 ` James Bottomley
2019-08-15 10:50 ` Christoph Hellwig
2019-08-15 10:50 ` Christoph Hellwig
2019-08-15 10:50 ` Christoph Hellwig
2019-08-15 10:50 ` Christoph Hellwig
2019-08-15 10:50 ` Christoph Hellwig
2019-08-19 14:25 ` Christoph Hellwig
2019-08-19 14:25 ` Christoph Hellwig
2019-08-19 14:25 ` Christoph Hellwig
2019-08-19 14:25 ` Christoph Hellwig
2019-08-19 14:25 ` Christoph Hellwig
2019-08-08 16:00 ` [PATCH 8/8] dma-mapping: remove CONFIG_ARCH_NO_COHERENT_DMA_MMAP Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-08 16:00 ` Christoph Hellwig
2019-08-09 7:21 ` Geert Uytterhoeven
2019-08-09 7:21 ` Geert Uytterhoeven
2019-08-09 7:21 ` Geert Uytterhoeven
2019-08-09 7:21 ` Geert Uytterhoeven
2019-08-09 7:21 ` Geert Uytterhoeven
2019-08-29 15:38 ` remove default fallbacks in dma_map_ops v3 Christoph Hellwig
2019-08-29 15:38 ` Christoph Hellwig
2019-08-29 15:38 ` Christoph Hellwig
2019-08-29 15:38 ` Christoph Hellwig
2019-08-29 15:38 ` Christoph Hellwig
2019-08-05 9:11 [PATCH 4/7] ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_* Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:11 ` Christoph Hellwig
2019-08-05 9:22 ` Takashi Iwai
2019-08-05 9:22 ` Takashi Iwai
2019-08-05 9:22 ` Takashi Iwai
2019-08-05 9:22 ` Takashi Iwai
2019-08-05 9:22 ` Takashi Iwai
2019-08-06 5:29 ` Christoph Hellwig
2019-08-06 5:29 ` Christoph Hellwig
2019-08-06 5:29 ` Christoph Hellwig
2019-08-06 5:29 ` Christoph Hellwig
2019-08-06 5:29 ` Christoph Hellwig
2019-08-06 6:00 ` Takashi Iwai
2019-08-06 6:00 ` Takashi Iwai
2019-08-06 6:00 ` Takashi Iwai
2019-08-06 6:00 ` Takashi Iwai
2019-08-06 6:00 ` Takashi Iwai
2019-11-04 7:06 youling 257
2019-11-04 7:06 ` youling 257
2019-11-04 7:06 ` youling 257
2019-11-04 8:02 ` Takashi Iwai
2019-11-04 8:02 ` Takashi Iwai
2019-11-04 8:02 ` Takashi Iwai
2019-11-04 8:02 ` Takashi Iwai
2019-11-04 8:27 ` youling 257
2019-11-04 8:27 ` youling 257
2019-11-04 8:27 ` youling 257
2019-11-04 8:27 ` youling 257
2019-11-04 8:32 ` Greg Kroah-Hartman
2019-11-04 8:32 ` Greg Kroah-Hartman
2019-11-04 8:32 ` Greg Kroah-Hartman
2019-11-04 8:32 ` Greg Kroah-Hartman
2019-11-04 8:49 ` Greg Kroah-Hartman
2019-11-04 8:49 ` Greg Kroah-Hartman
2019-11-04 8:49 ` Greg Kroah-Hartman
2019-11-04 8:49 ` Greg Kroah-Hartman
2019-11-04 9:03 ` Takashi Iwai
2019-11-04 9:03 ` Takashi Iwai
2019-11-04 9:03 ` Takashi Iwai
2019-11-04 9:03 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190808160005.10325-3-hch@lst.de \
--to=hch@lst.de \
--cc=deller@gmx.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=m.szyprowski@samsung.com \
--cc=monstr@monstr.eu \
--cc=robin.murphy@arm.com \
--cc=tiwai@suse.de \
--cc=vladimir.murzin@arm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.