Possible error in doc_write_ecc

[Patrick Higgins]

On Sat, 3 Jun 2000, David Woodhouse wrote:

> > So far I've only be looking at syndrome output of reads, but I've started
> > to look into writes as well, and it looks like doc_write_ecc doesn't
> > parallel what's in the docs.  Perhaps there's a reason, but I thought I'd
> > point it out:
> 
> Look in the NFTL code. It's immediately followed by a doc_write_oob to
> write the syndromes which were calculated and put in the buffer.
> 
> I don't particularly like the abstraction between 'driver' and 'user' code
> there - offer me a cleaner one and I'll be happy.
> 
> --
> dwmw2

OK, I think I'm beginning to understand how things are laid out, but it's
pretty confusing without good reason.  By including ECC information into
struct mtd_info I assume you hoping that two different types of hardware
might use the same ECC scheme and we could write user modules to implement
the ECC without knowing the exact hardware in question.  I'm not an expert
in the area, but after having looked into the ECC field a bit, I don't
think this sort of thing will happen frequently, if ever.  Rather than
cluttering up the entire interface, it would probably be best to just have
hardware which has a common ECC mechanism work out sharing code on their
own.

Basically, higher levels would just call mtd_info.read() and accept the
results as valid, unless an error value is returned.  They really
shouldn't have to worry about what the hardware did or didn't do to try to
correct the error, but only with the results.

-Patrick


To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org