[PATCH] mtd-www: FAQ: spelling fixes

[PATCH] mtd-www: FAQ: spelling fixes

[Shmulik Ladkani]

Few typos fixed.

Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
---
diff --git a/faq/jffs2.xml b/faq/jffs2.xml
index a08af7a..1b426d7 100644
--- a/faq/jffs2.xml
+++ b/faq/jffs2.xml
@@ -85,7 +85,7 @@ eraseblocks and write only in NAND page size chunks. Please, use the
 <P>
 Also please, do not forget to erase your flash before flashing the image. You
 may use the <CODE>flash_eraseall</CODE> utility for this. And it makes sense to
-make sure the erase functionality actually works my reading the erase MTD
+make sure the erase functionality actually works by reading the erased MTD
 device back and checking that only 0xFF bytes were read.
 </P>
 
@@ -210,7 +210,7 @@ write-buffer contained some data and was not yet synced before the unclean
 reboot happened. In them first and the third cases, you just lose the very
 last data you have written, in the second case you lose nothing. The wrong
 nodes will eventually be recycled by Garbage Collector and the massages will go
-(but they may leave quite long).
+(but they may live quite long).
 </P>
 
 <P>
@@ -301,7 +301,7 @@ the kernel command line to use it as a root filesystem
 <P>On <B>NOR FLASH</B> each write goes directly into the FLASH.</P>
 
 <P>
-On <B>NAND FLASHM</B> and <B>NOR ECC FLASH</B> we have a write-buffer for
+On <B>NAND FLASH</B> and <B>NOR ECC FLASH</B> we have a write-buffer for
 writing only full pages to the chips. There could be a loss of data, when the
 write-buffer is not flushed before power down. There are some mechanisms to
 ensure, that the write-buffer is flushed. You can force the flush of the
diff --git a/faq/ubifs.xml b/faq/ubifs.xml
index 8dafead..6476ce0 100644
--- a/faq/ubifs.xml
+++ b/faq/ubifs.xml
@@ -557,7 +557,7 @@ fully erased, which removes any problematic non-<code>0xFF</code> data from
 their OOB areas.</p>
 
 <p>Of course it is not possible to re-erase individual NAND pages, and entire
-PEBs are erised.  UBIFS performs this procedure by reading the useful
+PEBs are erased.  UBIFS performs this procedure by reading the useful
 (non 0xFF'ed) contents of LEBs and then invoking the
 <a href="ubi.html#L_lebchange">atomic LEB change</a> UBI operation. Obviously,
 this means that UBIFS has to read and write a lot of LEBs which takes

Re: [PATCH] mtd-www: FAQ: spelling fixes

[Brian Norris]

On Tue, May 1, 2012 at 10:58 PM, Shmulik Ladkani
<shmulik.ladkani@gmail.com> wrote:
> Few typos fixed.
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
> ---
> diff --git a/faq/jffs2.xml b/faq/jffs2.xml
> index a08af7a..1b426d7 100644
> --- a/faq/jffs2.xml
> +++ b/faq/jffs2.xml
> @@ -210,7 +210,7 @@ write-buffer contained some data and was not yet synced before the unclean
>  reboot happened. In them first and the third cases, you just lose the very
>  last data you have written, in the second case you lose nothing. The wrong
>  nodes will eventually be recycled by Garbage Collector and the massages will go

How about 'massages' -> 'messages'? :)

> -(but they may leave quite long).
> +(but they may live quite long).
>  </P>

Otherwise looks good; thanks for the fix. I think I have a few of
these type of fixes sitting around here somewhere...

Re: [PATCH] mtd-www: FAQ: spelling fixes

[Shmulik Ladkani]

Hi,

On Tue, 1 May 2012 23:09:10 -0700 Brian Norris <computersforpeace@gmail.com> wrote:
> On Tue, May 1, 2012 at 10:58 PM, Shmulik Ladkani
> > @@ -210,7 +210,7 @@ write-buffer contained some data and was not yet synced before the unclean
> > reboot happened. In them first and the third cases, you just lose the very
> > last data you have written, in the second case you lose nothing. The wrong
> > nodes will eventually be recycled by Garbage Collector and the massages will go
> 
> How about 'massages' -> 'messages'? :)

Thanks :)
Apparently my subconscious didn't want the massages to go...

Will resubmit shortly.

Regards,
Shmulik

[PATCH v2] mtd-www: FAQ: spelling fixes

[Shmulik Ladkani]

Few typos fixed.

Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
---
diff --git a/faq/jffs2.xml b/faq/jffs2.xml
index a08af7a..a204da6 100644
--- a/faq/jffs2.xml
+++ b/faq/jffs2.xml
@@ -85,7 +85,7 @@ eraseblocks and write only in NAND page size chunks. Please, use the
 <P>
 Also please, do not forget to erase your flash before flashing the image. You
 may use the <CODE>flash_eraseall</CODE> utility for this. And it makes sense to
-make sure the erase functionality actually works my reading the erase MTD
+make sure the erase functionality actually works by reading the erased MTD
 device back and checking that only 0xFF bytes were read.
 </P>
 
@@ -209,8 +209,8 @@ data write or write buffer sync or (2) while GC was working or (3) while the
 write-buffer contained some data and was not yet synced before the unclean
 reboot happened. In them first and the third cases, you just lose the very
 last data you have written, in the second case you lose nothing. The wrong
-nodes will eventually be recycled by Garbage Collector and the massages will go
-(but they may leave quite long).
+nodes will eventually be recycled by Garbage Collector and the messages will go
+(but they may live quite long).
 </P>
 
 <P>
@@ -301,7 +301,7 @@ the kernel command line to use it as a root filesystem
 <P>On <B>NOR FLASH</B> each write goes directly into the FLASH.</P>
 
 <P>
-On <B>NAND FLASHM</B> and <B>NOR ECC FLASH</B> we have a write-buffer for
+On <B>NAND FLASH</B> and <B>NOR ECC FLASH</B> we have a write-buffer for
 writing only full pages to the chips. There could be a loss of data, when the
 write-buffer is not flushed before power down. There are some mechanisms to
 ensure, that the write-buffer is flushed. You can force the flush of the
diff --git a/faq/ubifs.xml b/faq/ubifs.xml
index 8dafead..6476ce0 100644
--- a/faq/ubifs.xml
+++ b/faq/ubifs.xml
@@ -557,7 +557,7 @@ fully erased, which removes any problematic non-<code>0xFF</code> data from
 their OOB areas.</p>
 
 <p>Of course it is not possible to re-erase individual NAND pages, and entire
-PEBs are erised.  UBIFS performs this procedure by reading the useful
+PEBs are erased.  UBIFS performs this procedure by reading the useful
 (non 0xFF'ed) contents of LEBs and then invoking the
 <a href="ubi.html#L_lebchange">atomic LEB change</a> UBI operation. Obviously,
 this means that UBIFS has to read and write a lot of LEBs which takes

Re: [PATCH v2] mtd-www: FAQ: spelling fixes

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

On Wed, 2012-05-02 at 14:02 +0300, Shmulik Ladkani wrote:
> Few typos fixed.
> 
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>

Pushed to mtd-www.git, thanks!

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]