(Trim the CC list) Hi Huang, On Wed, Dec 04, 2013 at 01:41:25PM -0800, Brian Norris wrote: > I'd like to follow up on this question, since you didn't answer it, and > it's still relevant, since we haven't yet merged your GPMI DT binding > (it's queued for the next merge window): > > On Mon, Nov 18, 2013 at 10:50:59AM -0800, Brian Norris wrote: > > Do you have a good reason why you needed GPMI NAND to choose the ECC > > configuration (a la "miminum ECC") instead of fully specifying your ECC > > selection in device tree? I recall most of your arguments were about > > using an ECC strength that leaves room for user data in OOB (e.g., with > > JFFS2). But you could have done the same thing by creating a proper DT > > property to describe the desidered ECC strength, with no real > > disadvantage, right? > > I'll rephrase it: why can't/don't you define a GPMI binding for the > actual ECC level, like: > > fsl,nand-ecc-strength and fsl,nand-ecc-sector > > ? > > Then, you could still default to the old geometry if these properties > aren't present, and you don't have to rely on Linux auto-detecting ECC > properties for non-ONFI chips. Ping? Do you have any comment here? It seems like a more precise DT binding could still be useful for GPMI NAND. Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
