linux-kernel - Re: [PATCH] Blackfin BF54x NAND Flash Controller driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8bd0f97a0709031057u1f4608f6y36bd20a8f6910a32@mail.gmail.com>
Date:	Mon, 3 Sep 2007 13:57:59 -0400
From:	"Mike Frysinger" <vapier.adi@...il.com>
To:	bryan.wu@...log.com
Cc:	"David Woodhouse" <dwmw2@...radead.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH] Blackfin BF54x NAND Flash Controller driver

On 9/3/07, Bryan Wu <bryan.wu@...log.com> 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

> +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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/