All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1493979065.3591.26.camel@nxp.com>

diff --git a/a/1.txt b/N1/1.txt
index 2295dfd..b48afd2 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -9,8 +9,8 @@ On Fri, 2017-05-05 at 09:18 +0800, Shawn Guo wrote:
 > 
 > @Leonard, if someday we support 'LDO bypass' mode in upstream kernel,
 > the OPP hackery needs to be back in some way even with reg_arm/reg_soc
-> modeling in place, right?  Or will we have a better way to ensure SW1A
-> rail can always feed a correct voltage directly to reg_arm®_soc?
+> modeling in place, right???Or will we have a better way to ensure SW1A
+> rail can always feed a correct voltage directly to reg_arm?_soc?
 
 Maybe? Or maybe the cpufreq driver could detect this situation and
 handle it internally. In the vendor tree this the cpufreq driver has a
@@ -20,10 +20,10 @@ I posted another RFC at upstreaming ldo-bypass recently but it did not
 handle this particular case of a shared input rail. It can be handled
 separately.
 
-See: https://lkml.org/lkml/2017/3/22/640
+See:?https://lkml.org/lkml/2017/3/22/640
 
 But getting that series to an acceptable state might take a long time.
 
--- 
+--?
 Regards,
 Leonard
diff --git a/a/content_digest b/N1/content_digest
index 01c88b3..27f1c49 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -9,21 +9,10 @@
  "ref\020170504134100.GR18578@dragon\0"
  "ref\08c3827c4-1272-f004-52d9-7c79e93813c6@denx.de\0"
  "ref\020170505011834.GS18578@dragon\0"
- "From\0Leonard Crestez <leonard.crestez@nxp.com>\0"
- "Subject\0Re: [PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override\0"
+ "From\0leonard.crestez@nxp.com (Leonard Crestez)\0"
+ "Subject\0[PATCH] ARM: dts: imx6sx-sdb: Remove cpufreq OPP override\0"
  "Date\0Fri, 5 May 2017 13:11:05 +0300\0"
- "To\0Shawn Guo <shawnguo@kernel.org>"
- " Marek Vasut <marex@denx.de>\0"
- "Cc\0Peter Chen <Peter.Chen@nxp.com>"
-  Anson Huang <Anson.Huang@nxp.com>
-  linux-pm@vger.kernel.org <linux-pm@vger.kernel.org>
-  Viresh Kumar <viresh.kumar@linaro.org>
-  Rafael J. Wysocki <rjw@rjwysocki.net>
-  linux-kernel <linux-kernel@vger.kernel.org>
-  Sascha Hauer <kernel@pengutronix.de>
-  Fabio Estevam <fabio.estevam@nxp.com>
-  Fabio Estevam <festevam@gmail.com>
- " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On Fri, 2017-05-05 at 09:18 +0800, Shawn Guo wrote:\n"
@@ -37,8 +26,8 @@
  "> \n"
  "> @Leonard, if someday we support 'LDO bypass' mode in upstream kernel,\n"
  "> the OPP hackery needs to be back in some way even with reg_arm/reg_soc\n"
- "> modeling in place, right?\302\240\302\240Or will we have a better way to ensure SW1A\n"
- "> rail can always feed a correct voltage directly to reg_arm\302\256_soc?\n"
+ "> modeling in place, right???Or will we have a better way to ensure SW1A\n"
+ "> rail can always feed a correct voltage directly to reg_arm?_soc?\n"
  "\n"
  "Maybe? Or maybe the cpufreq driver could detect this situation and\n"
  "handle it internally. In the vendor tree this the cpufreq driver has a\n"
@@ -48,12 +37,12 @@
  "handle this particular case of a shared input rail. It can be handled\n"
  "separately.\n"
  "\n"
- "See:\302\240https://lkml.org/lkml/2017/3/22/640\n"
+ "See:?https://lkml.org/lkml/2017/3/22/640\n"
  "\n"
  "But getting that series to an acceptable state might take a long time.\n"
  "\n"
- "--\302\240\n"
+ "--?\n"
  "Regards,\n"
  Leonard
 
-901d825b7c428e79deb7c1786f64f33f9c6d3dfbf5ab7cbd226445de54a15452
+2b0a6430c73f979d6909f10b369b35eead32a7acff481ddd1da8804c3765b9be

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.