public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Adrian Hunter <adrian.hunter@nokia.com>
Cc: Rohit Hagargundgi <h.rohit@samsung.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] [MTD] Flex-OneNAND support
Date: Wed, 4 Mar 2009 08:50:55 -0800	[thread overview]
Message-ID: <20090304085055.c9de6cbb.akpm@linux-foundation.org> (raw)
In-Reply-To: <49AE6907.1080702@nokia.com>

On Wed, 04 Mar 2009 13:41:59 +0200 Adrian Hunter <adrian.hunter@nokia.com> wrote:

> Andrew Morton wrote:
> >> ...
> >>
> >> +static loff_t flexonenand_get_addr(struct onenand_chip *this, int block)
> >> +{
> >> +	loff_t ofs = 0;
> >> +	int die = 0, boundary;
> >> +
> >> +	if (ONENAND_IS_DDP(this) && block >= this->density_mask) {
> >> +		block -= this->density_mask;
> >> +		die = 1;
> >> +		ofs = this->diesize[0];
> >> +	}
> >> +
> >> +	boundary = this->boundary[die];
> >> +	ofs += block << (this->erase_shift - 1);
> >> +	if (block > (boundary + 1))
> >> +		ofs += (block - boundary - 1) << (this->erase_shift - 1);
> > 
> > Both `block' and `boundary' have 32-bit types.  Are you sure that the
> > left-shift cannot overflow?
> 
> Only very recently has MTD supported sizes greater than 32 bits internally
> for any type of flash.  The external APIs (ioctls) are still 32-bit based.
> 
> For this driver, supporting sizes over 32-bits is a separate issue - and
> may never be needed.

So it doesn't support files >4G?  What's the max device size (now and
projected)?

> >> +	return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
> >> +}
> > 
> > I wonder what the heck EUCLEAN was invented for and whether MTD's
> > extensive use of it is appropriate.
> 
> UBI uses it to detect bit-flips so that data can be moved before it
> can no longer be read.  So it is pretty much essential for flash
> memories.

That's not the point.

My point is: for what purpose was EUNCLEAN created by whoever created
it and, given that, is its use by MTD appropriate?  Because it does
appear that this gets returned all the way to userspace sometimes.

  reply	other threads:[~2009-03-04 16:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-03  6:36 [PATCH 1/3] [MTD] Flex-OneNAND support Rohit Hagargundgi
2009-03-03 20:49 ` Andrew Morton
2009-03-04 11:41   ` Adrian Hunter
2009-03-04 16:50     ` Andrew Morton [this message]
2009-03-04 23:47       ` Kyungmin Park
2009-03-04 23:55         ` Andrew Morton
2009-03-05  3:43           ` Kyungmin Park
2009-03-05  4:46             ` Amit Kumar Sharma
2009-03-05 13:38       ` Adrian Hunter
2009-03-05 14:46         ` Artem Bityutskiy
2009-03-05 19:13         ` Andrew Morton
2009-03-05 18:18   ` Rohit Hagargundgi

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=20090304085055.c9de6cbb.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=adrian.hunter@nokia.com \
    --cc=h.rohit@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --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