On Mon, 2007-09-03 at 13:57 -0400, Mike Frysinger wrote:
> On 9/3/07, Bryan Wu <[email protected]> wrote:
> > --- a/drivers/mtd/nand/Kconfig
> > +++ b/drivers/mtd/nand/Kconfig
> > @@ -131,6 +131,24 @@ config MTD_NAND_AU1550
> > +config MTD_NAND_BF54X
> > + tristate "NAND Flash support for Blackfin BF54X SoC DSP"
>
> i'd just describe it as "Blackfin on-chip NAND" rather than sticking
> in exact part numbers as i imagine we can extend it down the line
>
> > + This enables the NAND flash controller on the BF54X SoC DPSs
>
> "BF54X SoC DPSs" -> "BF54x SoC DSPs"
>
> > + No board specific support is done by this driver, each board
> > + must advertise a platform_device for the driver to attach.
>
> should mention the module name when built as a module
>
I will get rid of this BF54X and use BF5XX for (BF54x and BF52x and
future processor)
> > +config MTD_NAND_BF54X_HWECC
> > + bool "BF54X NAND Hardware ECC"
> > + depends on MTD_NAND_BF54X
> > + help
> > + Enable the use of the BF54X's internal ECC generator when
> > + using NAND. Early versions of the chip have had problems with
> > + incorrect ECC generation, and if using these, the default of
> > + software ECC is preferable.
>
> rather than advertising this, i'd just keep it in the driver ...
> presumably there are anomaly #'s for when the ECC is wrong, so we can
> make the code depend on those
> -mike
This option is quite common in the NAND driver. If there are anomaly
#'s, code can still depend on those by using hardware_ecc varible. This
option is very useful when someone need software_ecc.
Thanks
- Bryan Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
