[PATCH mtd-www 1/4] footer: drop 'Last updated' and other buggy footer notices

[PATCH mtd-www 1/4] footer: drop 'Last updated' and other buggy footer notices

[Brian Norris]

These "last updated" messages are often wrong, and are rarely useful. We
could also drop the VAR_CVSID definitions from all the other source
files, but there's no need at the moment.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
---
 inc/footer.tmpl | 1 -
 1 file changed, 1 deletion(-)

diff --git a/inc/footer.tmpl b/inc/footer.tmpl
index 9ba350f55f56..aaa58a1950bf 100644
--- a/inc/footer.tmpl
+++ b/inc/footer.tmpl
@@ -2,7 +2,6 @@
    </div>
    <div align="right">
    	<p>
-	VAR_CVSID
       	<a href="http://validator.w3.org/check?uri=referer">
 		<img src="http://www.w3.org/Icons/valid-xhtml10"
 		 alt="Valid XHTML 1.0!" height="31" width="88" />
-- 
1.9.1

[PATCH mtd-www 2/4] source: update git tree information

[Brian Norris]

Include information about the l2-mtd.git and linux-ubifs.git trees, and
add a nice table to catalog them.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
---
 doc/git.xml |  8 +++---
 source.xml  | 90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 88 insertions(+), 10 deletions(-)

diff --git a/doc/git.xml b/doc/git.xml
index d22ef8ec6cb4..c3d0b88b87f8 100644
--- a/doc/git.xml
+++ b/doc/git.xml
@@ -11,10 +11,8 @@
 
 	<H2>MTD GIT HOWTO</H2>
 
-<P>The MTD GIT tree is at <TT>git://git.infradead.org/linux-mtd.git</TT>,
-and is visible through <A
-HREF="http://git.infradead.org/?p=linux-mtd.git">gitweb</A>. Other git
-trees are available and can be browsed through the gitweb interface 
+<P>The MTD GIT trees are documented <A HREF="../source.html">here</A>
+and can be browsed through the gitweb interface
 at <A HREF="http://git.infradead.org/">http://git.infradead.org/</A>.
 </P>
 
@@ -25,7 +23,7 @@ job runs every five minutes, indexing the available trees in users'
 gitweb.</P>
 <P>When creating GIT trees with patches you intend to be pushed upstream,
 please try to ensure that we end up with as few merges as possible.
-Anything you commit should be on top of the latest linux-mtd git tree,
+Anything you commit should be on top of the development tree (see <A HREF="../source.html">here</A>),
 rather than against a clean tree from Linus. Avoid doing any merges of
 your own, unless absolutely necessary.</P>
 
diff --git a/source.xml b/source.xml
index 01c359fd20d4..a557a23d45f7 100644
--- a/source.xml
+++ b/source.xml
@@ -10,12 +10,88 @@
 
 <h2>GIT vs. Linux 3.x</h2>
 
-    <P>The MTD GIT tree is <TT>git://git.infradead.org/linux-mtd.git</TT>,
-    and is viewable using gitweb at <A 
+    <P>MTD development is kept in GIT and managed according to standard Linux
+    development practices. Development is based off of one of several trees,
+    depending on what you're targeting. For MTD development, patches are kept
+    in the <TT>linux-mtd.git</TT> and <TT>l2-mtd.git</TT> repositories. The
+    former targets the current release cycle (use this only for bugfixes other
+    material that's worthy of rapid integration into Linus' tree), while the
+    latter targets the next Linux release (use this for most development).
+    UBI and UBIFS development is tracked separately, in
+    <TT>linux-ubifs.git</TT>. User-space tools are kept in
+    <TT>mtd-utils.git</TT>.</P>
+
+    <P>All of the kernel trees are included in the
+    <a href="http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git">linux-next</a>
+    tree and are viewable using gitweb at <A
     HREF="http://git.infradead.org/">http://git.infradead.org/</A>, along
