diff for duplicates of <20150724034229.642.88156@quantum>

diff --git a/a/1.txt b/N1/1.txt
index 7fded37..73f8c97 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,9 +1,7 @@
 Quoting Paul Osmialowski (2015-07-04 14:50:03)
 > Hi Arnd,
-> =
-
-> I'm attaching excerpt from Kinetis reference manual that may make =
-
+> 
+> I'm attaching excerpt from Kinetis reference manual that may make 
 > situation clearer.
 
 Hi Paul,
@@ -17,23 +15,15 @@ clk: mcg and sim clock drivers for twr-k70f120m Kinetis SoC
 At least it helps me find the patch I care about when skimming the
 series ;-)
 
-> =
-
-> These MCG and SIM registers are used only to determine configuration =
-
+> 
+> These MCG and SIM registers are used only to determine configuration 
 > (clock fixed rates and clock signal origins) at run time.
-> =
-
-> Namely, the real MCGOUTCLK source (in the middle) which is the parent for =
-
-> core clock (CCLK) and peripheral clock (PCLK) is determined at run time b=
-y =
-
+> 
+> Namely, the real MCGOUTCLK source (in the middle) which is the parent for 
+> core clock (CCLK) and peripheral clock (PCLK) is determined at run time by 
 > reading MCG registers, let me quote commit message from Emcraft git repo:
-> =
-
->       * Determine in run-time what oscillator module (OSC0 or OSC1) is us=
-ed
+> 
+>       * Determine in run-time what oscillator module (OSC0 or OSC1) is used
 >      as clock source for the main PLL.
 
 According to [0] there are three options: a 32k RTC osc clock and osc0
@@ -43,16 +33,11 @@ fixed-rate binding.
 >       * When OSC1 is selected, assume its frequency to be 12 MHz on all
 >      boards (there is a 12 MHz oscillator on XTAL1/EXTAL1 on K70-SOM and
 >      TWR-K70F120M boards).
-> =
-
-> In my .dts I'm trying to possibly follow real clock hierarchy, but to go =
-
-> anywhere behind MCGOUTCLK would require ability to rewrite .dtb e.g. by =
-
-> U-boot. But that's too demanding for any potential users of this BSP. So =
-
-> let's asume that MCGOUTCLK is the root clock and a parent for CCLK and =
-
+> 
+> In my .dts I'm trying to possibly follow real clock hierarchy, but to go 
+> anywhere behind MCGOUTCLK would require ability to rewrite .dtb e.g. by 
+> U-boot. But that's too demanding for any potential users of this BSP. So 
+> let's asume that MCGOUTCLK is the root clock and a parent for CCLK and 
 > PCLK.
 
 I'm confused. The point of device tree is to solve problems like this;
