All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <4EE903CE.1010903@freescale.com>

diff --git a/a/1.txt b/N1/1.txt
index 7df3fbc..15fa4c1 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,25 +1,31 @@
 On 12/14/2011 02:41 AM, LiuShuo wrote:
-> 于 2011年12月13日 10:46, LiuShuo 写道:
->> 于 2011年12月13日 05:30, Scott Wood 写道:
+> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 10:46, LiuShuo =E5=86=99=E9=
+=81=93:
+>> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:30, Scott Wood =E5=86=
+=99=E9=81=93:
 >>> On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
 >>>> On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
->>>>> NAND chips come from the factory with bad blocks marked at a certain
->>>>> offset into each page.  This offset is normally in the OOB area, but
+>>>>> NAND chips come from the factory with bad blocks marked at a certai=
+n
+>>>>> offset into each page.  This offset is normally in the OOB area, bu=
+t
 >>>>> since we change the layout from "4k data, 128 byte oob" to "2k
 >>>>> data, 64
 >>>>> byte oob, 2k data, 64 byte oob" the marker is no longer in the
 >>>>> oob.  On
 >>>>> first use we need to migrate the markers so that they are still in
 >>>>> the oob.
->>>> Ah, I see, thanks. Are you planning to implement in-kernel migration or
+>>>> Ah, I see, thanks. Are you planning to implement in-kernel migration=
+ or
 >>>> use a user-space tool?
 >>> That's the kind of answer I was hoping to get from Shuo. :-)
 >> OK, I try to do this. Wait for a couple of days.
 >>
 >> -LiuShuo
 > I found it's too complex to do the migration in Linux driver.
-> 
-> Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once is
+>=20
+> Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once i=
+s
 > enough.
 
 Any reason not to do it automatically on the first U-Boot bad block
@@ -28,12 +34,14 @@ scan, if the flash isn't marked as already migrated?
 Further discussion on the details of how to do it in U-Boot should move
 to the U-Boot list.
 
-> And let user ensure it been completed before linux use the Nand flash chip.
+> And let user ensure it been completed before linux use the Nand flash c=
+hip.
 
 I don't want to trust the user here.  It's too easy to skip it, and
 things will appear to work, but have subtle problems.
 
-> Even if we don't do the migration, the bad block also can be marked as bad
+> Even if we don't do the migration, the bad block also can be marked as =
+bad
 > by wearing. So, do we really need to take much time to implement it ?
 > (code looks too complex.)
 
diff --git a/a/content_digest b/N1/content_digest
index d4c6bc2..feea919 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -18,32 +18,37 @@
   shuo.liu@freescale.com
   linux-mtd@lists.infradead.org
   akpm@linux-foundation.org
-  leoli@freescale.com
  " dwmw2@infradead.org\0"
  "\00:1\0"
  "b\0"
  "On 12/14/2011 02:41 AM, LiuShuo wrote:\n"
- "> \344\272\216 2011\345\271\26412\346\234\21013\346\227\245 10:46, LiuShuo \345\206\231\351\201\223:\n"
- ">> \344\272\216 2011\345\271\26412\346\234\21013\346\227\245 05:30, Scott Wood \345\206\231\351\201\223:\n"
+ "> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 10:46, LiuShuo =E5=86=99=E9=\n"
+ "=81=93:\n"
+ ">> =E4=BA=8E 2011=E5=B9=B412=E6=9C=8813=E6=97=A5 05:30, Scott Wood =E5=86=\n"
+ "=99=E9=81=93:\n"
  ">>> On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:\n"
  ">>>> On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:\n"
