All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <566233e4cd23_40ed3ff1bbbdd3044@quark.notmuch>

diff --git a/a/1.txt b/N1/1.txt
index 38d73db..76ecd1c 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,59 +1,42 @@
-Heiko St=C3=BCbner wrote:
+Heiko Stübner wrote:
 > Hi Mike,
-> =
-
+> 
 > Am Freitag, 7. August 2015, 12:09:27 schrieb Michael Turquette:
 > > This is an alternative solution to Lee's "clk: Provide support for
 > > always-on clocks" series[0].
-> > =
-
+> > 
 > > The first two patches introduce run-time checks to ensure that clock
-> > consumer drivers are respecting the clk.h api. The former patch check=
-s
+> > consumer drivers are respecting the clk.h api. The former patch checks
 > > for prepare and enable imbalances. The latter checks for calls to
 > > clk_put without first disabling and unpreparing the clk.
-> > =
-
+> > 
 > > The third patch introduces a new flag, CLK_ENABLE_HAND_OFF, which
-> > prepares and enables a clk at registration-time. The reference counts=
-
-> > (prepare & enable) are transferred to the first clock consumer driver=
-
+> > prepares and enables a clk at registration-time. The reference counts
+> > (prepare & enable) are transferred to the first clock consumer driver
 > > that clk_get's the clk with this flag set AND calls clk_prepare or
 > > clk_enable.
-> > =
-
+> > 
 > > The net result is that a clock with this flag set will be enabled at
 > > boot and neither the clk_disable_unused garbage collector or the
-> > "sibling clock disables a shared parent" scenario will cause the flag=
-ged
+> > "sibling clock disables a shared parent" scenario will cause the flagged
 > > clock to be disabled. The first driver to come along and explicitly
 > > claim, prepare and enable this clock will inherit those reference
 > > counts. No change to clock consumer drivers is required for this to
 > > work. Please continue to use the clk.h api properly.
-> =
-
-> just out of curiosity, did this move anywhere yet? (Last message from o=
-ctober =
-
+> 
+> just out of curiosity, did this move anywhere yet? (Last message from october 
 > 1st it seems)
-> =
-
-> It looks like it is needed to fix the orphan-deferral I need on Rockchi=
-p that =
-
+> 
+> It looks like it is needed to fix the orphan-deferral I need on Rockchip that 
 > breaks sunxi in its current state.
 
-Yes, I'm preparing another version. Sorry for high latency, but I've been=
-
+Yes, I'm preparing another version. Sorry for high latency, but I've been
 traveling for more than 2 months non-stop.
 
 Regards,
 Mike
 
-> =
-
-> =
-
+> 
+> 
 > Thanks
 > Heiko
diff --git a/a/content_digest b/N1/content_digest
index d31b6d5..67e5cc4 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -14,64 +14,47 @@
  " geert@linux-m68k.org\0"
  "\00:1\0"
  "b\0"
- "Heiko St=C3=BCbner wrote:\n"
+ "Heiko St\303\274bner wrote:\n"
  "> Hi Mike,\n"
- "> =\n"
- "\n"
+ "> \n"
  "> Am Freitag, 7. August 2015, 12:09:27 schrieb Michael Turquette:\n"
  "> > This is an alternative solution to Lee's \"clk: Provide support for\n"
  "> > always-on clocks\" series[0].\n"
- "> > =\n"
- "\n"
+ "> > \n"
  "> > The first two patches introduce run-time checks to ensure that clock\n"
- "> > consumer drivers are respecting the clk.h api. The former patch check=\n"
- "s\n"
+ "> > consumer drivers are respecting the clk.h api. The former patch checks\n"
  "> > for prepare and enable imbalances. The latter checks for calls to\n"
  "> > clk_put without first disabling and unpreparing the clk.\n"
- "> > =\n"
- "\n"
+ "> > \n"
  "> > The third patch introduces a new flag, CLK_ENABLE_HAND_OFF, which\n"
- "> > prepares and enables a clk at registration-time. The reference counts=\n"
- "\n"
- "> > (prepare & enable) are transferred to the first clock consumer driver=\n"
- "\n"
+ "> > prepares and enables a clk at registration-time. The reference counts\n"
+ "> > (prepare & enable) are transferred to the first clock consumer driver\n"
  "> > that clk_get's the clk with this flag set AND calls clk_prepare or\n"
  "> > clk_enable.\n"
- "> > =\n"
- "\n"
+ "> > \n"
  "> > The net result is that a clock with this flag set will be enabled at\n"
  "> > boot and neither the clk_disable_unused garbage collector or the\n"
- "> > \"sibling clock disables a shared parent\" scenario will cause the flag=\n"
- "ged\n"
+ "> > \"sibling clock disables a shared parent\" scenario will cause the flagged\n"
  "> > clock to be disabled. The first driver to come along and explicitly\n"
  "> > claim, prepare and enable this clock will inherit those reference\n"
  "> > counts. No change to clock consumer drivers is required for this to\n"
  "> > work. Please continue to use the clk.h api properly.\n"
- "> =\n"
- "\n"
- "> just out of curiosity, did this move anywhere yet? (Last message from o=\n"
- "ctober =\n"
- "\n"
+ "> \n"
+ "> just out of curiosity, did this move anywhere yet? (Last message from october \n"
  "> 1st it seems)\n"
- "> =\n"
- "\n"
- "> It looks like it is needed to fix the orphan-deferral I need on Rockchi=\n"
- "p that =\n"
- "\n"
+ "> \n"
+ "> It looks like it is needed to fix the orphan-deferral I need on Rockchip that \n"
  "> breaks sunxi in its current state.\n"
  "\n"
- "Yes, I'm preparing another version. Sorry for high latency, but I've been=\n"
- "\n"
+ "Yes, I'm preparing another version. Sorry for high latency, but I've been\n"
  "traveling for more than 2 months non-stop.\n"
  "\n"
  "Regards,\n"
  "Mike\n"
  "\n"
- "> =\n"
- "\n"
- "> =\n"
- "\n"
+ "> \n"
+ "> \n"
  "> Thanks\n"
  > Heiko
 
-5feb5b337459739451610af30684a2b34d5cf2a4e507a0f3834c767d647ad41e
+4bce2a19c866db4da2259277d18f44774a0aa7ffc2bf0d57bf9d594c48cd6c6b

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.