-    with a separate tree for the userspace tools, and users' own trees.
-    From time to time, other trees will exist which contain development work
-    which is not yet ready to be merged with the mainstream kernel.</P>
+    with a separate tree for the userspace tools, and users' own trees.</P>
+
+<table cellpadding="8">
+    <tr>
+        <th>Tree Name</th><th>GIT URL</th><th>Gitweb URL</th>
+    </tr>
+    <tr>
+        <td>
+            MTD
+        </td>
+        <td>
+            <tt>git://git.infradead.org/linux-mtd.git</tt>
+        </td>
+        <td>
+            <a href="http://git.infradead.org/linux-mtd.git">
+                http://git.infradead.org/linux-mtd.git</a>
+        </td>
+    </tr>
+    <tr>
+        <td>
+            MTD (next)
+        </td>
+        <td>
+            <tt>git://git.infradead.org/l2-mtd.git</tt>
+        </td>
+        <td>
+            <a href="http://git.infradead.org/l2-mtd.git">
+                http://git.infradead.org/l2-mtd.git</a>
+        </td>
+    </tr>
+    <tr>
+        <td>
+            UBI / UBIFS
+        </td>
+        <td>
+            <tt>git://git.infradead.org/linux-ubifs.git</tt>
+        </td>
+        <td>
+            <a href="http://git.infradead.org/linux-ubifs.git">
+                http://git.infradead.org/linux-ubifs.git</a>
+        </td>
+    </tr>
+    <tr>
+        <td>
+            MTD user-space tools
+        </td>
+        <td>
+            <tt>git://git.infradead.org/mtd-utils.git</tt>
+        </td>
+        <td>
+            <a href="http://git.infradead.org/mtd-utils.git">
+                http://git.infradead.org/mtd-utils.git</a>
+        </td>
+    </tr>
+    <tr>
+        <td>
+            This website
+        </td>
+        <td>
+            <tt>git://git.infradead.org/mtd-www.git</tt>
+        </td>
+        <td>
+            <a href="http://git.infradead.org/mtd-www.git">
+                http://git.infradead.org/mtd-www.git</a>
+        </td>
+    </tr>
+</table>
 
     <P>Gitweb can give patches between specific points in the tree. To
     obtain the full patch between Linus' official kernel tree and the
@@ -59,6 +135,10 @@ different machine to the old <tt>cvs.infradead.org</tt>) may send trivial patche
 to the mailing list -- but expect to be given an account and expected to
 use git if you make a habit of it.</P>
 
+<p>If you are sending patches to the <a href="mail.html">mailing list</a>,
+please remember to base them on the appropriate tree listed above, not Linus'
+tree.</p>
+
 <h3>Patch Format Guidelines</h3>
 <p>
 In order to make the lives of the patchmonkeys/maintainers easier, a few
-- 
1.9.1

[PATCH mtd-www 3/4] doc / faq: spelling, grammar, etc.

[Brian Norris]

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
---
 doc/ubi.xml   | 10 +++++-----
 doc/ubifs.xml |  2 +-
 faq/nand.xml  |  2 +-
 faq/ubi.xml   |  6 +++---
 faq/ubifs.xml | 14 +++++++-------
 5 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/doc/ubi.xml b/doc/ubi.xml
index 5cb160306c61..3192fbce3144 100644
--- a/doc/ubi.xml
+++ b/doc/ubi.xml
@@ -535,7 +535,7 @@ amount of flash space available for UBI users. Namely:</p>
 	type and is explained below.</li>
 </ul>
 
-<p>Lets introduce symbols:</p>
+<p>Let's introduce symbols:</p>
 
 <ul>
 	<li><i>W</i> - total number of physical eraseblocks on the flash
@@ -665,10 +665,10 @@ which might be difficult to debug later. So we recommend to always do this.</p>
 For example, suppose the first NAND page of a PEB has some data, the second one
 is empty, the third one also has some data, the fourth one and the rest of NAND
 pages are empty as well. In this case UBIFS will treat all NAND pages starting
-from the fourth one as free, and will write data there. However, if the flasher
-program has already written <code>0xFF</code>'s to these pages, so they will be
-written to twice! However, many NAND flashes require NAND pages to be written
-only once, even if the data contains only <code>0xFF</code> bytes.</p>
+from the fourth one as free, and will write data there. If the flasher program
+has already written <code>0xFF</code>'s to these pages, then any new UBIFS data
+will cause a second write. However, many NAND flashes require NAND pages to be
+written only once, even if the data contains only <code>0xFF</code> bytes.</p>
 
 <p>To put it differently, writing <code>0xFF</code> bytes may have side-effects.
 What the flasher has to do is to drop all empty NAND pages from the end of the
