diff for duplicates of <20120112131301.GA3478@matterhorn1>

diff --git a/a/1.txt b/N1/1.txt
index 94528e9..d1d5660 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -15,7 +15,7 @@ On 12 Jan 04, Turquette, Mike wrote:
 > >>>>>>> + * @clk: clk being initialized
 > >>>>>>> + *
 > >>>>>>> + * Initializes the lists in struct clk, queries the hardware for the
-> >>>>>>> + * parent and rate and sets them both.  Adds the clk to the sysfs tree
+> >>>>>>> + * parent and rate and sets them both. ?Adds the clk to the sysfs tree
 > >>>>>>> + * topology.
 > >>>>>>> + *
 > >>>>>>> + * Caller must populate clk->name and clk->flags before calling
@@ -32,19 +32,19 @@ On 12 Jan 04, Turquette, Mike wrote:
 > >>>>>> That would change the init call to something like:
 > >>>>>>
 > >>>>>> struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
-> >>>>>>                     struct clk *parent)
+> >>>>>> ? ? ? ? ? ? ? ? ? ? struct clk *parent)
 > >>>>>>
 > >>>>>> And have:
 > >>>>>> struct clk_hw {
-> >>>>>>       struct clk_hw_ops *ops;
-> >>>>>>       const char        *name;
-> >>>>>>       unsigned long     flags;
+> >>>>>> ? ? ? struct clk_hw_ops *ops;
+> >>>>>> ? ? ? const char ? ? ? ?*name;
+> >>>>>> ? ? ? unsigned long ? ? flags;
 > >>>>>> };
 > >>>>>>
 > >>>>>> Implementers can do:
 > >>>>>> struct my_clk_hw {
-> >>>>>>       struct clk_hw    hw;
-> >>>>>>       mydata;
+> >>>>>> ? ? ? struct clk_hw ? ?hw;
+> >>>>>> ? ? ? mydata;
 > >>>>>> };
 > >>>>>>
 > >>>>>> And then change the clk ops callbacks to take struct clk_hw * as an
@@ -76,12 +76,12 @@ On 12 Jan 04, Turquette, Mike wrote:
 > >> The original clk_hw was defined simply as:
 > >>
 > >> struct clk_hw {
-> >>         struct clk *clk;
+> >> ? ? ? ? struct clk *clk;
 > >> };
 > >>
 > >> It's only purpose in life was as a handle for navigation between the
-> >> opaque struct clk and the hardware-specific struct my_clk_hw.  struct
-> >> clk_hw is defined in clk.h and everyone can see it.  If we're suddenly
+> >> opaque struct clk and the hardware-specific struct my_clk_hw. ?struct
+> >> clk_hw is defined in clk.h and everyone can see it. ?If we're suddenly
 > >> OK putting clk data in this structure then why bother with an opaque
 > >> struct clk at all?
 > >>
@@ -92,8 +92,8 @@ On 12 Jan 04, Turquette, Mike wrote:
 > >>
 > >> To answer your question on what data we're trying to expose: platform
 > >> code commonly needs the parent pointer and the clk rate (and by
-> >> extension, the rate of the parent).  For debug/error prints it is also
-> >> nice to have the clk name.  Generic clk flags are also conceivably
+> >> extension, the rate of the parent). ?For debug/error prints it is also
+> >> nice to have the clk name. ?Generic clk flags are also conceivably
 > >> something that platform code might want.
 > >
 > > I agree with the need to have the parent and flags from a static init
@@ -138,8 +138,3 @@ We're stuck on this fundamental point for a while now. And v5 of the
 patchset doesn't make much sense without resolving it.
 
 /Amit
-
-_______________________________________________
-linaro-dev mailing list
-linaro-dev@lists.linaro.org
-http://lists.linaro.org/mailman/listinfo/linaro-dev
diff --git a/a/content_digest b/N1/content_digest
index 5704bb3..37461e7 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -7,31 +7,10 @@
  "ref\0CAJOA=zPw7UuhE4R3SsBeyzQ2_iN29Zv-ExaUTTFCah+GoFSfNQ@mail.gmail.com\0"
  "ref\04F0506D0.30109@gmail.com\0"
  "ref\0CAJOA=zPgwiOSoyZK1SpzZVZfTOmwruTR=WO+gRdVZrZVzNuPSA@mail.gmail.com\0"
- "ref\0CAJOA=zPgwiOSoyZK1SpzZVZfTOmwruTR=WO+gRdVZrZVzNuPSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org\0"
- "From\0Amit Kucheria <amit.kucheria-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>\0"
- "Subject\0Re: [PATCH v4 3/6] clk: introduce the common clock framework\0"
+ "From\0amit.kucheria@linaro.org (Amit Kucheria)\0"
+ "Subject\0[PATCH v4 3/6] clk: introduce the common clock framework\0"
  "Date\0Thu, 12 Jan 2012 15:13:01 +0200\0"
