diff for duplicates of <20181024173232.GB5652@bogus>

diff --git a/a/1.txt b/N1/1.txt
index cdf260f..deb79be 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -7,10 +7,10 @@ On Tue, Oct 23, 2018 at 10:05:40AM -0700, Paul Walmsley wrote:
 > > > > > Add DT binding documentation for the Linux driver for the SiFive
 > > > > > asynchronous serial IP block.  Nothing too exotic.
 > > > > > 
-> > > > > Cc: linux-serial at vger.kernel.org
-> > > > > Cc: devicetree at vger.kernel.org
-> > > > > Cc: linux-riscv at lists.infradead.org
-> > > > > Cc: linux-kernel at vger.kernel.org
+> > > > > Cc: linux-serial@vger.kernel.org
+> > > > > Cc: devicetree@vger.kernel.org
+> > > > > Cc: linux-riscv@lists.infradead.org
+> > > > > Cc: linux-kernel@vger.kernel.org
 > > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 > > > > > Cc: Rob Herring <robh+dt@kernel.org>
 > > > > > Cc: Mark Rutland <mark.rutland@arm.com>
@@ -52,9 +52,9 @@ On Tue, Oct 23, 2018 at 10:05:40AM -0700, Paul Walmsley wrote:
 > 
 > 
 > Seems like there might be some confusion between IP blocks as integrated on
-> an SoC vs. IP blocks in isolation.? It's not necessarily the SoC integrator
+> an SoC vs. IP blocks in isolation.  It's not necessarily the SoC integrator
 > that sets an IP block version number; this can come from the IP block vendor
-> itself.? So each IP block may have its own version numbering practices for
+> itself.  So each IP block may have its own version numbering practices for
 > the IP block alone.
 > 
 > 
@@ -65,13 +65,13 @@ I thought you had that from what Palmer said and what I've seen so far.
 You have at least 3 bindings so far it seems.
 
 > But other IP blocks from other vendors may not align to that, or may not
-> have version numbers exposed at all.? In those cases there's no way for
-> software folks to find out what they are,? as you pointed out earlier.? This
+> have version numbers exposed at all.  In those cases there's no way for
+> software folks to find out what they are,  as you pointed out earlier.  This
 > is the case with most DT compatible strings in the kernel tree.
 > 
 > For example, we've integrated the NVDLA IP block, from NVIDIA, on some
-> designs.? Any NVIDIA version numbers in that IP block will probably not
-> follow the SiFive version numbering scheme.? I'd propose the right thing to
+> designs.  Any NVIDIA version numbers in that IP block will probably not
+> follow the SiFive version numbering scheme.  I'd propose the right thing to
 > do for an IP block compatible string is to follow the vendor's practice, and
 > then use the SoC integrator's version numbering practice for the
 > SoC-integrated compatible string.
@@ -91,10 +91,10 @@ follows it.
 
 > In effect, an SoC integration DT compatible string like
 > "sifive,fu540-c000-uart" implicitly states an IP block version number:
-> "whatever came out of the fab on the chip"[**].?? I'd propose that even in
+> "whatever came out of the fab on the chip"[**].   I'd propose that even in
 > these cases, there's an advantage to keeping the "0" on the end, since it
 > uniquely identifies an SoC-independent IP block, rather than just the type
-> of the IP block. ? But if the "0" on the end of the SoC integration DT
+> of the IP block.   But if the "0" on the end of the SoC integration DT
 > compatible string is problematic for you, we can certainly drop that last 0
 > from the SoC integration DT compatible string, and only suffer a slight lack
 > of clarity as to what version was integrated on that chip.
@@ -106,15 +106,15 @@ to be the way you document for SiFive IP blocks.
 > can address your concern, at least for these public IP blocks. Since the
 > SiFive UART and some other peripheral IP blocks are open-source, the public
 > can have a pretty good idea of what DT version number corresponds to the
