diff for duplicates of <20150811213041.31346.58562@quantum>

diff --git a/a/1.txt b/N1/1.txt
index 52c0f00..b0d9937 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,28 +1,23 @@
 Quoting Maxime Ripard (2015-07-25 00:39:25)
 > Hi Mike,
-> =
-
+> 
 > On Fri, Jul 24, 2015 at 11:26:19AM -0700, Michael Turquette wrote:
 > > > What are the issues with maintaining them? The only drawback I'm
 > > > seeing with introducing such a driver is that you can't really have a
 > > > clock that is both a divider and a multiplier, but that can be solved
 > > > by splitting it into two sub-clocks.
-> > =
-
+> > 
 > > There are a bunch of problems with the basic clock types. First is that
 > > there is some feature creep every merge window that subtly breaks an
 > > existing user (e.g. the round_rate stuff in clk-divider.c), and then
 > > there are the growing number of flags to handle corner cases that are
 > > one-off quirks for a single chip.
-> > =
-
+> > 
 > > These make it harder to maintain, but it is possible.
-> =
-
+> 
 > Ok. It's the downside of having common code I guess, everyone wants to
 > use it, and the clocks are just more subject to it than other drivers :/
-> =
-
+> 
 > > The real problem with these basic clock types is that they are an
 > > abstraction layer at the wrong level. Each clock type implements both
 > > the policy of a given clock, as well as the machine-specific details.
@@ -31,8 +26,7 @@ Quoting Maxime Ripard (2015-07-25 00:39:25)
 > > matter of policy and is useful on its own. But additionally that same
 > > policy is glued to a specific implementation: memory-mapped register
 > > controls for a clock divider.
-> > =
-
+> > 
 > > The I/O accessor stuff needs to be addressed at some point.  Currently
 > > the basic clock types assume specific patterns of access to
 > > memory-mapped clock registers. There are lots of other clock controls
@@ -40,14 +34,12 @@ Quoting Maxime Ripard (2015-07-25 00:39:25)
 > > code that has to be copy/pasted for each different type of access is
 > > 100%; i.e. we do not have abstractions at the right level such as
 > > .get_best_div(struct clk_hw *hw, unsigned long rate).
-> > =
-
+> > 
 > > What I would like to see in time is a re-usable layer for clock policy
 > > (e.g. common rules for how dividers or multipliers should behave), and
 > > then have that sit on top of the machine-specific callbacks that
 > > directly touch the hardware, such as the .get_best_div callback above.
-> =
-
+> 
 > Can't that be solved by moving to regmap using Matthias' patches, or
 > at least the IO method abstraction?
 
@@ -63,41 +55,32 @@ Stephen's.
 Regards,
 Mike
 
-> =
-
+> 
 > We would then have to only provide an additional callback then for
 > providers that have specific requirements about the divider
 > calculation.
-> =
-
+> 
 > So far, I haven't had any usecase where I needed anything but having
 > the as-close-as-possible rate, so I would expect to not provide
 > anything beside whether I'd like to round down or round up, but I do
 > understand that some other might have different requirements.
-> =
-
+> 
 > > For this reason I like to limit the number of new basic clock types. If
 > > there is a single user then I'm inclined to have the author put it with
 > > the machine-specific code. But in this case since there are two users, I
 > > see the value in making a new basic clock type.
-> =
-
+> 
 > That makes sense.
-> =
-
+> 
 > Maxime
-> =
-
-> -- =
-
+> 
+> -- 
 > Maxime Ripard, Free Electrons
 > Embedded Linux, Kernel and Android engineering
 > http://free-electrons.com
-> =
-
-> =
-
+> 
+> 
 > _______________________________________________
 > linux-arm-kernel mailing list
-> linux-arm-kernel@lists.infradead.org
+> linux-arm-kernel at lists.infradead.org
 > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff --git a/a/content_digest b/N1/content_digest
index e99a733..daee03d 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,45 +6,32 @@
  "ref\020150724065017.GJ2373@lukather\0"
  "ref\020150724182619.642.11590@quantum\0"
  "ref\020150725073925.GK2564@lukather\0"
- "From\0Michael Turquette <mturquette@baylibre.com>\0"
- "Subject\0Re: [PATCH v2 1/7] clk: Add a basic factor clock\0"
+ "From\0mturquette@baylibre.com (Michael Turquette)\0"
+ "Subject\0[PATCH v2 1/7] clk: Add a basic factor clock\0"
  "Date\0Tue, 11 Aug 2015 14:30:41 -0700\0"
- "To\0Maxime Ripard <maxime.ripard@free-electrons.com>"
- "\0"
- "Cc\0Chen-Yu Tsai <wens@csie.org>"
-  Jim Quinlan <jim2101024@gmail.com>
-  Stephen Boyd <sboyd@codeaurora.org>
-  Emilio Lopez <emilio@elopez.com.ar>
-  Hans de Goede <hdegoede@redhat.com>
-  linux-clk <linux-clk@vger.kernel.org>
- " linux-arm-kernel <linux-arm-kernel@lists.infradead.org>\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "Quoting Maxime Ripard (2015-07-25 00:39:25)\n"
  "> Hi Mike,\n"
