[PATCH v7 5/6] ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt

[Gupta, Pekon]

> From: Mark Rutland [mailto:mark.rutland at arm.com]
> > On Fri, Oct 04, 2013 at 08:49:47PM +0100, Pekon Gupta wrote:
> > DT property values for OMAP based gpmc-nand have been updated
> > to match changes in commit:
> > 	6faf096 ARM: OMAP2+: cleaned-up DT support of various ECC
> schemes
> > Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> 
Sorry that's an old commit. I probably missed out updating the commit log.
So please ignore it here, I should remove that from commit log.


> Doesn't this mean these dts were broken between the changes to the
> driver and the changes to the dts?
> 
But the DTS updates are kept separate from driver updates because
- DTS updates go into "Benoit's tree" or "Tony's tree"
- whereas driver updates go into MTD tree.
So, it was suggested in earlier patch revisions that I keep the driver
and the DTS patches separate, so that there is no merge conflict
between the trees when they are finally accepted.


> I think the existing properties need to continue to be supoprted for
> backwards compatibility. The dts can be fixed up to have the preferred
> binding style, but they shouldn't _have_ to be modified to continue to
> function...
> 
However, there should be a way to remove legacy code which can
no longer be maintained. Here following ecc-schemes are such
legacy code, which are neither supported nor encouraged
to use since long time.
- OMAP_ECC_CODE_HAMMING_HW,
- OMAP_ECC_CODE_HAMMING_DEFAULT,
- OMAP_ECC_CODE_HAMMING_HW_ROMCODE

Also backward compatibility is maintained by keeping a common
symbol for all 3 above implementations OMAP_ECC_CODE_HAM1_HW
I don't think there is a point to continue keeping these  symbols
in kernel driver if they are unused, and make driver bulky and unreadable.

In actual it shouldn't matter to user what symbols I use inside
the driver, what matters is backward compatibility right ?


with regards, pekon