linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Leo Barnes <barnes.leo@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Expected capabilities of MTD-layer drivers?
Date: Mon, 31 May 2010 10:02:35 +0300	[thread overview]
Message-ID: <1275289355.2678.29.camel@localhost> (raw)
In-Reply-To: <AANLkTil3v1loUPrHZKHGe36FUqxYOTp52PDtXd9jAGpq@mail.gmail.com>

On Mon, 2010-05-31 at 08:51 +0200, Leo Barnes wrote:
> Hello!
> 
> I have recently run into trouble with what I now believe is a buggy
> driver in the MTD-layer. The driver in question is the msm_nand driver
> in the MSM android kernel:
> 
> http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=drivers/mtd/devices/msm_nand.h;h=b5e6293e929ab0cab0fc1c1b35a5526915b64086;hb=HEAD
> 
> It seems to be written with YAFFS2 entirely in mind, which means that
> when trying to access it in other ways results in errors. So, in order
> to tell if it is in fact the driver that is buggy, I need to find out
> what the expected capabilities of nand_read/nand_read_oob and
> nand_write/nand_write_oob actually are.
> 
> 1. What are the allowed amount of bytes that can be read with
> nand_read? In the driver, this seems to be multiples of the pagesize,
> but I have spotted the UBI driver trying to read 64 byte chunks when
> trying to scan all the EC headers (which fails). When studying the
> OneNAND drivers, an arbitrary amount of bytes seems to be allowed, but
> OneNAND is after all quite different from regular NAND.

MTD interface assumes that arbitrary amount of bytes can be read. I'm
not sure this is a good idea, but this is historical.

> 2. What are the allowed amount of bytes that can be written with
> nand_write/nand_write_oob?

Any amount, but aligned to the min I/O unit size (mtd->writesize).

> 3. When running the mtd_readtest, the test fails on every page on
> every block when it asks the driver to read OOB-data. What is the
> expected behaviour when ops.mode = MTD_OOB_PLACE, ops.datbuf = ops.len
> = 0 and ops.ooblen = mtd->oobsize (64 bytes in this case)? At the
> moment, the driver returns EBADMSG whenever mtd_readtest tries to do
> this.

Sorry, not sure, I do not use OOB and already forgot. But the OneNAND
driver or nand_base.c is a good reference.

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

      reply	other threads:[~2010-05-31  7:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-31  6:51 Expected capabilities of MTD-layer drivers? Leo Barnes
2010-05-31  7:02 ` Artem Bityutskiy [this message]

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=1275289355.2678.29.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=barnes.leo@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).