[PATCH 1/2] mtd: nand: add OOB argument to NAND {read, write}_page interfaces

[Bastian Hecht]

2012/4/22 Shmulik Ladkani <shmulik.ladkani at gmail.com>:
> On Thu, 19 Apr 2012 15:06:33 -0700 Brian Norris <computersforpeace at gmail.com> wrote:
>> On Thu, Apr 19, 2012 at 9:50 AM, Mike Dunn <mikedunn at newsguy.com> wrote:
>> > On 04/17/2012 08:44 PM, Brian Norris wrote:
>> I guess this may not be an issue for page read, but I know one use for
>> write_page data+OOB. MLC NAND, for instance, requires that you write
>> *once* to a page, so I introduced ioctl(MEMWRITE) which generically
>> allows page, OOB, or both to be written. This trickles down to the
>> nand_ecc_ctrl.write_page function, I think. There are probably other
>> cases that I'm not really thinking of right now.
>
> From MTD user's perspective, mtd_read() and mtd_write() interfaces
> do not expose the OOB to the user at all.
>
> OTHO, mtd_read_oob() and mtd_write_oob() allow the user to read/write
> either the OOB on its own (NULL 'ops->datbuf'), or the page data along
> with its accompanying OOB (non-null 'ops->datbuf' and 'ops->oobbuf').
>
> There are few users of the mtd_read_oob/mtd_write_oob interfaces that
> provide a non-null 'ops->datbuf':
> - nand_bbt.c
> - MEMWRITE mtdchar ioctl
> - mtdswap.c
> - sm_ftl.c
> - yaffs2 (out-of-tree)

Following this thread, I wondered how mtd_write_oob is meant to work.
The sh_flctl code simply writes the OOB data 1 to 1 into the oob area
of the nand chip when using hardware ECC. So when reading this, it
should result in a corrupted page. Is the driver meant to OR the ECC
code to the buffer? Then the driver would need a page read and write
it back applying the oob data, no?

Best regards,

 Bastian Hecht

> Regards,
> Shmulik
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/