- "> =\n"
- "\n"
+ "> \n"
  "> On Fri, Jul 24, 2015 at 11:26:19AM -0700, Michael Turquette wrote:\n"
  "> > > What are the issues with maintaining them? The only drawback I'm\n"
  "> > > seeing with introducing such a driver is that you can't really have a\n"
  "> > > clock that is both a divider and a multiplier, but that can be solved\n"
  "> > > by splitting it into two sub-clocks.\n"
- "> > =\n"
- "\n"
+ "> > \n"
  "> > There are a bunch of problems with the basic clock types. First is that\n"
  "> > there is some feature creep every merge window that subtly breaks an\n"
  "> > existing user (e.g. the round_rate stuff in clk-divider.c), and then\n"
  "> > there are the growing number of flags to handle corner cases that are\n"
  "> > one-off quirks for a single chip.\n"
- "> > =\n"
- "\n"
+ "> > \n"
  "> > These make it harder to maintain, but it is possible.\n"
- "> =\n"
- "\n"
+ "> \n"
  "> Ok. It's the downside of having common code I guess, everyone wants to\n"
  "> use it, and the clocks are just more subject to it than other drivers :/\n"
- "> =\n"
- "\n"
+ "> \n"
  "> > The real problem with these basic clock types is that they are an\n"
  "> > abstraction layer at the wrong level. Each clock type implements both\n"
  "> > the policy of a given clock, as well as the machine-specific details.\n"
@@ -53,8 +40,7 @@
  "> > matter of policy and is useful on its own. But additionally that same\n"
  "> > policy is glued to a specific implementation: memory-mapped register\n"
  "> > controls for a clock divider.\n"
- "> > =\n"
- "\n"
+ "> > \n"
  "> > The I/O accessor stuff needs to be addressed at some point.  Currently\n"
  "> > the basic clock types assume specific patterns of access to\n"
  "> > memory-mapped clock registers. There are lots of other clock controls\n"
@@ -62,14 +48,12 @@
  "> > code that has to be copy/pasted for each different type of access is\n"
  "> > 100%; i.e. we do not have abstractions at the right level such as\n"
  "> > .get_best_div(struct clk_hw *hw, unsigned long rate).\n"
- "> > =\n"
- "\n"
+ "> > \n"
  "> > What I would like to see in time is a re-usable layer for clock policy\n"
  "> > (e.g. common rules for how dividers or multipliers should behave), and\n"
  "> > then have that sit on top of the machine-specific callbacks that\n"
  "> > directly touch the hardware, such as the .get_best_div callback above.\n"
- "> =\n"
- "\n"
+ "> \n"
  "> Can't that be solved by moving to regmap using Matthias' patches, or\n"
  "> at least the IO method abstraction?\n"
  "\n"
@@ -85,43 +69,34 @@
  "Regards,\n"
  "Mike\n"
  "\n"
- "> =\n"
- "\n"
+ "> \n"
  "> We would then have to only provide an additional callback then for\n"
  "> providers that have specific requirements about the divider\n"
  "> calculation.\n"
- "> =\n"
- "\n"
+ "> \n"
  "> So far, I haven't had any usecase where I needed anything but having\n"
  "> the as-close-as-possible rate, so I would expect to not provide\n"
  "> anything beside whether I'd like to round down or round up, but I do\n"
  "> understand that some other might have different requirements.\n"
- "> =\n"
- "\n"
+ "> \n"
  "> > For this reason I like to limit the number of new basic clock types. If\n"
  "> > there is a single user then I'm inclined to have the author put it with\n"
  "> > the machine-specific code. But in this case since there are two users, I\n"
  "> > see the value in making a new basic clock type.\n"
- "> =\n"
- "\n"
+ "> \n"
  "> That makes sense.\n"
- "> =\n"
- "\n"
+ "> \n"
  "> Maxime\n"
- "> =\n"
- "\n"
- "> -- =\n"
- "\n"
+ "> \n"
+ "> -- \n"
  "> Maxime Ripard, Free Electrons\n"
  "> Embedded Linux, Kernel and Android engineering\n"
  "> http://free-electrons.com\n"
- "> =\n"
- "\n"
- "> =\n"
- "\n"
+ "> \n"
+ "> \n"
  "> _______________________________________________\n"
  "> linux-arm-kernel mailing list\n"
- "> linux-arm-kernel@lists.infradead.org\n"
+ "> linux-arm-kernel at lists.infradead.org\n"
  > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 
-0d1f5d2758ec34611352cbf70f8934efeeefb2462610f91d49b2f877a114634d
+128f76a638f4ab48b08253e7e06194bb571d40325f5a8206e181bbf45db1bef5
