Expected capabilities of MTD-layer drivers?

[Artem Bityutskiy]

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 (Артём Битюцкий)