mtd locking

[Brian Norris]

Hi,

On Sun, May 29, 2016 at 06:17:02PM +0200, Richard Weinberger wrote:
> Am 29.05.2016 um 17:53 schrieb Matthias Auchmann:
> > By intended you mean it's wrong and we know, but it's still wrong, right?
> 
> I'd say lazy. Sometimes counters don't need to be exact.
> Having exact counting is expensive. See network stack.
> 
> I'm not sure what the exact reasons in the ECC error counting
> case are.
> Maybe Brian or Boris can tell more.

Boris correctly explained things. And several people have noticed, but
few solutions have been attempted.

The only thing I'd add: I suspect the MTD char device APIs haven't
gotten as much love because they aren't as useful. Most users have found
better utility by working through JFFS2, UBI/UBIFS, etc., since there's
just so much that a raw MTD doesn't really solve for you, especially
when you start talking about the type of device where you care about
bitflips (i.e., NAND).

You're more likely to get away fine with raw MTD on NOR flash, but then
you don't care about ECCGETSTATS there anyway.

I think Boris has found use cases where he just wants to talk raw
NAND/MTD, so maybe some of this dynamic is changing.

(And BTW, I realized this is a potential impediment to moving the MTD
tests entirely to user space. They can still work fine in
single-threaded mode, but once you start running multiple instances,
you'll start getting inaccurate stats reports, which will make some
tests think they've failed.)

Brian