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

diff --git a/a/1.txt b/N1/1.txt
index e607975..ed5b77d 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,18 +1,24 @@
-于 2011年12月15日 04:15, Scott Wood 写道:
+=E4=BA=8E 2011=E5=B9=B412=E6=9C=8815=E6=97=A5 04:15, Scott Wood =E5=86=99=
+=E9=81=93:
 > 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 certa=
+in
+>>>>>> offset into each page.  This offset is normally in the OOB area, b=
+ut
 >>>>>> 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 migratio=
+n 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.
@@ -20,7 +26,8 @@
 >>> -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
+>> Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once =
+is
 >> enough.
 > Any reason not to do it automatically on the first U-Boot bad block
 > scan, if the flash isn't marked as already migrated?
@@ -28,26 +35,29 @@
 > 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 =
+chip.
 > 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.)
 > It is not acceptable to ignore factory bad block markers just because
-> some methods of using the flash may eventually detect an error (possibly
+> some methods of using the flash may eventually detect an error (possibl=
+y
 > after data is lost -- no guarantee that the badness is ECC-correctable)
 > and mark the block bad again.
 >
 > If you don't feel up to the task, I can look at it, but won't have time
 > until January.
 hi Scott,
-It's really hard to me and I have much other works to do now. Thanks for 
+It's really hard to me and I have much other works to do now. Thanks for=20
 your help.
 
 hi Artem,
-Could this patch be applied now and we make a independent patch for  bad 
+Could this patch be applied now and we make a independent patch for  bad=20
 block information
 migration later?
 
diff --git a/a/content_digest b/N1/content_digest
index 9434a3b..a8cff39 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -19,25 +19,30 @@
   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"
- "\344\272\216 2011\345\271\26412\346\234\21015\346\227\245 04:15, Scott Wood \345\206\231\351\201\223:\n"
+ "=E4=BA=8E 2011=E5=B9=B412=E6=9C=8815=E6=97=A5 04:15, Scott Wood =E5=86=99=\n"
+ "=E9=81=93:\n"
  "> 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=\n"
+ "=E9=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 certa=\n"
+ "in\n"
+ ">>>>>> offset into each page.  This offset is normally in the OOB area, b=\n"
+ "ut\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 migratio=\n"
+ "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"
@@ -45,7 +50,8 @@
  ">>> -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"
+ ">> Maybe we can add a uboot command (e.g. nand bbmigrate) to do it, once =\n"
+ "is\n"
  ">> enough.\n"
  "> Any reason not to do it automatically on the first U-Boot bad block\n"
  "> scan, if the flash isn't marked as already migrated?\n"
@@ -53,26 +59,29 @@
  "> 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 =\n"
+ "chip.\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"
  "> It is not acceptable to ignore factory bad block markers just because\n"
- "> some methods of using the flash may eventually detect an error (possibly\n"
+ "> some methods of using the flash may eventually detect an error (possibl=\n"
+ "y\n"
  "> after data is lost -- no guarantee that the badness is ECC-correctable)\n"
  "> and mark the block bad again.\n"
  ">\n"
  "> If you don't feel up to the task, I can look at it, but won't have time\n"
  "> until January.\n"
  "hi Scott,\n"
- "It's really hard to me and I have much other works to do now. Thanks for \n"
+ "It's really hard to me and I have much other works to do now. Thanks for=20\n"
  "your help.\n"
  "\n"
  "hi Artem,\n"
- "Could this patch be applied now and we make a independent patch for  bad \n"
+ "Could this patch be applied now and we make a independent patch for  bad=20\n"
  "block information\n"
  "migration later?\n"
  "\n"
@@ -80,4 +89,4 @@
  "\n"
  > -Scott
 
-086c745f671ccd4279e2a94ef1744c8b7e349b213fffbbcdecf626da387e061b
+0f3401fef533edf683ae5c6f1e5ad8a784f7a3246c6365fdd69760c5a542c0f2

diff --git a/a/content_digest b/N2/content_digest
index 9434a3b..42484f2 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -13,14 +13,14 @@
  "Date\0Fri, 16 Dec 2011 10:44:06 +0800\0"
  "To\0Scott Wood <scottwood@freescale.com>"
  " <dedekind1@gmail.com>\0"
- "Cc\0Artem.Bityutskiy@nokia.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<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"
  "\344\272\216 2011\345\271\26412\346\234\21015\346\227\245 04:15, Scott Wood \345\206\231\351\201\223:\n"
@@ -80,4 +80,4 @@
  "\n"
  > -Scott
 
-086c745f671ccd4279e2a94ef1744c8b7e349b213fffbbcdecf626da387e061b
+0f6c8fa2be055749cda2347f80317349fc9b4418e3e09421c247c4a8b6b08553

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.