nand_base - kill chip->oob_poi?

[Woodhouse, David]

On Wed, 2012-03-28 at 11:51 +0200, Thomas Gleixner wrote:
> On Tue, 27 Mar 2012, Brian Norris wrote:
> 
> > Hi,
> > 
> > I'm looking to support a new NAND hardware controller, and it doesn't
> > support OOB read/write for its fastest modes of operation, since most
> > normal activity (i.e., UBI(FS)) doesn't need OOB. So I'm trying to
> 
> And how is ECC working for that "normal" activity ?
> 
> Using NAND w/o ECC is doomed for fail.

I was assuming that the controller *used* the OOB area for hardware ECC,
but just didn't support letting the *host* access the OOB area "in its
fastest modes of operation".

> > My plan looked something like the following:
> > - avoid using chip->oob_poi explicitly if at all possible
> > - pass both buf and oob pointers to the various {read,write}_page
> >   interfaces (in nand_chip and in nand_ecc_ctrl)
> > - allow oob to be NULL, which would imply that the API call only
> >   needed the in-band data

And presumably the swecc/hwecc cases would still use either oob_poi or
their own buffer, since they have to put the syndrome *somewhere* after
calculating it... but those are only for those controllers which *use*
the swecc/hwecc support.

I don't think it matters that your plan "conflicts" with the ECC
implementations that you wouldn't be able to to use on this hardware
anyway.

I agree that adding more interfaces would probably not be a good idea;
this code is tangled enough already.


-- 
                   Sent with MeeGo's ActiveSync support.

David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4370 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120328/b9791a58/attachment.bin>