On Thu, Dec 5, 2013 at 11:06 AM, Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, 5 Dec 2013 19:02:22 +0000, Gupta, Pekon wrote: > >> >From: Ezequiel Garcia [mailto:ezequiel.garcia@xxxxxxxxxxxxxxxxxx] >> [...] >> >AFAIK, there's no hardware limitation that would prevent us from setting >> >a per-partition ECC, keep in mind this effort is not reduced to make >> >devicetree accept ECC on the partitions. >> > >> I had some reservations in doing so.. (as mentioned in previous email also [2]) >> I would rather like to understand long term benefits of such implementation. > > The long term benefits is simply to properly handle the hardware > constraints. We have hardware platforms were parts of the NAND *MUST* > use 1-bit ECC to be compatible with the ROM code, and other parts of > the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the > NAND requirements. Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. > Isn't handling hardware constraints properly not a sufficient > motivation for doing something? I'm not convinced your hardware constraints are reasonable or generally useful. But I could be convinced otherwise. >> Also, any constrain due to ROM code, or upgrading from remote can be >> handled using various alternative approaches like [a] and [b]. > > And you're not realizing that these solutions are ugly and impractical? Solution [a] is both ugly and impractical. Solution [b] is only a little ugly but quite practical (you could flesh out a better user-space ECC library, then combine it with nanddump/nandwrite --noecc). Rewriting both the MTD and NAND layers is not exactly practical and may still yield something ugly. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