- ">>>>> NAND chips come from the factory with bad blocks marked at a certain\n"
- ">>>>> offset into each page.  This offset is normally in the OOB area, but\n"
+ ">>>>> NAND chips come from the factory with bad blocks marked at a certai=\n"
+ "n\n"
+ ">>>>> offset into each page.  This offset is normally in the OOB area, bu=\n"
+ "t\n"
  ">>>>> since we change the layout from \"4k data, 128 byte oob\" to \"2k\n"
  ">>>>> data, 64\n"
  ">>>>> byte oob, 2k data, 64 byte oob\" the marker is no longer in the\n"
  ">>>>> oob.  On\n"
  ">>>>> first use we need to migrate the markers so that they are still in\n"
  ">>>>> the oob.\n"
- ">>>> Ah, I see, thanks. Are you planning to implement in-kernel migration or\n"
+ ">>>> Ah, I see, thanks. Are you planning to implement in-kernel migration=\n"
+ " or\n"
  ">>>> use a user-space tool?\n"
  ">>> That's the kind of answer I was hoping to get from Shuo. :-)\n"
  ">> OK, I try to do this. Wait for a couple of days.\n"
  ">>\n"
  ">> -LiuShuo\n"
  "> I found it's too complex to do the migration in Linux driver.\n"
- "> \n"
- "> Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once is\n"
+ ">=20\n"
+ "> Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once i=\n"
+ "s\n"
  "> enough.\n"
  "\n"
  "Any reason not to do it automatically on the first U-Boot bad block\n"
@@ -52,12 +57,14 @@
  "Further discussion on the details of how to do it in U-Boot should move\n"
  "to the U-Boot list.\n"
  "\n"
- "> And let user ensure it been completed before linux use the Nand flash chip.\n"
+ "> And let user ensure it been completed before linux use the Nand flash c=\n"
+ "hip.\n"
  "\n"
  "I don't want to trust the user here.  It's too easy to skip it, and\n"
  "things will appear to work, but have subtle problems.\n"
  "\n"
- "> Even if we don't do the migration, the bad block also can be marked as bad\n"
+ "> Even if we don't do the migration, the bad block also can be marked as =\n"
+ "bad\n"
  "> by wearing. So, do we really need to take much time to implement it ?\n"
  "> (code looks too complex.)\n"
  "\n"
@@ -71,4 +78,4 @@
  "\n"
  -Scott
 
-87cc38b58a8dd0a11c90d7a78c2f2981b8f8e022f78d03e5f97bcc40e3a8dfe6
+6ab77d37b76bc468f340559200b9f2bf5642ad2c298e2d41fa9df683830400ea

diff --git a/a/content_digest b/N2/content_digest
index d4c6bc2..769a00b 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -11,15 +11,15 @@
  "Subject\0Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip\0"
  "Date\0Wed, 14 Dec 2011 14:15:10 -0600\0"
  "To\0LiuShuo <b35362@freescale.com>\0"
- "Cc\0Artem.Bityutskiy@nokia.com"
-  dedekind1@gmail.com
-  linuxppc-dev@lists.ozlabs.org
-  linux-kernel@vger.kernel.org
-  shuo.liu@freescale.com
-  linux-mtd@lists.infradead.org
-  akpm@linux-foundation.org
-  leoli@freescale.com
- " dwmw2@infradead.org\0"
+ "Cc\0<dedekind1@gmail.com>"
+  <shuo.liu@freescale.com>
+  <dwmw2@infradead.org>
+  <Artem.Bityutskiy@nokia.com>
+  <linux-mtd@lists.infradead.org>
+  <linuxppc-dev@lists.ozlabs.org>
+  <akpm@linux-foundation.org>
+  <linux-kernel@vger.kernel.org>
+ " <leoli@freescale.com>\0"
  "\00:1\0"
  "b\0"
  "On 12/14/2011 02:41 AM, LiuShuo wrote:\n"
@@ -71,4 +71,4 @@
  "\n"
  -Scott
 
-87cc38b58a8dd0a11c90d7a78c2f2981b8f8e022f78d03e5f97bcc40e3a8dfe6
+a182a404151ec0952c69b6dc74dc62caf235dbea193c00cec7c719d0bebec7b2

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.