[REV3] mtd: nand: Prepare for Micron on-die ECC controller support.

[Gupta, Pekon]

Hi David,

>From: David Mosberger [mailto:davidm at egauge.net]
>>On Mon, Mar 31, 2014 at 1:45 PM, Gerhard Sittig <gsi at denx.de> wrote:
>
>> Isn't there the ONFI SETFEATURE request?  And don't you use this
>> very request to disable and enable chip internal ECC support, to
>> get the raw (uncorrected) bits after bitflips were detected?  So
>> I understand that there is support to enable this mode at will,
>> and we already have (or will have) code to do so.
>>
>> If we consider disabling on-die-ECC support when we find it
>> enabled and know it's not what the user wants to run, then the
>> next logical step might be to support enabling this feature if
>> the user wants it and the chip doesn't have it enabled at this
>> point in time.
>>
>> So I guess the buffers should get allocated as soon as the chip
>> supports on-die-ECC.  (While the allocation should only get
>> introduced in the phase where the raw-read and bitflip count gets
>> added.)
>
>The ECC-mode of the driver never changes.
>Sure, what you describe could be implemented as an additional feature
>in the future (I don't have any plans to do so since it makes little sense to
>me, as no other ECC-mode uses the layout of the on-die-controller).
>
>To be honest, I'm a bit confused: on the one hand, you're asking me to
>simplify the patches into smaller pieces, on the other you seem to ask
>for new features.
>
I too would like to see ECC-mode selection based on user's choice.
So there should be mechanism to enable/disable this feature based on
DT or platform-data. And onfi_set_feature() is the correct thing to use.
This would make your patches more simple, without disturbing the generic
frame-work. If you patch causes any regression, or abruptly changes
behavior of any working driver, then it's less likely to get accepted.
So, instead of re-sending patches it's important to discuss the changes.


with regards, pekon