diff for duplicates of <54B970AD.7020407@arm.com>

diff --git a/a/1.txt b/N1/1.txt
index 48dc4b4..c897e8a 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -21,21 +21,21 @@ Thanks!
 
 >   And I have some questiones about the usage:
 >
-> 1) If we create a iommu domain by “arch_setup_dma_ops", then we would
+> 1) If we create a iommu domain by ?arch_setup_dma_ops", then we would
 > like to call the standard iommu interface, like
-> “iommu_set_fault_handle”,
-> How can we get the "struct iommu_domain *"? (the “dev_domain” is
+> ?iommu_set_fault_handle?,
+> How can we get the "struct iommu_domain *"? (the ?dev_domain? is
 > static.)
 >
-> 2) If a device A call “arch_setup_dma_ops” to create a iommu domain, and
+> 2) If a device A call ?arch_setup_dma_ops? to create a iommu domain, and
 > a client device B would like to join this iommu domain,
-> so it call “iommu_dma_attach_device”. then the device B want to alloc
-> the iommu memory, it call “dma_alloc_attrs” whose first parameter should
-> be the “struct device *”of device A. Is it designed like this in this
+> so it call ?iommu_dma_attach_device?. then the device B want to alloc
+> the iommu memory, it call ?dma_alloc_attrs? whose first parameter should
+> be the ?struct device *?of device A. Is it designed like this in this
 > patch?
->      (In arch/arm, “dev->archdata.dma_ops = &iommu_dma_ops” is in
-> “arm_iommu_attach_devce”;
->       In this patch, this sentence is in “arch_setup_dma_ops”).
+>      (In arch/arm, ?dev->archdata.dma_ops = &iommu_dma_ops? is in
+> ?arm_iommu_attach_devce?;
+>       In this patch, this sentence is in ?arch_setup_dma_ops?).
 >
 
 At this point there's not really any support for devices managing their 
@@ -73,9 +73,3 @@ dma-ranges values.
 Robin.
 
 [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/7556/focus=8237
-
-
-_______________________________________________
-iommu mailing list
-iommu@lists.linux-foundation.org
-https://lists.linuxfoundation.org/mailman/listinfo/iommu
diff --git a/a/content_digest b/N1/content_digest
index 7ab5008..9b58732 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,21 +2,10 @@
  "ref\01421136128.27675.58.camel@mtksdaap41\0"
  "ref\054B80857.7060407@arm.com\0"
  "ref\01421392892.19175.6.camel@mhfsdcap03\0"
- "From\0Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>\0"
- "Subject\0Re: [RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping\0"
+ "From\0robin.murphy@arm.com (Robin Murphy)\0"
+ "Subject\0[RFC PATCH 0/5] arm64: IOMMU-backed DMA mapping\0"
  "Date\0Fri, 16 Jan 2015 20:12:29 +0000\0"
- "To\0Yong Wu <yong.wu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>\0"
- "Cc\0linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>"
-  arnd-r2nGTMty4D4@public.gmane.org <arnd-r2nGTMty4D4@public.gmane.org>
-  stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org <stefano.stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
-  Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>
-  thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org <thunder.leizhen-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
-  Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>
-  iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
-  Yingjoe Chen <yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
-  eddie.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org <eddie.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
-  dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
- " linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On 16/01/15 07:21, Yong Wu wrote:\n"
@@ -42,21 +31,21 @@
  "\n"
  ">   And I have some questiones about the usage:\n"
  ">\n"
- "> 1) If we create a iommu domain by \342\200\234arch_setup_dma_ops\", then we would\n"
+ "> 1) If we create a iommu domain by ?arch_setup_dma_ops\", then we would\n"
  "> like to call the standard iommu interface, like\n"
- "> \342\200\234iommu_set_fault_handle\342\200\235,\n"
- "> How can we get the \"struct iommu_domain *\"? (the \342\200\234dev_domain\342\200\235 is\n"
+ "> ?iommu_set_fault_handle?,\n"
+ "> How can we get the \"struct iommu_domain *\"? (the ?dev_domain? is\n"
  "> static.)\n"
  ">\n"
- "> 2) If a device A call \342\200\234arch_setup_dma_ops\342\200\235 to create a iommu domain, and\n"
+ "> 2) If a device A call ?arch_setup_dma_ops? to create a iommu domain, and\n"
  "> a client device B would like to join this iommu domain,\n"
- "> so it call \342\200\234iommu_dma_attach_device\342\200\235. then the device B want to alloc\n"
- "> the iommu memory, it call \342\200\234dma_alloc_attrs\342\200\235 whose first parameter should\n"
- "> be the \342\200\234struct device *\342\200\235of device A. Is it designed like this in this\n"
+ "> so it call ?iommu_dma_attach_device?. then the device B want to alloc\n"
+ "> the iommu memory, it call ?dma_alloc_attrs? whose first parameter should\n"
+ "> be the ?struct device *?of device A. Is it designed like this in this\n"
  "> patch?\n"
- ">      (In arch/arm, \342\200\234dev->archdata.dma_ops = &iommu_dma_ops\342\200\235 is in\n"
- "> \342\200\234arm_iommu_attach_devce\342\200\235;\n"
- ">       In this patch, this sentence is in \342\200\234arch_setup_dma_ops\342\200\235).\n"
+ ">      (In arch/arm, ?dev->archdata.dma_ops = &iommu_dma_ops? is in\n"
+ "> ?arm_iommu_attach_devce?;\n"
+ ">       In this patch, this sentence is in ?arch_setup_dma_ops?).\n"
  ">\n"
  "\n"
  "At this point there's not really any support for devices managing their \n"
@@ -93,12 +82,6 @@
  "\n"
  "Robin.\n"
  "\n"
- "[1]:http://thread.gmane.org/gmane.linux.kernel.iommu/7556/focus=8237\n"
- "\n"
- "\n"
- "_______________________________________________\n"
- "iommu mailing list\n"
- "iommu@lists.linux-foundation.org\n"
- https://lists.linuxfoundation.org/mailman/listinfo/iommu
+ [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/7556/focus=8237
 
-7a848326fb9ef5f3a75f494b4980127c9b539b1adabe5074285747337d68a457
+841d1b886bca3d5a121b41f818bae3e53bdbfaaf15a98315045de6859de905c2
