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

Brian Norris computersforpeace at gmail.com
Tue Apr 1 05:33:49 EDT 2014


On Tue, Apr 01, 2014 at 05:29:54AM +0000, Pekon Gupta wrote:
> >From: David Mosberger [mailto:davidm at egauge.net]
> >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.

I think what Gerhard was asking and what Pekon is asking for are
different. I don't think Gerhard's suggestion is realistic (that users
would change ECC modes mid-use). But Pekon's following concern (which I
share) sounds more reasonable, I think, for init-time configuration.

> 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.

I actually don't think his patches would abruptly change any working
driver, since it only utilizes on-die ECC if the chip already had it
enabled (and existing drivers would thus not function properly). But I
don't think it's the best design, since it assumes that the flash's
initial state is the expected mode of operation.

> So, instead of re-sending patches it's important to discuss the changes.

Yes, please.

Brian



More information about the linux-mtd mailing list