- "To\0Turquette"
-  Mike <mturquette-l0cyMroinI0@public.gmane.org>
- " Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>\0"
- "Cc\0andrew-g2DYL2Zd6BY@public.gmane.org"
-  linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org
-  eric.miao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
-  jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org
-  linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org
-  sboyd-jfJNa2p1gH1BDgjK7y7TUQ@public.gmane.org
-  magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
-  linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
-  arnd.bergmann-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
-  patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
-  linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  paul-DWxLp4Yu+b8AvxtiuMwx3w@public.gmane.org
-  linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org
-  broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org
-  linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-  Colin Cross <ccross-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
-  Richard Zhao <richard.zhao-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
- " skannan-jfJNa2p1gH1BDgjK7y7TUQ@public.gmane.org\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On 12 Jan 04, Turquette, Mike wrote:\n"
@@ -51,7 +30,7 @@
  "> >>>>>>> + * @clk: clk being initialized\n"
  "> >>>>>>> + *\n"
  "> >>>>>>> + * Initializes the lists in struct clk, queries the hardware for the\n"
- "> >>>>>>> + * parent and rate and sets them both. \302\240Adds the clk to the sysfs tree\n"
+ "> >>>>>>> + * parent and rate and sets them both. ?Adds the clk to the sysfs tree\n"
  "> >>>>>>> + * topology.\n"
  "> >>>>>>> + *\n"
  "> >>>>>>> + * Caller must populate clk->name and clk->flags before calling\n"
@@ -68,19 +47,19 @@
  "> >>>>>> That would change the init call to something like:\n"
  "> >>>>>>\n"
  "> >>>>>> struct clk *clk_init(struct device *dev, const struct clk_hw *hw,\n"
- "> >>>>>> \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 struct clk *parent)\n"
+ "> >>>>>> ? ? ? ? ? ? ? ? ? ? struct clk *parent)\n"
  "> >>>>>>\n"
  "> >>>>>> And have:\n"
  "> >>>>>> struct clk_hw {\n"
- "> >>>>>> \302\240 \302\240 \302\240 struct clk_hw_ops *ops;\n"
- "> >>>>>> \302\240 \302\240 \302\240 const char \302\240 \302\240 \302\240 \302\240*name;\n"
- "> >>>>>> \302\240 \302\240 \302\240 unsigned long \302\240 \302\240 flags;\n"
+ "> >>>>>> ? ? ? struct clk_hw_ops *ops;\n"
+ "> >>>>>> ? ? ? const char ? ? ? ?*name;\n"
+ "> >>>>>> ? ? ? unsigned long ? ? flags;\n"
  "> >>>>>> };\n"
  "> >>>>>>\n"
  "> >>>>>> Implementers can do:\n"
  "> >>>>>> struct my_clk_hw {\n"
- "> >>>>>> \302\240 \302\240 \302\240 struct clk_hw \302\240 \302\240hw;\n"
- "> >>>>>> \302\240 \302\240 \302\240 mydata;\n"
+ "> >>>>>> ? ? ? struct clk_hw ? ?hw;\n"
+ "> >>>>>> ? ? ? mydata;\n"
  "> >>>>>> };\n"
  "> >>>>>>\n"
  "> >>>>>> And then change the clk ops callbacks to take struct clk_hw * as an\n"
@@ -112,12 +91,12 @@
  "> >> The original clk_hw was defined simply as:\n"
  "> >>\n"
  "> >> struct clk_hw {\n"
- "> >> \302\240 \302\240 \302\240 \302\240 struct clk *clk;\n"
+ "> >> ? ? ? ? struct clk *clk;\n"
  "> >> };\n"
  "> >>\n"
  "> >> It's only purpose in life was as a handle for navigation between the\n"
- "> >> opaque struct clk and the hardware-specific struct my_clk_hw. \302\240struct\n"
- "> >> clk_hw is defined in clk.h and everyone can see it. \302\240If we're suddenly\n"
+ "> >> opaque struct clk and the hardware-specific struct my_clk_hw. ?struct\n"
+ "> >> clk_hw is defined in clk.h and everyone can see it. ?If we're suddenly\n"
  "> >> OK putting clk data in this structure then why bother with an opaque\n"
  "> >> struct clk at all?\n"
  "> >>\n"
@@ -128,8 +107,8 @@
  "> >>\n"
  "> >> To answer your question on what data we're trying to expose: platform\n"
  "> >> code commonly needs the parent pointer and the clk rate (and by\n"
- "> >> extension, the rate of the parent). \302\240For debug/error prints it is also\n"
- "> >> nice to have the clk name. \302\240Generic clk flags are also conceivably\n"
+ "> >> extension, the rate of the parent). ?For debug/error prints it is also\n"
+ "> >> nice to have the clk name. ?Generic clk flags are also conceivably\n"
  "> >> something that platform code might want.\n"
  "> >\n"
  "> > I agree with the need to have the parent and flags from a static init\n"
@@ -173,11 +152,6 @@
  "We're stuck on this fundamental point for a while now. And v5 of the\n"
  "patchset doesn't make much sense without resolving it.\n"
  "\n"
- "/Amit\n"
- "\n"
- "_______________________________________________\n"
- "linaro-dev mailing list\n"
- "linaro-dev@lists.linaro.org\n"
- http://lists.linaro.org/mailman/listinfo/linaro-dev
+ /Amit
 
-1a1f5dbe3bc39eeb1f1b0fcf717af929c9f07753a0c5a4abcb670d7df5657fd9
+963c447ede950c8d885fac2ef03a906de85809f3f33fb45e64256e8abd0ac9e1
