Faraday's FTNANDC024 NAND flash controller supports SLC, MLC and TLC flash.
Because Faraday's official Linux driver for this controller is designed to
show off (or exercise) the capabilities of their hardware, it is kludged to
support all 3 kinds of NAND flash as well.  Supporting TLC flash is particularly
burdensome because of the non-power-of-2 block sizes, which the generic NAND
layer in linux-3.3 (the kernel version to which Faraday's driver applies) does
not support at all.  Faraday's solution was to apply a very ugly patch to the
generic NAND code; this patch is contained in the tarball with their driver.

In contrast, my own (Mychaela Falconia's) reimplementation of the FTNANDC024
driver is designed primarily for SLC flash.  SLC flash support is all that's
needed for my current employer's use of this FTNANDC024 controller in their
product, but my driver will probably work for MLC flash too, provided that the
flash is not *too* nasty.  I have heard that "some" (all?) "modern" MLC/TLC
flashes require data scrambling/randomization; FTNANDC024 hardware includes
this feature, but my driver keeps it disabled.  Enabling the scrambler would
cause other nastiness as explained below, and I don't have the incentive to
implement the ugly workarounds that would be needed.  I don't support
non-power-of-2 block sizes either, so I assume it means no TLC support.

Blank page handling
===================

If a given NAND page is blank in that it has not been written to since the
block it resides in has been erased, high level MTD software (JFFS2, UBI/UBIFS
etc) generally expects that it will return all 0xFF bytes and not an error when
read.  This condition was trivially satisfied in the good old days of friendly
SLC flashes that required no more than 1 bit of ECC correctability, dumb
controllers that stood out of the way and software-based Hamming ECC: the
driver would issue a Read Page command to the NAND chip, the chip would return
all 0xFF bytes (if a single bit somewhere read as 0, software ECC would correct
it to a 1), and having all 0xFF bytes in both the data and OOB areas was the
same as what would result from explicitly writing a page with all 0xFF bytes.

But modern flashes and controllers are giving us extra grief.  Problem 1: BCH
ECC hardware is often designed in such a way that the ECC bits for a page of
all 0xFF bytes are NOT 0xFF.  FTNANDC024 has a register bit feeding some XOR
gates which allows one of two behaviours to be selected.  In the classic mode,
the bits going into the ECC engine are not inverted, the ECC bits for a page of
all 0xFF bytes are not all 1s, and if a blank (never written) page is read, the
controller throws up an unrecoverable ECC error.  In the "inverted" mode the
XOR gates in the data path fix things up so that when all data bytes are 0xFF,
all ECC bytes are also 0xFF, and everyone is happy.

Problem 2: I have heard that some (all?) MLC/TLC flashes require data
scrambling/randomization.  FTNANDC024 has a scrambler that can be enabled or
disabled by another register bit, but think what it does to the reading of
blank (unwritten) pages.  If the inverter is disabled, the controller will flag
an unrecoverable ECC error; if the inverter is enabled, no ECC error will occur,
but the data returned to the host would be 0xFF passed through the descrambler,
i.e., it will look like random garbage.  JFFS2/UBI/UBIFS would not be too happy.

My current driver for the FTNANDC024 configures the controller with scrambling
disabled and data inversion enabled.  This configuration works for SLC and
(hopefully) the "nicer" MLC flashes that don't require data randomization, and
satisfies the blank pages requirement without any extra pain.  However, if
someone needs to use this controller with a flash chip that does require data
randomization, then the only solution I can think of would be to disable the
inverter, enable the scrambler, and have special code in the driver: whenever
the controller returns a hard ECC error on a read, re-read the same page with
the scrambler disabled to see if it's blank.  Very ugly, hence I refuse to do
it until and unless an actual need arises, rather than merely hypothetical.