From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: linux-mtd@lists.infradead.org, Artem Bityutskiy <dedekind1@gmail.com>
Subject: [PATCH] mtd-www: FAQ: spelling fixes
Date: Wed, 2 May 2012 08:58:26 +0300 [thread overview]
Message-ID: <20120502085826.23b8cf5c@halley> (raw)
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
next reply other threads:[~2012-05-02 5:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 5:58 Shmulik Ladkani [this message]
2012-05-02 6:09 ` [PATCH] mtd-www: FAQ: spelling fixes Brian Norris
2012-05-02 10:57 ` Shmulik Ladkani
2012-05-02 11:02 ` [PATCH v2] " Shmulik Ladkani
2012-05-02 12:24 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120502085826.23b8cf5c@halley \
--to=shmulik.ladkani@gmail.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).