| Message ID | 4BE23A6F.1010406@renesas.com |
|---|---|
| State | New, archived |
| Headers | show |
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
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?
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.
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.
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.
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) {
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(-)