diff --git a/doc/ubifs.xml b/doc/ubifs.xml
index 44405d67aec5..c1f54b54744f 100644
--- a/doc/ubifs.xml
+++ b/doc/ubifs.xml
@@ -666,7 +666,7 @@ NOTES
 </pre>
 
 <p>This is true for UBIFS (except of the "some buggy implementations" part,
-because UBIFS does reserves space for cached dirty data). This is also true for
+because UBIFS does reserve space for cached dirty data). This is also true for
 JFFS2, as well as for any other Linux file system.</p>
 
 <p>However, some (perhaps not very good) user-space programmers do not take
diff --git a/faq/nand.xml b/faq/nand.xml
index e142de88a4c8..05f0fbf09f65 100644
--- a/faq/nand.xml
+++ b/faq/nand.xml
@@ -92,7 +92,7 @@ necessary before you copy a filesystem image to the chip.
 
 <P>
 Technically yes, as long as this MTD partition does not contain bad blocks. But
-it is generally a bad idea. For bad block aware copying, batter use nandwrite
+it is generally a bad idea. For bad block aware copying, use nandwrite
 from the <CODE>mtd-utils</CODE> package.
 </P>
 
diff --git a/faq/ubi.xml b/faq/ubi.xml
index e20786203005..9b2165def9c3 100644
--- a/faq/ubi.xml
+++ b/faq/ubi.xml
@@ -501,7 +501,7 @@ Why does ubiattach on a freshly formatted device fail with "Invalid argument"?
 
 <p>On NAND devices that support sub-page accesses, <code>ubiformat</code>
 may choose a different location for the
-<a href="../doc/ubi.html#L_ubi_headers">VID header</a> to the kernel UBI driver
+<a href="../doc/ubi.html#L_ubi_headers">VID header</a> to the kernel UBI driver.
 This can result in the following error when attaching to a UBI device:</p>
 
 <pre>
@@ -559,7 +559,7 @@ ubi.mtd=0,2048
 
 <h2><a name="L_subpage">What is a sub-page?</a></h2>
 
-<p>Please, refer <a href="../doc/ubi.html#L_subpage">this</a> section.</p>
+<p>Please, refer to <a href="../doc/ubi.html#L_subpage">this</a> section.</p>
 
 
 
@@ -857,7 +857,7 @@ is a similar table for UBI.</p>
 <h3>Extra self-checks</h3>
 
 <p>UBI contains various internal self-check functions which are often
-very useful for debugging or testing. Please, refer the corresponding
+very useful for debugging or testing. Please, refer to the corresponding
 <a href="ubifs.html#L_how_debug_self_checks">UBIFS self-checks</a>
 section for more information, because UBI extra self-checks are very
 similar, just a bit simpler. Here is a similar table for UBI.</p>
diff --git a/faq/ubifs.xml b/faq/ubifs.xml
index 0274b52958d5..8b61fc741967 100644
--- a/faq/ubifs.xml
+++ b/faq/ubifs.xml
@@ -188,7 +188,7 @@ by running the <a href="../doc/ubi.html#L_usptools"><code>mtdinfo</code></a>
 tool with <code>-u</code> parameter. Of course, the tool has to be run on
 the target system.</p>
 
-<p>Please, refer <a href="ubi.html#L_find_min_io_size">this</a> for more
+<p>Please, refer to <a href="ubi.html#L_find_min_io_size">this</a> for more
 information about how to find these parameters.</p>
 
 <p>And optionally, you should decide which compression algorithm you want
@@ -264,7 +264,7 @@ vol_flags=autoresize
 </ul>
 
 <p>The <code>ubinize</code> utility requires volumes description file. Please,
-refer <a href="ubi.html#L_ubi_mkimg">this</a> section for more
+refer to <a href="ubi.html#L_ubi_mkimg">this</a> section for more
 <code>ubinize</code> usage information.</p>
 
 <p>In the example, the <code>ubinize.cfg</code> file tells <code>ubinize</code>
