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

[Mike Dunn <mikedunn@newsguy.com>]

Hi Brian,

On 04/17/2012 08:44 PM, Brian Norris wrote:

> Now, in future revisions of this ASIC, it may be possible to access
> OOB via DMA as well, but even if this happens, it doesn't make a lot
> of sense on this hardware to *always* pull OOB data. 


No, it doesn't.  In fact, I'm not aware of any code within or on top of mtd that
does anything with the oob data when a page is read.  If oob is needed,
mtd_read_oob() is used.  Coincidentally, I recxently discovered that my docg4
driver is technically broken because I don't fill the chip->oob_poi buffer when
I read a page, but it never caused a problem with UBI/ubifs.  And the mtdutils
are fine because mtdchar requires use of an ioctl for oob access, and the
handler for this ioctl uses mtd_read_oob().


> As mentioned
> previously, most normal applications (i.e., UBI(FS)) don't need to
> access this OOB data at all, so it seems silly to go to extra work to
> have the DMA controller return it to the MTD/NAND layers. I'm not
> familiar with the OOB/ECC schemes on enough other hardware to
> determine whether other drivers could make use of this same
> optimization. It would require hardware with internal buffers for
> error correction and an access mode that easily returns page data
> only...


The Freescale nand controllers might fall into this category.  Hardware handles
error detction *and* correction, so there's no need to read the oob at all if
it's not needed.  And fsl_ifc_nand was just mainlined, BTW.

Thanks,
Mike