-> source RTL, since the RTL is public. ? The version number identifies a
+> source RTL, since the RTL is public.   The version number identifies a
 > specific programming model, without tying that programming model to any
-> SoC-specific workarounds, etc.? So for these cases, I think there's a pretty
+> SoC-specific workarounds, etc.  So for these cases, I think there's a pretty
 > good case for having IP block-specific version numbers in DT compatible
 > strings, and I hope you'll agree.
 > 
 > 
 > The advantage for all of us is that there's then no need to embed
-> chip-specific DT match strings in these drivers, for the most part.? We just
+> chip-specific DT match strings in these drivers, for the most part.  We just
 > match on "sifive,uart0" and that's it, assuming no chip-specific workarounds
 > are needed.
 > 
@@ -128,7 +128,7 @@ to be the way you document for SiFive IP blocks.
 > > I'm not going to go read your RTL, sorry.
 > 
 > 
-> There's no need, but you did ask where it came from.? Sorry you didn't like
+> There's no need, but you did ask where it came from.  Sorry you didn't like
 > the answer.
 
 I only meant that in context of reviewing the IP block. My questions 
@@ -145,15 +145,15 @@ were meant to be what questions should a common document answer.
 > 
 > ** The caveat is that even with SoC identifiers in the Linux DT compatible
 > strings, there's not enough information in many of the existing kernel DT
-> compatibility strings to uniquely identify chip versions.? Taking OMAP and
+> compatibility strings to uniquely identify chip versions.  Taking OMAP and
 > Tegra as examples, there are several different chip versions for a given SoC
-> generation that came out of the fab.? ? OMAP chip version strings usually
+> generation that came out of the fab.    OMAP chip version strings usually
 > began with "ES"; Tegra version numbers, as I recall, were a letter and two
-> numbers.? For the most part, those versions were never specifically
+> numbers.  For the most part, those versions were never specifically
 > identified in the upstream kernel DT strings or in DT file names. (There are
 > some exceptions with OMAP where we did identify specific chip version
 > numbers, because sizable numbers of folks had boards with early silicon, and
-> we were committed to supporting them at the time.)??? Sadly even adding
+> we were committed to supporting them at the time.)    Sadly even adding
 > these additional chip version identifiers to the DT strings wouldn't be
 > perfect: I've seen at least one large vendor implementing metal-only ECOs
 > without incrementing public chip version numbers. The point here is that
@@ -172,3 +172,8 @@ configuration information into registers. We only need DT for what we
 can't discover.
 
 Rob
+
+_______________________________________________
+linux-riscv mailing list
+linux-riscv@lists.infradead.org
+http://lists.infradead.org/mailman/listinfo/linux-riscv
diff --git a/a/content_digest b/N1/content_digest
index cb1fa26..5d9f3aa 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -4,10 +4,18 @@
  "ref\04317548d-f831-29ba-3be9-35f080587db9@sifive.com\0"
  "ref\0CAL_JsqLagTgjDhZ02X=wPFDB4WF2bR7=LyzSW9D=ooo_XB_zOg@mail.gmail.com\0"
  "ref\06571bb0e-b36a-1196-4d90-8aa62d8a2a90@sifive.com\0"
- "From\0robh@kernel.org (Rob Herring)\0"
- "Subject\0[PATCH v2 1/2] dt-bindings: serial: add documentation for the SiFive UART driver\0"
+ "From\0Rob Herring <robh@kernel.org>\0"
+ "Subject\0Re: [PATCH v2 1/2] dt-bindings: serial: add documentation for the SiFive UART driver\0"
  "Date\0Wed, 24 Oct 2018 12:32:32 -0500\0"
