[PATCH] mtd: nandbiterrs: Support for NAND biterrors test on platforms without raw write

[Boris Brezillon]

Hi Iwo,

On Mon, 9 May 2016 14:09:46 +1000
Iwo Mergler <iwo.mergler at netcommwireless.com> wrote:

> Hi Boris,
> 
> 
> I have to admit that your NACK surprised me.
> 
> My patch removes an unnecessary use of raw write
> from the test. It was only there because of my
> original implementation, which I now consider
> mistaken.

Sorry, I didn't look at the diff itself, and focused on the commit
message :-/. Indeed, using normal write in the overwrite test should be
harmless, but I still think that all controller should properly
implement raw access functions, otherwise the "incremental errors"
test is irrelevant (you'll overwrite ECC bytes along with in-band
data, and will end up with more bitflips than you expected).

> 
> I fully agree with you that raw write should
> be implemented, despite the impediments.
> Although I have seen at least one NAND controller
> that always computed and wrote ECC, with no way
> for software to circumvent it.

Hm, I was told that so many times and each time I had a closer look it
appeared to be untrue, so I tend to be skeptical on these kind of
statement now. Could you tell me more about this controller?

> 
> Could you please elaborate a little why you
> don't want a test module to work with incomplete
> MTD drivers?

As I said, this test module will only work in overwrite mode when the
controller does not support raw accesses.

> Is that supposed to be motivating
> driver writers for better implementations? ;-)

Yes, partly, and also because it's really helpful when you need to debug
NAND stuff.

Honestly, I'd rather see NAND implementations return -ENOTSUPP when
they do not support raw accesses than pretending they are.

> 
> Would you accept the patch if I remove the comment
> about data reshuffling drivers? It's not required
> for the patch and, as you correctly pointed out,
> now inaccurate.

At least rework it to mention that you're only modifying the overwrite
test, and that writing in normal mode in this case is harmless.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com