Hi Pekon, Sorry, I'm revisiting your patch series a bit late. There are a few factors that contributed to this, though. 1. This patch series talks extensively about U-Boot. U-Boot is not my interest, nor should it be the focus of kernel (driver) development. Any work done here should be framed in the kernel driver context. [1] 2. You have previously CC'd me on U-Boot patches. Or at least, I think so. More about this in the next point... 3. The U-Boot source code structure is rather similar to pieces of Linux subsystems. So without additional effort, it is hard to discern whether a patch is intended for Linux MTD or U-Boot MTD. 4. You cross-posted to both the U-Boot and Linux-MTD mailing lists. So the sum of all this is that I ignored these patches at first, as they weren't clearly intended for me. On Fri, Dec 13, 2013 at 02:42:56PM +0530, Pekon Gupta wrote: > As there were parallel set of patches running between u-boot and kernel. I don't know what patches you're talking about. > hence, some patch-sets caused regression for OMAP3x platforms when booting "Hence" is not the right word. The previous sentence doesn't imply that there were regressions. > using u-boot specifically for ecc-schemes (like BCH4_SW). Huh? What does "specifically for ecc-schemes" mean? You mean that only some schemes had regressions? Can you be more specific? What are these regressions? The rest of this cover letter (and most of the patch descriptions) describes the configurations and testing (which is all very good, don't get me wrong), with a lot of focus on things I don't follow (namely, U-Boot), but you omit many of the important details, like * What is the regression? I honestly don't see a description of the actual regression. (I can read the code to intuit that, but what's the point of your pages of description if it doesn't mention this?) Please give some logical description of the problem * What are the effects of the regression? ECC bytes in the wrong place, so you see correction failures/corruption? JFFS2 failures? (The "oobfree" changes, for instance, should only affect something like JFFS2.) * What Linux commit caused the regression? * Should this patch set be marked for -stable? And for what kernel release? (the previous question would help answer this) > Hence this patch series fixes those regressions, and tests complete [...] snip I'm preparing a 3.14 pull request soon, and since you seem committed to fixing and properly testing a known regression here, I'd like to see this go in. But given the late timing and the unanswered questions, I think it's unlikely to go in -rc1. Perhaps I can send a later pull request if we can get it together properly. So I'd like to first of all get a few answers to my questions, and then I think we might want to refresh this patch series with a little better commit messages and perhaps a separate documentation file (not necessarily in the same patch series, as the fix is more urgent). Brian [1] For instance, rather than saying "the ECC layout doesn't match U-Boot", you should probably describe what the intended ECC layout should look like and show that Linux does not match it. Perhaps it's time for some better documentation, like Ezequiel stashed under Documentation/mtd/nand/ for pxa3xx. You could also take some cues from Huang's comments on ECC layouts, etc., in gpmi-nand.c. -- 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
