UBI: Fix s/then/than/ typos

Submitted by Shinya Kuribayashi on May 6, 2010, 3:41 a.m.

Details

Message ID 4BE23A6F.1010406@renesas.com
State New, archived
Headers show

Commit Message

Shinya Kuribayashi May 6, 2010, 3:41 a.m.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
  drivers/mtd/ubi/Kconfig |    2 +-
  drivers/mtd/ubi/io.c    |    2 +-
  drivers/mtd/ubi/kapi.c  |    6 +++---
  drivers/mtd/ubi/scan.c  |    4 ++--
  drivers/mtd/ubi/wl.c    |    2 +-
  5 files changed, 8 insertions(+), 8 deletions(-)

Comments

Artem Bityutskiy May 6, 2010, 6:33 a.m.
On Thu, 2010-05-06 at 12:41 +0900, Shinya Kuribayashi wrote:
> Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
> ---
>   drivers/mtd/ubi/Kconfig |    2 +-
>   drivers/mtd/ubi/io.c    |    2 +-
>   drivers/mtd/ubi/kapi.c  |    6 +++---
>   drivers/mtd/ubi/scan.c  |    4 ++--
>   drivers/mtd/ubi/wl.c    |    2 +-
>   5 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
> index 0a8c7ea..f702a16 100644

Weird, but I cannot apply this patch. Could you please save it from the
mailing list and try to apply? For me, all hunks fail:

