All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <5403D019.8030801@marvell.com>

diff --git a/a/1.txt b/N1/1.txt
index 3d0f745..1b45827 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -16,8 +16,8 @@ On 09/01/2014 06:11 AM, Catalin Marinas wrote:
 >> -		if (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE))
 >> -			fpsimd_save_state(&current->thread.fpsimd_state);
 >
-> That?s needed if we enter a low power state directly from a task with
-> a valid mm (user). I?m not sure that?s possible, but just in case.
+> That’s needed if we enter a low power state directly from a task with
+> a valid mm (user). I’m not sure that’s possible, but just in case.
 
 u are right, in some special cases (such like IKS, etc) a normal thread 
 also may call cpu_suspend() function so that it will run here; i will 
@@ -25,8 +25,8 @@ commit another patch to reserve this part.
 
 >> +		this_cpu_write(fpsimd_last_state, NULL);
 >
-> That?s correct. In most cases, we enter low power state from the idle
-> thread which does not have an mm, so the CPU_PM_EXIT case wouldn?t set
+> That’s correct. In most cases, we enter low power state from the idle
+> thread which does not have an mm, so the CPU_PM_EXIT case wouldn’t set
 > a TIF_FOREIGN_FPSTATE, so thread switching would not detect the change.
 >
 >> 		break;
diff --git a/a/content_digest b/N1/content_digest
index b0b0e88..4204d29 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,9 +1,12 @@
  "ref\01409463591-661-1-git-send-email-leoy@marvell.com\0"
  "ref\0CC25C839-1C64-4BD0-818B-4DA0CD7EC28B@arm.com\0"
- "From\0leoy@marvell.com (Leo Yan)\0"
- "Subject\0[PATCH v1] arm64: fix bug for reloading FPSIMD state after cpu power off\0"
+ "From\0Leo Yan <leoy@marvell.com>\0"
+ "Subject\0Re: [PATCH v1] arm64: fix bug for reloading FPSIMD state after cpu power off\0"
  "Date\0Mon, 1 Sep 2014 09:47:05 +0800\0"
- "To\0linux-arm-kernel@lists.infradead.org\0"
+ "To\0Catalin Marinas <catalin.marinas@arm.com>\0"
+ "Cc\0linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>"
+  linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
+ " Ard Biesheuvel <ard.biesheuvel@linaro.org>\0"
  "\00:1\0"
  "b\0"
  "On 09/01/2014 06:11 AM, Catalin Marinas wrote:\n"
@@ -24,8 +27,8 @@
  ">> -\t\tif (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE))\n"
  ">> -\t\t\tfpsimd_save_state(&current->thread.fpsimd_state);\n"
  ">\n"
- "> That?s needed if we enter a low power state directly from a task with\n"
- "> a valid mm (user). I?m not sure that?s possible, but just in case.\n"
+ "> That\342\200\231s needed if we enter a low power state directly from a task with\n"
+ "> a valid mm (user). I\342\200\231m not sure that\342\200\231s possible, but just in case.\n"
  "\n"
  "u are right, in some special cases (such like IKS, etc) a normal thread \n"
  "also may call cpu_suspend() function so that it will run here; i will \n"
@@ -33,8 +36,8 @@
  "\n"
  ">> +\t\tthis_cpu_write(fpsimd_last_state, NULL);\n"
  ">\n"
- "> That?s correct. In most cases, we enter low power state from the idle\n"
- "> thread which does not have an mm, so the CPU_PM_EXIT case wouldn?t set\n"
+ "> That\342\200\231s correct. In most cases, we enter low power state from the idle\n"
+ "> thread which does not have an mm, so the CPU_PM_EXIT case wouldn\342\200\231t set\n"
  "> a TIF_FOREIGN_FPSTATE, so thread switching would not detect the change.\n"
  ">\n"
  ">> \t\tbreak;\n"
@@ -50,4 +53,4 @@
  "Thanks,\n"
  Leo Yan
 
-19d28f69db919c77fc10a2cdd7fc01c1ef57f66539dd2031b4b36ec90a3d588f
+ff104641a9ce6e49e099cb52e2029833ee5cd7695366218f83ddc396d762cc5e

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.