diff for duplicates of <1748257.PI6hyOPu9L@diego>

diff --git a/a/1.txt b/N1/1.txt
index 836313c..6fa4b6c 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,4 +1,4 @@
-Am Mittwoch, 8. Juli 2015, 21:00:06 schrieb Heiko Stübner:
+Am Mittwoch, 8. Juli 2015, 21:00:06 schrieb Heiko St?bner:
 > Most newer Rockchip SoCs provide the possibility to use a usb-phy
 > as passthrough for the debug uart (uart2), making it possible to
 > get console output without needing to open the device.
@@ -21,10 +21,10 @@ dumping some thoughts that stem from comments in my g+ post about this:
 
 Arnd Bergmann, yesterday 19:40:
 Would it help to move this code into the console init section of the UART 
-driver to avoid losing the initial output?
+driver to avoid losing the initial output??
 
 
-Heiko Stübner, yesterday 20:08
+Heiko St?bner, yesterday 20:08
 I don't think so. The functionality has nothing to do with the uart itself - 
 in fact for the system everything stays the same - only the routing becomes 
 different. It should even work with earlyprintk/earlycon.
@@ -32,17 +32,17 @@ different. It should even work with earlyprintk/earlycon.
 The only output you loose is up to the point when the early_initcall is 
 executed - which is around the smp bringup time. And I guess if somebody is 
 doing kernel changes for this early stage, they will probably use a board with 
-a real uart or modify their uboot to already also set this option.
+a real uart or modify their uboot to already also set this option.?
 
 
 Arnd Bergmann, yesterday 20:52
 Isn't early_initcall /much/ later than console_init, or even earlycon?
 The console output gets buffered until the first console gets found and is then 
 flushed to that. If you switch the MUX just before registering the console, you 
-should not lose anything, and also put this code in a more natural location.
+should not lose anything, and also put this code in a more natural location.?
 
 
-Heiko Stübner, today 23:03
+Heiko St?bner, today 23:03
 Yep as I said, twi switch currently runs around the time of the smp bringup . 
 I'm probably just daft, but also still not sure how this should fit into the 
 uart driver/console stuff. Especially as it is not even a property of the 
@@ -59,10 +59,4 @@ somebody needs to touch (and debug) such low-low-level parts like before the
 smp bringup they won't do it on a board without a real serial port I guess.
 
 I guess we should also move this to a mailing list ... I guess I'll just copy 
-our thread here into a reply to my patch ;-) .
-
-
-_______________________________________________
-Linux-rockchip mailing list
-Linux-rockchip@lists.infradead.org
-http://lists.infradead.org/mailman/listinfo/linux-rockchip
+our thread here into a reply to my patch ;-) .?
diff --git a/a/content_digest b/N1/content_digest
index efc0eed..b6ee4fd 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,18 +1,11 @@
  "ref\01574322.mYky5df1dK@diego\0"
- "From\0Heiko St\303\274bner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>\0"
- "Subject\0Re: [PATCH] soc/rockchip: add handler for usb-uart functionality\0"
+ "From\0heiko@sntech.de (Heiko St\303\274bner)\0"
+ "Subject\0[PATCH] soc/rockchip: add handler for usb-uart functionality\0"
  "Date\0Fri, 10 Jul 2015 23:07:26 +0200\0"
- "To\0linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
- " Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>\0"
- "Cc\0amstan-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org"
-  Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
-  dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org
-  linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
-  Yunzhi Li <lyz-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
- " Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
- "Am Mittwoch, 8. Juli 2015, 21:00:06 schrieb Heiko St\303\274bner:\n"
+ "Am Mittwoch, 8. Juli 2015, 21:00:06 schrieb Heiko St?bner:\n"
  "> Most newer Rockchip SoCs provide the possibility to use a usb-phy\n"
  "> as passthrough for the debug uart (uart2), making it possible to\n"
  "> get console output without needing to open the device.\n"
@@ -35,10 +28,10 @@
  "\n"
  "Arnd Bergmann, yesterday 19:40:\n"
  "Would it help to move this code into the console init section of the UART \n"
- "driver to avoid losing the initial output?\357\273\277\n"
+ "driver to avoid losing the initial output??\n"
  "\n"
  "\n"
- "Heiko St\303\274bner, yesterday 20:08\n"
+ "Heiko St?bner, yesterday 20:08\n"
  "I don't think so. The functionality has nothing to do with the uart itself - \n"
  "in fact for the system everything stays the same - only the routing becomes \n"
  "different. It should even work with earlyprintk/earlycon.\n"
@@ -46,17 +39,17 @@
  "The only output you loose is up to the point when the early_initcall is \n"
  "executed - which is around the smp bringup time. And I guess if somebody is \n"
  "doing kernel changes for this early stage, they will probably use a board with \n"
- "a real uart or modify their uboot to already also set this option.\357\273\277\n"
+ "a real uart or modify their uboot to already also set this option.?\n"
  "\n"
  "\n"
  "Arnd Bergmann, yesterday 20:52\n"
  "Isn't early_initcall /much/ later than console_init, or even earlycon?\n"
  "The console output gets buffered until the first console gets found and is then \n"
  "flushed to that. If you switch the MUX just before registering the console, you \n"
- "should not lose anything, and also put this code in a more natural location.\357\273\277\n"
+ "should not lose anything, and also put this code in a more natural location.?\n"
  "\n"
  "\n"
- "Heiko St\303\274bner, today 23:03\n"
+ "Heiko St?bner, today 23:03\n"
  "Yep as I said, twi switch currently runs around the time of the smp bringup . \n"
  "I'm probably just daft, but also still not sure how this should fit into the \n"
  "uart driver/console stuff. Especially as it is not even a property of the \n"
@@ -73,12 +66,6 @@
  "smp bringup they won't do it on a board without a real serial port I guess.\n"
  "\n"
  "I guess we should also move this to a mailing list ... I guess I'll just copy \n"
- "our thread here into a reply to my patch ;-) .\357\273\277\n"
- "\n"
- "\n"
- "_______________________________________________\n"
- "Linux-rockchip mailing list\n"
- "Linux-rockchip@lists.infradead.org\n"
- http://lists.infradead.org/mailman/listinfo/linux-rockchip
+ our thread here into a reply to my patch ;-) .?
 
-a45a0dd907ad6a23a5fc768b0f06792f2c35643c951a56edcc2237188cf5208a
+db071e6326ff0ec425214ec79badef4c0d0813d5d3645f1c88060951d3cdd283
