diff for duplicates of <1472839879.2754.77.camel@linux.intel.com>

diff --git a/a/1.txt b/N1/1.txt
index 8ae45ca..a70592a 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -2,15 +2,15 @@
 > > > 
 > > > 
 > > > > 
-> > > > +?????/*
-> > > > +??????* By default, allow up to 25ms of APST-induced
-> > > > latency.??This will
-> > > > +??????* have no effect on non-APST supporting controllers
+> > > > +     /*
+> > > > +      * By default, allow up to 25ms of APST-induced
+> > > > latency.  This will
+> > > > +      * have no effect on non-APST supporting controllers
 > > > > (i.e.
 > > > > any
-> > > > +??????* controller with APSTA == 0).
-> > > > +??????*/
-> > > > +?????ctrl->apst_max_latency_ns = 25000000;
+> > > > +      * controller with APSTA == 0).
+> > > > +      */
+> > > > +     ctrl->apst_max_latency_ns = 25000000;
 > > > 
 > > > Is it possible to make that a #define please?
 > > 
@@ -18,14 +18,14 @@
 > 
 > One question, though: should we call this and the sysfs parameter
 > apst_max_latency or should it be more generically
-> power_save_max_latency???The idea is that we might want to support
-> non-automonous transitions some day or even runtime D3.??Or maybe
+> power_save_max_latency?  The idea is that we might want to support
+> non-automonous transitions some day or even runtime D3.  Or maybe
 > those should be separately configured if used.
 
-I read the spec and reviewed your latest patchset. ?Personally for me I
+I read the spec and reviewed your latest patchset.  Personally for me I
 like having the field names from the NVMe spec in the names of the
 Linux implementation because it makes it easier to find and relate the
-two. ?So apst_max_latency makes more sense to me, as this is a
+two.  So apst_max_latency makes more sense to me, as this is a
 'apst'(e/a) NVMe feature.
 
 > 
@@ -33,5 +33,5 @@ two. ?So apst_max_latency makes more sense to me, as this is a
 > 
 > _______________________________________________
 > Linux-nvme mailing list
-> Linux-nvme at lists.infradead.org
+> Linux-nvme@lists.infradead.org
 > http://lists.infradead.org/mailman/listinfo/linux-nvme
diff --git a/a/content_digest b/N1/content_digest
index e723d56..95041be 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -3,24 +3,30 @@
  "ref\01472483266.2816.14.camel@linux.intel.com\0"
  "ref\0CALCETrXu8oOnc9R=_Bt8f6c=eGAJ0ZwbUL5xCUsu5zWR_ZzSKA@mail.gmail.com\0"
  "ref\0CALCETrUFRhNTamd-u_K+KTowN9S8WJKgreUQ4mfxmfx5v8zSPQ@mail.gmail.com\0"
- "From\0james_p_freyensee@linux.intel.com (J Freyensee)\0"
- "Subject\0[PATCH 3/3] nvme: Enable autonomous power state transitions\0"
+ "From\0J Freyensee <james_p_freyensee@linux.intel.com>\0"
+ "Subject\0Re: [PATCH 3/3] nvme: Enable autonomous power state transitions\0"
  "Date\0Fri, 02 Sep 2016 11:11:19 -0700\0"
+ "To\0Andy Lutomirski <luto@amacapital.net>\0"
+ "Cc\0Keith Busch <keith.busch@intel.com>"
+  Jens Axboe <axboe@fb.com>
+  Christoph Hellwig <hch@lst.de>
+  linux-nvme@lists.infradead.org
+ " linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>\0"
  "\00:1\0"
  "b\0"
  "\n"
  "> > > \n"
  "> > > \n"
  "> > > > \n"
- "> > > > +?????/*\n"
- "> > > > +??????* By default, allow up to 25ms of APST-induced\n"
- "> > > > latency.??This will\n"
- "> > > > +??????* have no effect on non-APST supporting controllers\n"
+ "> > > > +\302\240\302\240\302\240\302\240\302\240/*\n"
+ "> > > > +\302\240\302\240\302\240\302\240\302\240\302\240* By default, allow up to 25ms of APST-induced\n"
+ "> > > > latency.\302\240\302\240This will\n"
+ "> > > > +\302\240\302\240\302\240\302\240\302\240\302\240* have no effect on non-APST supporting controllers\n"
  "> > > > (i.e.\n"
  "> > > > any\n"
- "> > > > +??????* controller with APSTA == 0).\n"
- "> > > > +??????*/\n"
- "> > > > +?????ctrl->apst_max_latency_ns = 25000000;\n"
+ "> > > > +\302\240\302\240\302\240\302\240\302\240\302\240* controller with APSTA == 0).\n"
+ "> > > > +\302\240\302\240\302\240\302\240\302\240\302\240*/\n"
+ "> > > > +\302\240\302\240\302\240\302\240\302\240ctrl->apst_max_latency_ns = 25000000;\n"
  "> > > \n"
  "> > > Is it possible to make that a #define please?\n"
  "> > \n"
@@ -28,14 +34,14 @@
  "> \n"
  "> One question, though: should we call this and the sysfs parameter\n"
  "> apst_max_latency or should it be more generically\n"
- "> power_save_max_latency???The idea is that we might want to support\n"
- "> non-automonous transitions some day or even runtime D3.??Or maybe\n"
+ "> power_save_max_latency?\302\240\302\240The idea is that we might want to support\n"
+ "> non-automonous transitions some day or even runtime D3.\302\240\302\240Or maybe\n"
  "> those should be separately configured if used.\n"
  "\n"
- "I read the spec and reviewed your latest patchset. ?Personally for me I\n"
+ "I read the spec and reviewed your latest patchset. \302\240Personally for me I\n"
  "like having the field names from the NVMe spec in the names of the\n"
  "Linux implementation because it makes it easier to find and relate the\n"
- "two. ?So apst_max_latency makes more sense to me, as this is a\n"
+ "two. \302\240So apst_max_latency makes more sense to me, as this is a\n"
  "'apst'(e/a) NVMe feature.\n"
  "\n"
  "> \n"
@@ -43,7 +49,7 @@
  "> \n"
  "> _______________________________________________\n"
  "> Linux-nvme mailing list\n"
- "> Linux-nvme at lists.infradead.org\n"
+ "> Linux-nvme@lists.infradead.org\n"
  > http://lists.infradead.org/mailman/listinfo/linux-nvme
 
-0cb9840f2dfbb88a2fc0df15f4f6177bc7b2f84dd9feace1fe60913dca0ca976
+3f1e5fe9b684c14b6f684572b7ada34dabc4220dd30366c92189cf3805964103