- "To\0linux-riscv@lists.infradead.org\0"
+ "To\0Paul Walmsley <paul.walmsley@sifive.com>\0"
+ "Cc\0Mark Rutland <mark.rutland@arm.com>"
+  devicetree@vger.kernel.org
+  Paul Walmsley <paul@pwsan.com>
+  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+  Palmer Dabbelt <palmer@sifive.com>
+  linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
+  open list:SERIAL DRIVERS <linux-serial@vger.kernel.org>
+ " linux-riscv@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On Tue, Oct 23, 2018 at 10:05:40AM -0700, Paul Walmsley wrote:\n"
@@ -19,10 +27,10 @@
  "> > > > > Add DT binding documentation for the Linux driver for the SiFive\n"
  "> > > > > asynchronous serial IP block.  Nothing too exotic.\n"
  "> > > > > \n"
- "> > > > > Cc: linux-serial at vger.kernel.org\n"
- "> > > > > Cc: devicetree at vger.kernel.org\n"
- "> > > > > Cc: linux-riscv at lists.infradead.org\n"
- "> > > > > Cc: linux-kernel at vger.kernel.org\n"
+ "> > > > > Cc: linux-serial@vger.kernel.org\n"
+ "> > > > > Cc: devicetree@vger.kernel.org\n"
+ "> > > > > Cc: linux-riscv@lists.infradead.org\n"
+ "> > > > > Cc: linux-kernel@vger.kernel.org\n"
  "> > > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\n"
  "> > > > > Cc: Rob Herring <robh+dt@kernel.org>\n"
  "> > > > > Cc: Mark Rutland <mark.rutland@arm.com>\n"
@@ -64,9 +72,9 @@
  "> \n"
  "> \n"
  "> Seems like there might be some confusion between IP blocks as integrated on\n"
- "> an SoC vs. IP blocks in isolation.? It's not necessarily the SoC integrator\n"
+ "> an SoC vs. IP blocks in isolation.\302\240 It's not necessarily the SoC integrator\n"
  "> that sets an IP block version number; this can come from the IP block vendor\n"
- "> itself.? So each IP block may have its own version numbering practices for\n"
+ "> itself.\302\240 So each IP block may have its own version numbering practices for\n"
  "> the IP block alone.\n"
  "> \n"
  "> \n"
@@ -77,13 +85,13 @@
  "You have at least 3 bindings so far it seems.\n"
  "\n"
  "> But other IP blocks from other vendors may not align to that, or may not\n"
- "> have version numbers exposed at all.? In those cases there's no way for\n"
- "> software folks to find out what they are,? as you pointed out earlier.? This\n"
+ "> have version numbers exposed at all.\302\240 In those cases there's no way for\n"
+ "> software folks to find out what they are,\302\240 as you pointed out earlier.\302\240 This\n"
  "> is the case with most DT compatible strings in the kernel tree.\n"
  "> \n"
  "> For example, we've integrated the NVDLA IP block, from NVIDIA, on some\n"
- "> designs.? Any NVIDIA version numbers in that IP block will probably not\n"
- "> follow the SiFive version numbering scheme.? I'd propose the right thing to\n"
+ "> designs.\302\240 Any NVIDIA version numbers in that IP block will probably not\n"
+ "> follow the SiFive version numbering scheme.\302\240 I'd propose the right thing to\n"
  "> do for an IP block compatible string is to follow the vendor's practice, and\n"
  "> then use the SoC integrator's version numbering practice for the\n"
  "> SoC-integrated compatible string.\n"
@@ -103,10 +111,10 @@
  "\n"
  "> In effect, an SoC integration DT compatible string like\n"
  "> \"sifive,fu540-c000-uart\" implicitly states an IP block version number:\n"
- "> \"whatever came out of the fab on the chip\"[**].?? I'd propose that even in\n"
+ "> \"whatever came out of the fab on the chip\"[**].\302\240\302\240 I'd propose that even in\n"
  "> these cases, there's an advantage to keeping the \"0\" on the end, since it\n"
  "> uniquely identifies an SoC-independent IP block, rather than just the type\n"
- "> of the IP block. ? But if the \"0\" on the end of the SoC integration DT\n"
+ "> of the IP block. \302\240 But if the \"0\" on the end of the SoC integration DT\n"
  "> compatible string is problematic for you, we can certainly drop that last 0\n"
  "> from the SoC integration DT compatible string, and only suffer a slight lack\n"
  "> of clarity as to what version was integrated on that chip.\n"