[dedekind@eru ubi-2.6]$ patch -p1 < ~/tmp/shinya1 
patching file drivers/mtd/ubi/Kconfig
Hunk #1 FAILED at 27.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/mtd/ubi/Kconfig.rej
patching file drivers/mtd/ubi/io.c
Hunk #1 FAILED at 65.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/mtd/ubi/io.c.rej
patching file drivers/mtd/ubi/kapi.c
Hunk #1 FAILED at 488.
Hunk #2 FAILED at 571.
Hunk #3 FAILED at 590.
3 out of 3 hunks FAILED -- saving rejects to file
drivers/mtd/ubi/kapi.c.rej
patching file drivers/mtd/ubi/scan.c
Hunk #1 FAILED at 231.
Hunk #2 FAILED at 452.
2 out of 2 hunks FAILED -- saving rejects to file
drivers/mtd/ubi/scan.c.rej
patching file drivers/mtd/ubi/wl.c
Hunk #1 FAILED at 350.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/mtd/ubi/wl.c.rej
Artem Bityutskiy May 6, 2010, 6:47 a.m.
On Thu, 2010-05-06 at 12:41 +0900, Shinya Kuribayashi wrote:
> Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
> ---
>   drivers/mtd/ubi/Kconfig |    2 +-
>   drivers/mtd/ubi/io.c    |    2 +-
>   drivers/mtd/ubi/kapi.c  |    6 +++---
>   drivers/mtd/ubi/scan.c  |    4 ++--
>   drivers/mtd/ubi/wl.c    |    2 +-
>   5 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
> index 0a8c7ea..f702a16 100644
> --- a/drivers/mtd/ubi/Kconfig
> +++ b/drivers/mtd/ubi/Kconfig
> @@ -27,7 +27,7 @@ config MTD_UBI_WL_THRESHOLD
>   	  The default value should be OK for SLC NAND flashes, NOR flashes and
>   	  other flashes which have eraseblock life-cycle 100000 or more.
>   	  However, in case of MLC NAND flashes which typically have eraseblock
> -	  life-cycle less then 10000, the threshold should be lessened (e.g.,
> +	  life-cycle less than 10000, the threshold should be lessened (e.g.,
>   	  to 128 or 256, although it does not have to be power of 2).

Thanks for the patches, but they really look corrupted. Could you please
send applicable versions?
Shinya Kuribayashi May 6, 2010, 7:06 a.m.
On 5/6/2010 3:47 PM, Artem Bityutskiy wrote:
> Thanks for the patches, but they really look corrupted. Could you please
> send applicable versions?

Ah, the culprit must be 'format=flowed'.  Recently I've migrated to
Thunderbird3 and this was my first patch submission to communities.
Should have disabled that option, sorry for inconvenience!

Will fix and resubmit a few hours later to wait for any feedbacks.
Artem Bityutskiy May 6, 2010, 7:21 a.m.
On Thu, 2010-05-06 at 16:06 +0900, Shinya Kuribayashi wrote:
> On 5/6/2010 3:47 PM, Artem Bityutskiy wrote:
> > Thanks for the patches, but they really look corrupted. Could you please
> > send applicable versions?
> 
> Ah, the culprit must be 'format=flowed'.  Recently I've migrated to
> Thunderbird3 and this was my first patch submission to communities.
> Should have disabled that option, sorry for inconvenience!
> 
> Will fix and resubmit a few hours later to wait for any feedbacks.

AFAIK, format=flowed is just about displaying quoted text, not changing
the contents.

I also tried to use thunderbird in the past, but it is very unfrienly to
patch submitters. So I switched to Evolution which is much better. But
for sending patches git send-email is the tool to use in most of the
cases, IMO.
Mark Brown May 7, 2010, 3:58 p.m.
On Thu, May 06, 2010 at 10:21:35AM +0300, Artem Bityutskiy wrote:

> AFAIK, format=flowed is just about displaying quoted text, not changing
> the contents.

No, it affects all text - it allows the MUA to re-wrap text in
paragraphs to fit within the display regardless of the original line
wrapping.  It's very useful for human languages but unfortunate for
patches.

Patch hide | download patch | download mbox

diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
index 0a8c7ea..f702a16 100644
--- a/drivers/mtd/ubi/Kconfig
+++ b/drivers/mtd/ubi/Kconfig
@@ -27,7 +27,7 @@  config MTD_UBI_WL_THRESHOLD
  	  The default value should be OK for SLC NAND flashes, NOR flashes and
  	  other flashes which have eraseblock life-cycle 100000 or more.
  	  However, in case of MLC NAND flashes which typically have eraseblock
-	  life-cycle less then 10000, the threshold should be lessened (e.g.,
+	  life-cycle less than 10000, the threshold should be lessened (e.g.,
  	  to 128 or 256, although it does not have to be power of 2).
  
  config MTD_UBI_BEB_RESERVE
diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index 533b1a4..016ec13 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
@@ -65,7 +65,7 @@ 
   *
   * A: because when writing a sub-page, MTD still writes a full 2K page but the
   * bytes which are no relevant to the sub-page are 0xFF. So, basically, writing
- * 4x512 sub-pages is 4 times slower then writing one 2KiB NAND page. Thus, we
+ * 4x512 sub-pages is 4 times slower than writing one 2KiB NAND page. Thus, we
   * prefer to use sub-pages only for EV and VID headers.
   *
   * As it was noted above, the VID header may start at a non-aligned offset.
diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c
index 17f287d..69fa4ef 100644
--- a/drivers/mtd/ubi/kapi.c
+++ b/drivers/mtd/ubi/kapi.c
@@ -488,7 +488,7 @@  EXPORT_SYMBOL_GPL(ubi_leb_write);
   *
   * This function changes the contents of a logical eraseblock atomically. @buf
   * has to contain new logical eraseblock data, and @len - the length of the
- * data, which has to be aligned. The length may be shorter then the logical
+ * data, which has to be aligned. The length may be shorter than the logical
   * eraseblock size, ant the logical eraseblock may be appended to more times
   * later on. This function guarantees that in case of an unclean reboot the old
   * contents is preserved. Returns zero in case of success and a negative error
@@ -571,7 +571,7 @@  EXPORT_SYMBOL_GPL(ubi_leb_erase);
   *
   * This function un-maps logical eraseblock @lnum and schedules the
   * corresponding physical eraseblock for erasure, so that it will eventually be
- * physically erased in background. This operation is much faster then the
+ * physically erased in background. This operation is much faster than the
   * erase operation.
   *
   * Unlike erase, the un-map operation does not guarantee that the logical
@@ -590,7 +590,7 @@  EXPORT_SYMBOL_GPL(ubi_leb_erase);
   *
   * The main and obvious use-case of this function is when the contents of a
   * logical eraseblock has to be re-written. Then it is much more efficient to
- * first un-map it, then write new data, rather then first erase it, then write
+ * first un-map it, then write new data, rather than first erase it, then write
   * new data. Note, once new data has been written to the logical eraseblock,
   * UBI guarantees that the old contents has gone forever. In other words, if an
   * unclean reboot happens after the logical eraseblock has been un-mapped and
diff --git a/drivers/mtd/ubi/scan.c b/drivers/mtd/ubi/scan.c
index dc5f688..aed19f3 100644
--- a/drivers/mtd/ubi/scan.c
+++ b/drivers/mtd/ubi/scan.c
@@ -231,7 +231,7 @@  static struct ubi_scan_volume *add_volume(struct ubi_scan_info *si, int vol_id,
   * case of success this function returns a positive value, in case of failure, a
   * negative error code is returned. The success return codes use the following
   * bits:
- *     o bit 0 is cleared: the first PEB (described by @seb) is newer then the
+ *     o bit 0 is cleared: the first PEB (described by @seb) is newer than the
   *       second PEB (described by @pnum and @vid_hdr);
   *     o bit 0 is set: the second PEB is newer;
   *     o bit 1 is cleared: no bit-flips were detected in the newer LEB;
@@ -452,7 +452,7 @@  int ubi_scan_add_used(struct ubi_device *ubi, struct ubi_scan_info *si,
  
  		if (cmp_res & 1) {
  			/*
-			 * This logical eraseblock is newer then the one
+			 * This logical eraseblock is newer than the one
  			 * found earlier.
  			 */
  			err = validate_vid_hdr(vid_hdr, sv, pnum);
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index f64ddab..ee7b1d8 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -350,7 +350,7 @@  static void prot_queue_add(struct ubi_device *ubi, struct ubi_wl_entry *e)
   * @max: highest possible erase counter
   *
   * This function looks for a wear leveling entry with erase counter closest to
- * @max and less then @max.
+ * @max and less than @max.
   */
  static struct ubi_wl_entry *find_wl_entry(struct rb_root *root, int max)
  {