All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Adrian Hunter <ext-adrian.hunter@nokia.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [RFC] [PATCH] [MTD] Update internal API to support 64-bit device size
Date: Fri, 14 Nov 2008 13:54:33 +0200	[thread overview]
Message-ID: <1226663673.16925.88.camel@sauron> (raw)
In-Reply-To: <4912EE49.4070202@nokia.com>

There are 2 compilation warnings:

fs/jffs2/erase.c: In function ‘jffs2_erase_failed’:                                                                                                                      
fs/jffs2/erase.c:178: warning: comparison is always true due to limited range of data type                                                                               
fs/jffs2/erase.c: In function ‘jffs2_erase_callback’:                                                                                                                    
fs/jffs2/erase.c:212: warning: format ‘%08x’ expects type ‘unsigned int’, but argument 2 has type ‘u_int64_t’                                                            

And the first one points to a real problem.

> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index eae26bb..139aeb7 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -15,6 +15,8 @@
>  #include <linux/mtd/compatmac.h>
>  #include <mtd/mtd-abi.h>
>  
> +#include <asm/div64.h>
> +
>  #define MTD_CHAR_MAJOR 90
>  #define MTD_BLOCK_MAJOR 31
>  #define MAX_MTD_DEVICES 32
> @@ -25,16 +27,16 @@
>  #define MTD_ERASE_DONE          0x08
>  #define MTD_ERASE_FAILED        0x10
>  
> -#define MTD_FAIL_ADDR_UNKNOWN 0xffffffff
> +#define MTD_FAIL_ADDR_UNKNOWN -1LL

OK, but look at the 'jffs2_erase_failed()' function:

--------------------------------------------------------------
static void jffs2_erase_failed(struct jffs2_sb_info *c, struct jffs2_eraseblock *jeb, uint32_t bad_offset)
{
        /* For NAND, if the failure did not occur at the device level for a
           specific physical page, don't bother updating the bad block table. */
        if (jffs2_cleanmarker_oob(c) && (bad_offset != MTD_FAIL_ADDR_UNKNOWN)) {
                /* We had a device-level failure to erase.  Let's see if we've
                   failed too many times. */
                if (!jffs2_write_nand_badblock(c, jeb, bad_offset)) {
                        /* We'd like to give this block another try. */
... etc ...
--------------------------------------------------------------

bad_offs is uint32_t, and bad_offset != -1LL is always true, which is
a problem.

> +static inline u_int32_t mtd_div_by_ws(u_int64_t sz, struct mtd_info
> *mtd)
> +{
> +	if (mtd->writesize_shift)
> +		return sz >> mtd->writesize_shift;
> +	do_div(sz, mtd->writesize);
> +	return sz;
> +}

I would introduce mtd->writesize_mask instead of calculating it, because
it is presumably more optimal.

> +
> +static inline u_int32_t mtd_mod_by_ws(u_int64_t sz, struct mtd_info
> *mtd)
> +{
> +	if (mtd->writesize_shift)
> +		return sz & ((1 << mtd->writesize_shift) - 1);
> +	return do_div(sz, mtd->writesize);
> +}

Ditto.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

  reply	other threads:[~2008-11-14 11:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-06 13:16 [RFC] [PATCH] [MTD] Update internal API to support 64-bit device size Adrian Hunter
2008-11-14 11:54 ` Artem Bityutskiy [this message]
2008-11-14 13:27   ` Adrian Hunter
2008-11-14 12:05 ` 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=1226663673.16925.88.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=dwmw2@infradead.org \
    --cc=ext-adrian.hunter@nokia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.