@@ -78,47 +63,46 @@ Below is what your binding/dts should look like:
 
 {
 	osc0: clock {
-		compatible =3D "fixed-clock";
-		#clock-cells =3D <0>;
-		clock-frequency =3D <50000000>;
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <50000000>;
 	};
 
 	osc1: clock {
-		compatible =3D "fixed-clock";
-		#clock-cells =3D <0>;
-		clock-frequency =3D <12000000>;
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <12000000>;
 	};
 
 	rtc: clock {
-		compatible =3D "fixed-clock";
-		#clock-cells =3D <0>;
-		clock-frequency =3D <32768>;
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
 	};
 
 	soc: soc {
 		mcg: clock-controller@40064000 {
-			compatible =3D "fsl,kinetis-mcg";
-			clock-cells =3D <1>;
-			reg =3D <0x40064000 0x14>;
-			clocks =3D <&osc0>, <&osc1>, <&rtc>;
-			clock-names =3D "osc0", "osc1", "rtc";
+			compatible = "fsl,kinetis-mcg";
+			clock-cells = <1>;
+			reg = <0x40064000 0x14>;
+			clocks = <&osc0>, <&osc1>, <&rtc>;
+			clock-names = "osc0", "osc1", "rtc";
 		};
 
 		sim: clock-controller@40047000 {
-			compatible =3D "fsl,kinetis-sim";
-			clock-cells =3D <1>;
-			reg =3D <0x40047000 0x1100>;
-			clocks =3D <&mcg MCG_MCGOUTCLK_DIV1>, <&mcg MCG_MCGOUTCLK_DIV2>, <&mcg M=
-CG_MCGOUTCLK_DIV3> <&mcg MCG_MCGOUTCLK_DIV4>;
-			clock-names =3D "core", "bus", "flexbus", "flash";
+			compatible = "fsl,kinetis-sim";
+			clock-cells = <1>;
+			reg = <0x40047000 0x1100>;
+			clocks = <&mcg MCG_MCGOUTCLK_DIV1>, <&mcg MCG_MCGOUTCLK_DIV2>, <&mcg MCG_MCGOUTCLK_DIV3> <&mcg MCG_MCGOUTCLK_DIV4>;
+			clock-names = "core", "bus", "flexbus", "flash";
 		};
 	};
 
 	uart0: serial@4006a000 {
-		compatible =3D "fsl,kinetis-lpuart";
-		reg =3D <0x4006a000 0x1000>;
-		clocks =3D <&sim SIM_SCGC4_UART1_CLK>;
-		clock-names =3D "gate";
+		compatible = "fsl,kinetis-lpuart";
+		reg = <0x4006a000 0x1000>;
+		clocks = <&sim SIM_SCGC4_UART1_CLK>;
+		clock-names = "gate";
 	};
 
 I removed the interrupts and dma stuff from the uart0 node for clarity.
@@ -143,26 +127,19 @@ I think this means you can also get rid of kinetis_of_clk_get_name and
 kinetis_clk_gate_get but my brain is tired so I'll leave that as an
 exercise to the reader.
 
-[0] http://cache.freescale.com/files/microcontrollers/doc/ref_manual/K70P25=
-6M150SF3RM.pdf
+[0] http://cache.freescale.com/files/microcontrollers/doc/ref_manual/K70P256M150SF3RM.pdf
 
 Regards,
 Mike
 
-> =
-
-> In my most recent version I added OSC0ERCLK explicitly as one more root =
-
-> clock, since it is also used directly (through CG reg. 1 bit 0) by =
-
-> Freescale fec network device whose in-tree driver I'm trying to make =
-
+> 
+> In my most recent version I added OSC0ERCLK explicitly as one more root 
+> clock, since it is also used directly (through CG reg. 1 bit 0) by 
+> Freescale fec network device whose in-tree driver I'm trying to make 
 > usable for Kinetis.
-> =
-
+> 
 > On Sat, 4 Jul 2015, Arnd Bergmann wrote:
-> =
-
+> 
 > > On Friday 03 July 2015 00:08:27 Thomas Gleixner wrote:
 > >> On Thu, 2 Jul 2015, Paul Osmialowski wrote:
 > >>> On Thu, 2 Jul 2015, Arnd Bergmann wrote:
@@ -172,8 +149,7 @@ Mike
 > >>>> just fixed, you can use the normal binding for fixed rate clocks
 > >>>> and only describe the clocks that are related to the driver.
 > >>>
-> >>> In my view having these clocks grouped together looks more convincing=
-. After
+> >>> In my view having these clocks grouped together looks more convincing. After
 > >>> all, they all share the same I/O regs in order to read configuration.
 > >>
 > >> The fact that they share a register is not making them a group. That's
@@ -182,19 +158,16 @@ Mike
 > >> the functional level.
 > >
 > > I'd disagree with that: The clock controller is the device that owns the
-> > registers and that should be one node in DT, as Paul's first version do=
-es.
+> > registers and that should be one node in DT, as Paul's first version does.
 > >
 > > The part I'm still struggling with is understanding how the fixed-rate
-> > clocks are controlled through those registers. If they are indeed confi=
-gured
+> > clocks are controlled through those registers. If they are indeed configured
 > > through the registers, the name is probably wrong and should be changed
 > > to whatever kind of non-fixed clock this is.
 > >
 > >       Arnd
 > >
-> =
-
+> 
 > _______________________________________________
 > linux-arm-kernel mailing list
 > linux-arm-kernel@lists.infradead.org
diff --git a/a/content_digest b/N1/content_digest
index 9c5a70c..4cb0df0 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,8 +6,7 @@
  "From\0Michael Turquette <mturquette@baylibre.com>\0"
  "Subject\0Re: [PATCH v2 3/9] arm: twr-k70f120m: clock driver for Kinetis SoC\0"
  "Date\0Thu, 23 Jul 2015 20:42:29 -0700\0"
- "To\0Paul Osmialowski <pawelo@king.net.pl>"
- " Arnd Bergmann <arnd@arndb.de>\0"
+ "To\0Arnd Bergmann <arnd@arndb.de>\0"
  "Cc\0Mark Rutland <mark.rutland@arm.com>"
   Nicolas Pitre <nicolas.pitre@linaro.org>
   Linus Walleij <linus.walleij@linaro.org>
@@ -30,23 +29,13 @@
   Yuri Tikhonov <yur@emcraft.com>
   linux-gpio@vger.kernel.org
   Rob Herring <robh+dt@kernel.org>
-  Thomas Gleixner <tglx@linutronix.de>
-  linux-arm-kernel@lists.infradead.org
-  Sergei Poselenov <sposelenov@emcraft.com>
-  Paul Bolle <pebolle@tiscali.nl>
-  Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-  Stephen Boyd <sboyd@codeaurora.org>
-  linux-kernel@vger.kernel.org
-  Jingchang Lu <jingchang.lu@freescale.com>
- " dmaengine@vger.kernel.org\0"
+ " Thomas Gleixner <tglx@linutronix.>\0"
  "\00:1\0"
  "b\0"
  "Quoting Paul Osmialowski (2015-07-04 14:50:03)\n"
  "> Hi Arnd,\n"
- "> =\n"
- "\n"
- "> I'm attaching excerpt from Kinetis reference manual that may make =\n"
- "\n"
+ "> \n"
+ "> I'm attaching excerpt from Kinetis reference manual that may make \n"
  "> situation clearer.\n"
  "\n"
  "Hi Paul,\n"
@@ -60,23 +49,15 @@
  "At least it helps me find the patch I care about when skimming the\n"
  "series ;-)\n"
  "\n"
- "> =\n"
- "\n"
- "> These MCG and SIM registers are used only to determine configuration =\n"
- "\n"
+ "> \n"
+ "> These MCG and SIM registers are used only to determine configuration \n"
  "> (clock fixed rates and clock signal origins) at run time.\n"
- "> =\n"
- "\n"
- "> Namely, the real MCGOUTCLK source (in the middle) which is the parent for =\n"
- "\n"
- "> core clock (CCLK) and peripheral clock (PCLK) is determined at run time b=\n"
- "y =\n"
- "\n"
+ "> \n"
+ "> Namely, the real MCGOUTCLK source (in the middle) which is the parent for \n"
+ "> core clock (CCLK) and peripheral clock (PCLK) is determined at run time by \n"
  "> reading MCG registers, let me quote commit message from Emcraft git repo:\n"
- "> =\n"
- "\n"
- ">       * Determine in run-time what oscillator module (OSC0 or OSC1) is us=\n"
- "ed\n"
+ "> \n"
+ ">       * Determine in run-time what oscillator module (OSC0 or OSC1) is used\n"
  ">      as clock source for the main PLL.\n"
  "\n"
  "According to [0] there are three options: a 32k RTC osc clock and osc0\n"
@@ -86,16 +67,11 @@
  ">       * When OSC1 is selected, assume its frequency to be 12 MHz on all\n"
  ">      boards (there is a 12 MHz oscillator on XTAL1/EXTAL1 on K70-SOM and\n"
  ">      TWR-K70F120M boards).\n"
- "> =\n"
- "\n"
- "> In my .dts I'm trying to possibly follow real clock hierarchy, but to go =\n"
- "\n"
- "> anywhere behind MCGOUTCLK would require ability to rewrite .dtb e.g. by =\n"
- "\n"
- "> U-boot. But that's too demanding for any potential users of this BSP. So =\n"
- "\n"
- "> let's asume that MCGOUTCLK is the root clock and a parent for CCLK and =\n"
- "\n"
+ "> \n"
+ "> In my .dts I'm trying to possibly follow real clock hierarchy, but to go \n"
+ "> anywhere behind MCGOUTCLK would require ability to rewrite .dtb e.g. by \n"
+ "> U-boot. But that's too demanding for any potential users of this BSP. So \n"
+ "> let's asume that MCGOUTCLK is the root clock and a parent for CCLK and \n"
  "> PCLK.\n"
  "\n"
  "I'm confused. The point of device tree is to solve problems like this;\n"
@@ -121,47 +97,46 @@
  "\n"
  "{\n"
  "\tosc0: clock {\n"
- "\t\tcompatible =3D \"fixed-clock\";\n"
- "\t\t#clock-cells =3D <0>;\n"
- "\t\tclock-frequency =3D <50000000>;\n"
+ "\t\tcompatible = \"fixed-clock\";\n"
+ "\t\t#clock-cells = <0>;\n"
+ "\t\tclock-frequency = <50000000>;\n"
  "\t};\n"
  "\n"
  "\tosc1: clock {\n"
- "\t\tcompatible =3D \"fixed-clock\";\n"
- "\t\t#clock-cells =3D <0>;\n"
- "\t\tclock-frequency =3D <12000000>;\n"
+ "\t\tcompatible = \"fixed-clock\";\n"
+ "\t\t#clock-cells = <0>;\n"
+ "\t\tclock-frequency = <12000000>;\n"
  "\t};\n"
  "\n"
  "\trtc: clock {\n"
- "\t\tcompatible =3D \"fixed-clock\";\n"
- "\t\t#clock-cells =3D <0>;\n"
- "\t\tclock-frequency =3D <32768>;\n"
+ "\t\tcompatible = \"fixed-clock\";\n"
+ "\t\t#clock-cells = <0>;\n"
+ "\t\tclock-frequency = <32768>;\n"
  "\t};\n"
  "\n"
  "\tsoc: soc {\n"
  "\t\tmcg: clock-controller@40064000 {\n"
- "\t\t\tcompatible =3D \"fsl,kinetis-mcg\";\n"
- "\t\t\tclock-cells =3D <1>;\n"
- "\t\t\treg =3D <0x40064000 0x14>;\n"
- "\t\t\tclocks =3D <&osc0>, <&osc1>, <&rtc>;\n"
- "\t\t\tclock-names =3D \"osc0\", \"osc1\", \"rtc\";\n"
+ "\t\t\tcompatible = \"fsl,kinetis-mcg\";\n"
+ "\t\t\tclock-cells = <1>;\n"
+ "\t\t\treg = <0x40064000 0x14>;\n"
+ "\t\t\tclocks = <&osc0>, <&osc1>, <&rtc>;\n"
+ "\t\t\tclock-names = \"osc0\", \"osc1\", \"rtc\";\n"
  "\t\t};\n"
  "\n"
  "\t\tsim: clock-controller@40047000 {\n"
- "\t\t\tcompatible =3D \"fsl,kinetis-sim\";\n"
- "\t\t\tclock-cells =3D <1>;\n"
- "\t\t\treg =3D <0x40047000 0x1100>;\n"
- "\t\t\tclocks =3D <&mcg MCG_MCGOUTCLK_DIV1>, <&mcg MCG_MCGOUTCLK_DIV2>, <&mcg M=\n"
- "CG_MCGOUTCLK_DIV3> <&mcg MCG_MCGOUTCLK_DIV4>;\n"
- "\t\t\tclock-names =3D \"core\", \"bus\", \"flexbus\", \"flash\";\n"
+ "\t\t\tcompatible = \"fsl,kinetis-sim\";\n"
+ "\t\t\tclock-cells = <1>;\n"
+ "\t\t\treg = <0x40047000 0x1100>;\n"
+ "\t\t\tclocks = <&mcg MCG_MCGOUTCLK_DIV1>, <&mcg MCG_MCGOUTCLK_DIV2>, <&mcg MCG_MCGOUTCLK_DIV3> <&mcg MCG_MCGOUTCLK_DIV4>;\n"
+ "\t\t\tclock-names = \"core\", \"bus\", \"flexbus\", \"flash\";\n"
  "\t\t};\n"
  "\t};\n"
  "\n"
  "\tuart0: serial@4006a000 {\n"
- "\t\tcompatible =3D \"fsl,kinetis-lpuart\";\n"
- "\t\treg =3D <0x4006a000 0x1000>;\n"
- "\t\tclocks =3D <&sim SIM_SCGC4_UART1_CLK>;\n"
- "\t\tclock-names =3D \"gate\";\n"
+ "\t\tcompatible = \"fsl,kinetis-lpuart\";\n"
+ "\t\treg = <0x4006a000 0x1000>;\n"
+ "\t\tclocks = <&sim SIM_SCGC4_UART1_CLK>;\n"
+ "\t\tclock-names = \"gate\";\n"
  "\t};\n"
  "\n"
  "I removed the interrupts and dma stuff from the uart0 node for clarity.\n"
@@ -186,26 +161,19 @@
  "kinetis_clk_gate_get but my brain is tired so I'll leave that as an\n"
  "exercise to the reader.\n"
  "\n"
- "[0] http://cache.freescale.com/files/microcontrollers/doc/ref_manual/K70P25=\n"
- "6M150SF3RM.pdf\n"
+ "[0] http://cache.freescale.com/files/microcontrollers/doc/ref_manual/K70P256M150SF3RM.pdf\n"
  "\n"
  "Regards,\n"
  "Mike\n"
  "\n"
- "> =\n"
- "\n"
- "> In my most recent version I added OSC0ERCLK explicitly as one more root =\n"
- "\n"
- "> clock, since it is also used directly (through CG reg. 1 bit 0) by =\n"
- "\n"
- "> Freescale fec network device whose in-tree driver I'm trying to make =\n"
- "\n"
+ "> \n"
+ "> In my most recent version I added OSC0ERCLK explicitly as one more root \n"
+ "> clock, since it is also used directly (through CG reg. 1 bit 0) by \n"
+ "> Freescale fec network device whose in-tree driver I'm trying to make \n"
  "> usable for Kinetis.\n"
- "> =\n"
- "\n"
+ "> \n"
  "> On Sat, 4 Jul 2015, Arnd Bergmann wrote:\n"
- "> =\n"
- "\n"
+ "> \n"
  "> > On Friday 03 July 2015 00:08:27 Thomas Gleixner wrote:\n"
  "> >> On Thu, 2 Jul 2015, Paul Osmialowski wrote:\n"
  "> >>> On Thu, 2 Jul 2015, Arnd Bergmann wrote:\n"
@@ -215,8 +183,7 @@
  "> >>>> just fixed, you can use the normal binding for fixed rate clocks\n"
  "> >>>> and only describe the clocks that are related to the driver.\n"
  "> >>>\n"
- "> >>> In my view having these clocks grouped together looks more convincing=\n"
- ". After\n"
+ "> >>> In my view having these clocks grouped together looks more convincing. After\n"
  "> >>> all, they all share the same I/O regs in order to read configuration.\n"
  "> >>\n"
  "> >> The fact that they share a register is not making them a group. That's\n"
@@ -225,22 +192,19 @@
  "> >> the functional level.\n"
  "> >\n"
  "> > I'd disagree with that: The clock controller is the device that owns the\n"
- "> > registers and that should be one node in DT, as Paul's first version do=\n"
- "es.\n"
+ "> > registers and that should be one node in DT, as Paul's first version does.\n"
  "> >\n"
  "> > The part I'm still struggling with is understanding how the fixed-rate\n"
- "> > clocks are controlled through those registers. If they are indeed confi=\n"
- "gured\n"
+ "> > clocks are controlled through those registers. If they are indeed configured\n"
  "> > through the registers, the name is probably wrong and should be changed\n"
  "> > to whatever kind of non-fixed clock this is.\n"
  "> >\n"
  "> >       Arnd\n"
  "> >\n"
- "> =\n"
- "\n"
+ "> \n"
  "> _______________________________________________\n"
  "> linux-arm-kernel mailing list\n"
  "> linux-arm-kernel@lists.infradead.org\n"
  > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 
-0f3220d3c4fda3bb654deb8208bd8213f0d962f87c99693288e1852e792fd031
+91c9b3d65a5dd8c8ec4c37126e69c78b0fc638915f5149c78c6dfc712fa0bb75
