Re: [PATCH v3 09/10] mtd: nand: utilize oob_required parameter

[Shmulik Ladkani <shmulik.ladkani@gmail.com>]

Hi Brian,

On Mon, 30 Apr 2012 12:59:52 -0700 Brian Norris <computersforpeace@gmail.com> wrote:
> On Sun, Apr 29, 2012 at 5:47 AM, Shmulik Ladkani
> <shmulik.ladkani@gmail.com> wrote:
> > On Fri, 27 Apr 2012 18:29:53 -0700 Brian Norris <computersforpeace@gmail.com> wrote:
> >> Don't read/write OOB if the caller doesn't requre it.
> >
> > Re-thinking this, I think this might be incorrect.
> > Sorry I havn't noticed this earlier.
> >
> > Suppose the nand chip is working in "sequential" (aka "incremental")
> > mode.
> > Meaning, a NAND_CMD_READ0 command is issued, and then adjacent pages are
> > read sequencially, without having to re-issue NAND_CMD_READ0.
> >
> > (see for example the loop within 'nand_do_read_ops', especially the
> > 'sndcmd' variable).
> >
> > In that case, we MUST read the 'oob', because the OOB bytes will always
> > arrive on the bus following the inband data.
> ...
> 
> I see. This is the kind of issue I was alluding to back in v2:
> 
> "For instance, is there any sort of hardware that expects the whole
> page + OOB to be read via chip->read_buf() for all reads..."

Yep. Charmed by the 'oob_required' idea, I sensed this potential trouble
too late :)

This is more delicate than I originally thought.

I completely agree with your statement "please do NOT accept any of
the patches 3-10 without an explicit ACK from someone who knows the driver".

I was querying regarging the adaptation of existing drivers since the
patchset looked "incomplete".

However if this attempt gets too complicated, I guess the compromise of
submitting just the infrastructure changes (patches 1 and 2) is probably
reasonable. Let the maintainers decide.

Regards,
Shmulik