@@ -118,15 +126,15 @@
  "> can address your concern, at least for these public IP blocks. Since the\n"
  "> SiFive UART and some other peripheral IP blocks are open-source, the public\n"
  "> can have a pretty good idea of what DT version number corresponds to the\n"
- "> source RTL, since the RTL is public. ? The version number identifies a\n"
+ "> source RTL, since the RTL is public. \302\240 The version number identifies a\n"
  "> specific programming model, without tying that programming model to any\n"
- "> SoC-specific workarounds, etc.? So for these cases, I think there's a pretty\n"
+ "> SoC-specific workarounds, etc.\302\240 So for these cases, I think there's a pretty\n"
  "> good case for having IP block-specific version numbers in DT compatible\n"
  "> strings, and I hope you'll agree.\n"
  "> \n"
  "> \n"
  "> The advantage for all of us is that there's then no need to embed\n"
- "> chip-specific DT match strings in these drivers, for the most part.? We just\n"
+ "> chip-specific DT match strings in these drivers, for the most part.\302\240 We just\n"
  "> match on \"sifive,uart0\" and that's it, assuming no chip-specific workarounds\n"
  "> are needed.\n"
  "> \n"
@@ -140,7 +148,7 @@
  "> > I'm not going to go read your RTL, sorry.\n"
  "> \n"
  "> \n"
- "> There's no need, but you did ask where it came from.? Sorry you didn't like\n"
+ "> There's no need, but you did ask where it came from.\302\240 Sorry you didn't like\n"
  "> the answer.\n"
  "\n"
  "I only meant that in context of reviewing the IP block. My questions \n"
@@ -157,15 +165,15 @@
  "> \n"
  "> ** The caveat is that even with SoC identifiers in the Linux DT compatible\n"
  "> strings, there's not enough information in many of the existing kernel DT\n"
- "> compatibility strings to uniquely identify chip versions.? Taking OMAP and\n"
+ "> compatibility strings to uniquely identify chip versions.\302\240 Taking OMAP and\n"
  "> Tegra as examples, there are several different chip versions for a given SoC\n"
- "> generation that came out of the fab.? ? OMAP chip version strings usually\n"
+ "> generation that came out of the fab.\302\240 \302\240 OMAP chip version strings usually\n"
  "> began with \"ES\"; Tegra version numbers, as I recall, were a letter and two\n"
- "> numbers.? For the most part, those versions were never specifically\n"
+ "> numbers.\302\240 For the most part, those versions were never specifically\n"
  "> identified in the upstream kernel DT strings or in DT file names. (There are\n"
  "> some exceptions with OMAP where we did identify specific chip version\n"
  "> numbers, because sizable numbers of folks had boards with early silicon, and\n"
- "> we were committed to supporting them at the time.)??? Sadly even adding\n"
+ "> we were committed to supporting them at the time.)\302\240\302\240\302\240 Sadly even adding\n"
  "> these additional chip version identifiers to the DT strings wouldn't be\n"
  "> perfect: I've seen at least one large vendor implementing metal-only ECOs\n"
  "> without incrementing public chip version numbers. The point here is that\n"
@@ -183,6 +191,11 @@
  "configuration information into registers. We only need DT for what we \n"
  "can't discover.\n"
  "\n"
- Rob
+ "Rob\n"
+ "\n"
+ "_______________________________________________\n"
+ "linux-riscv mailing list\n"
+ "linux-riscv@lists.infradead.org\n"
+ http://lists.infradead.org/mailman/listinfo/linux-riscv
 
-8cebe043ecf931daf2e00dd42071b14c56b53478d96e3f294be09a313dd7c3d5
+cf60ec1abfe65f9e2e3d6811696dfc7634c3b776d78b14ee28ea3c1cb9c4f294
