Re: [RFC 0/5] fix data+OOB writes, add ioctl

Brian Norris
2011-08-25T17:54:12Z

Hi Ricard,

On Thu, Aug 25, 2011 at 2:33 AM, Ricard Wanderlof
<ricard.wanderlof@axis.com> wrote:
> On Wed, 24 Aug 2011, Brian Norris wrote:
>> On Wed, Aug 24, 2011 at 8:36 AM, Ricard Wanderlof <ricard.wanderlof@axis.com> wrote:
>> Anyway, I believe the relevant patch dependency (from l2-mtd-2.6.git) is:
>>
>>  commit a8ee364bbf14861d5d0af39c4da06c30441895fb
>>  Author: THOMSON, Adam (Adam) <adam.thomson@alcatel-lucent.com>
>>  mtd: nand_base: always initialise oob_poi before writing OOB data
>
> That seems right.

BTW, that patch seems a bit broken to me; I sent a fixup for it:
http://lists.infradead.org/pipermail/linux-mtd/2011-August/037698.html

>> I guessed you would be more likely to get a segmentation fault on a
>> NULL pointer, but I may be wrong.
>
> Something seems to hang at a lower level, because the system becomes
> unresponsive at this point (I can telnet in, but trying to access the flash
> with ls for instance causes the shell to hang).

I think that I had a little bit of the wrong approach. I was doing
some ill advised hacking to the existing write functions. I spun off
my first two patches here as a different series (I believe I CC'd
you); I used a different approach that should make as little impact on
currently working hardware as possible:
http://lists.infradead.org/pipermail/linux-mtd/2011-August/037695.html

> (something seems missing here ...

Acknowledged :)

> I applied the patches as you mentioned, which brought success. Dumping a
> partition with nanddump, then writing it back with nandwrite -o -n results
> in the correct data being written both to the main and oob areas.

Great!

> (Without your inlinend patch, the nandwrite application still hangs after
> Writing to data block 0).

Not quite sure what the hanging is all about - may be related to my
improper use of CMD_SEQIN, then a nand wait function being called
later? - but that's why I've changed my approach.

> So the conclusion would be that this combination of patches does not break
> Peter Wippich's patch.

Thanks a lot for the testing. I think that my first approach still may
easily have unintended consequences, though. I welcome any testing on
my new patch series, and any more systems with broken "noecc" should
be handled through that thread.

Brian