nand_base - kill chip->oob_poi?

[Brian Norris]

On Wed, Mar 28, 2012 at 3:14 AM, Woodhouse, David
<david.woodhouse at intel.com> wrote:
> On Wed, 2012-03-28 at 11:51 +0200, Thomas Gleixner wrote:
>> On Tue, 27 Mar 2012, Brian Norris wrote:
>> > 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".

Right, HW ECC is working with a HW internal buffer that isn't exposed
to the host in its DMA modes. I can access it via PIO, but that's not
ideal.

>> > 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.

Yes, I guess they still need it. Maybe in places where they would have
used chip->oob_poi, I can replace it with a buffer passed as an
argument, then when that buffer is NULL we fall back to chip->oob_poi,
like the following:

static int nand_read_page_raw_syndrome(... uint8_t *buf, uint8_t *oobbuf ...)
{
    ...
    uint8_t *oob = oobbuf ? oobbuf : chip->oob_poi;
    ...
    chip->read_buf(mtd, oob, ...);
    ...
}

> 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.

Right. I'm just concerned with modifying the nand_chip / nand_ecc_ctrl
interfaces enough to work with this hardware while avoiding breaking
existing stuff and keeping the interfaces sane. I have to at least
break the assumption that the {read,write}_page interfaces *always*
will fill/use chip->oob_poi.

Brian