@@ -628,7 +628,7 @@ provably want the file-system doing inode updates every time they are read.</p>
 
 <h2><a name="L_nfs">Does UBIFS support NFS?</a></h2>
 
-<p>Not, it does not, which means you cannot export UBIFS file-system via NFS.
+<p>No, it does not, which means you cannot export UBIFS file-systems via NFS.
 We did make an attempt to support NFS, but the support was not exactly correct
 so it was dropped, and we have never found time to come back to that. Please,
 refer to <a href="http://marc.info/?l=linux-next&amp;m=121852228611051&amp;w=2">this thread</a>
@@ -682,15 +682,15 @@ compression, write-back, space wastage at the end of logical eraseblocks,
 garbage-collection, etc. Please, refer
 <a href="../doc/ubifs.html#L_spaceacc">this</a> section for details.</p>
 
-<p>Note, JFFS2 also has problems with free space predictions, but in average,
-it reports much more accurate amount of free space. However, JFFS2 may lie and
+<p>Note, JFFS2 also has problems with free space predictions, but on average,
+it reports free space much more accurately. However, JFFS2 may lie and
 report more free space than it actually has. For example, we experienced
 situations when JFFS2 reported 8MiB free space, while we were able to write
 only 2 MiB of data. This makes some user-space applications very unhappy.</p>
 
-<p>UBIFS also lies, but it always report <i>less</i> space that user may
+<p>UBIFS also lies, but it always reports <i>less</i> space than the user may
 actually write. For example, it may report 2MiB of free space, but if you
-start writing to it, may be able to write 4MiB there (even if you have
+start writing to it, you may be able to write 4MiB (even if you have
 compression disabled).</p>
 
 <p>Thus, the only way to find out <i>precise</i> amount of free space is to
-- 
1.9.1

[PATCH mtd-www 4/4] faq: ubi: note that CONFIG_MTD_NAND_VERIFY_WRITE is dead

[Brian Norris]

RIP.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
---
 faq/ubi.xml | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/faq/ubi.xml b/faq/ubi.xml
index 9b2165def9c3..f8c40f64044d 100644
--- a/faq/ubi.xml
+++ b/faq/ubi.xml
@@ -567,9 +567,27 @@ ubi.mtd=0,2048
 
 <p>If you have a 2048 bytes per NAND page device, and have
 <code>CONFIG_MTD_NAND_VERIFY_WRITE</code> enabled in your kernel, you will need
-to turn it off. The code does not currently (as of 2.6.26) perform verification
+to turn it off. The code did not currently (as of 2.6.26) perform verification
 of sub-page writes correctly. As UBI is one of the few users of sub-page
-writes, not much else seems to be affected by this bug.</p>
+writes, not much else seemed to be affected by this bug. In Linux 3.7,
+<code>CONFIG_MTD_NAND_VERIFY_WRITE</code> was removed:
+
+<pre>
+commit 657f28f8811c92724db10d18bbbec70d540147d6
+Date:   Tue Aug 14 22:38:45 2012 -0400
+
+    mtd: kill MTD_NAND_VERIFY_WRITE
+
+    "Both UBI and JFFS2 are able to read verify what they wrote already.
+    There are also MTD tests which do this verification. So I think there
+    is no reason to keep this in the NAND layer, let alone wasting RAM in
+    the driver to support this feature. Besides, it does not work for sub-pages
+    and many drivers have it broken. It hurts more than it provides benefits."
+
+    So kill MTD_NAND_VERIFY_WRITE entirely.
+</pre>
+
+</p>
 
 
 
-- 
1.9.1

Re: [PATCH mtd-www 1/4] footer: drop 'Last updated' and other buggy footer notices

[Brian Norris]

On Fri, Dec 19, 2014 at 06:38:23PM -0800, Brian Norris wrote:
> These "last updated" messages are often wrong, and are rarely useful. We
> could also drop the VAR_CVSID definitions from all the other source
> files, but there's no need at the moment.
> 
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Pushed all to mtd-www.git.

Brian