public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: MTD Maling List <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 02/11] mtd: decommission the NAND museum
Date: Tue, 05 Mar 2013 23:32:10 -0800	[thread overview]
Message-ID: <5136F0FA.5080905@gmail.com> (raw)
In-Reply-To: <1362489444-27762-3-git-send-email-dedekind1@gmail.com>


On 03/05/2013 05:17 AM, Artem Bityutskiy wrote:
> From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
>
> The MTD subsystem has its own small museum of ancient NANDs in a form of the
> CONFIG_MTD_NAND_MUSEUM_IDS configuration option. The museum contains stone age
> NANDs with 256 bytes pages, as well as iron age NANDs with 512 bytes per page
> and up to 8MiB page size.
>
> It is with great sorrow that I inform you that the museum is being
> decommissioned. The MTD subsystem is out of budget for Kconfig options and
> already has too many of them, and there is a general kernel trend to simplify
> the configuration menu.
>
> We remove the stone age exhibits along with closing the museum, but the iron
> age ones are transferred to the regular NAND depot, since there is still a
> remote possibility that they may be useful for someone.

Unfortunately, the iron age and modern age exhibits will not survive 
long together. The iron age will conquer the modern, as the exhibits 
that grew up without war have gone soft... OK, I can't draw this analogy 
out much further :)

What I mean to say is: some of the museum IDs that you left will 
conflict with the "current" ones, so that the museum IDs will always win 
out; they will be detected as their museum geometry, not their extended 
ID geometry. See below for examples.

> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> Acked-by: Brian Norris <computersforpeace@gmail.com>

My ack was on the old one (which removed them entirely), not the new one 
:) I'll re-review the other patches quickly and comment if there are any 
other anti-ack's.

> ---
>   drivers/mtd/nand/Kconfig    |    8 --------
>   drivers/mtd/nand/nand_ids.c |   28 ++++++++++------------------
>   2 files changed, 10 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 81bf5e5..0f443ef 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -41,14 +41,6 @@ config MTD_SM_COMMON
>   	tristate
>   	default n
>
> -config MTD_NAND_MUSEUM_IDS
> -	bool "Enable chip ids for obsolete ancient NAND devices"
> -	default n
> -	help
> -	  Enable this option only when your board has first generation
> -	  NAND chips (page size 256 byte, erase size 4-8KiB). The IDs
> -	  of these chips were reused by later, larger chips.

Note the keyword "reused"! Only a few of them were reused though. I 
marked all the repeats below. I don't know what we can do with that, 
though. Can we cut the repeats?

>   config MTD_NAND_DENALI
>           tristate "Support Denali NAND controller"
>           help
> diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
> index f1a799c..44f9db3 100644
> --- a/drivers/mtd/nand/nand_ids.c
> +++ b/drivers/mtd/nand/nand_ids.c
> @@ -22,24 +22,16 @@
>    * extended chip ID.
>    */
>   struct nand_flash_dev nand_flash_ids[] = {
> -
> -#ifdef CONFIG_MTD_NAND_MUSEUM_IDS
> -	{"NAND 1MiB 5V 8-bit",		0x6e, 256, 1, 0x1000, 0},
> -	{"NAND 2MiB 5V 8-bit",		0x64, 256, 2, 0x1000, 0},
> -	{"NAND 4MiB 5V 8-bit",		0x6b, 512, 4, 0x2000, 0},
> -	{"NAND 1MiB 3,3V 8-bit",	0xe8, 256, 1, 0x1000, 0},
> -	{"NAND 1MiB 3,3V 8-bit",	0xec, 256, 1, 0x1000, 0},
> -	{"NAND 2MiB 3,3V 8-bit",	0xea, 256, 2, 0x1000, 0},
> -	{"NAND 4MiB 3,3V 8-bit",	0xd5, 512, 4, 0x2000, 0},
> -	{"NAND 4MiB 3,3V 8-bit",	0xe3, 512, 4, 0x2000, 0},
> -	{"NAND 4MiB 3,3V 8-bit",	0xe5, 512, 4, 0x2000, 0},
> -	{"NAND 8MiB 3,3V 8-bit",	0xd6, 512, 8, 0x2000, 0},
> -
> -	{"NAND 8MiB 1,8V 8-bit",	0x39, 512, 8, 0x2000, 0},
> -	{"NAND 8MiB 3,3V 8-bit",	0xe6, 512, 8, 0x2000, 0},
> -	{"NAND 8MiB 1,8V 16-bit",	0x49, 512, 8, 0x2000, NAND_BUSWIDTH_16},
> -	{"NAND 8MiB 3,3V 16-bit",	0x59, 512, 8, 0x2000, NAND_BUSWIDTH_16},
> -#endif
> +       {"NAND 4MiB 5V 8-bit",          0x6b, 512, 4, 0x2000, 0},
> +       {"NAND 4MiB 3,3V 8-bit",        0xd5, 512, 4, 0x2000, 0},

0xd5 is reused (with a capital 'D'!) as 16 Gbit.

> +       {"NAND 4MiB 3,3V 8-bit",        0xe3, 512, 4, 0x2000, 0},
> +       {"NAND 4MiB 3,3V 8-bit",        0xe5, 512, 4, 0x2000, 0},
> +       {"NAND 8MiB 3,3V 8-bit",        0xd6, 512, 8, 0x2000, 0},
> +
> +       {"NAND 8MiB 1,8V 8-bit",        0x39, 512, 8, 0x2000, 0},

Reused.

> +       {"NAND 8MiB 3,3V 8-bit",        0xe6, 512, 8, 0x2000, 0},
> +       {"NAND 8MiB 1,8V 16-bit",       0x49, 512, 8, 0x2000, NAND_BUSWIDTH_16},

Ditto.

> +       {"NAND 8MiB 3,3V 16-bit",       0x59, 512, 8, 0x2000, NAND_BUSWIDTH_16},

Ditto.

>
>   	{"NAND 16MiB 1,8V 8-bit",	0x33, 512, 16, 0x4000, 0},
>   	{"NAND 16MiB 3,3V 8-bit",	0x73, 512, 16, 0x4000, 0},
>

Brian

  reply	other threads:[~2013-03-06  7:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-05 13:17 [PATCH 00/11] mtd: removals and simplifications Artem Bityutskiy
2013-03-05 13:17 ` [PATCH 01/11] mtd: nand_ids: minor clean-ups Artem Bityutskiy
2013-03-05 13:17 ` [PATCH 02/11] mtd: decommission the NAND museum Artem Bityutskiy
2013-03-06  7:32   ` Brian Norris [this message]
2013-03-06  7:44     ` Artem Bityutskiy
2013-03-06  8:17     ` Artem Bityutskiy
2013-03-05 13:17 ` [PATCH 03/11] arm: defconfigs: lpc32xx_defconfig: remove the museum NAND option Artem Bityutskiy
2013-03-06  8:49   ` Artem Bityutskiy
2013-03-06  9:04     ` Roland Stigge
2013-03-06  9:19       ` Artem Bityutskiy
2013-03-05 13:17 ` [PATCH 04/11] mtd: nand: remove the rtc_from4 driver support Artem Bityutskiy
2013-03-05 13:17 ` [PATCH 05/11] mtd: nand: remove AG-AND support Artem Bityutskiy
2013-03-05 13:17 ` [PATCH 06/11] mtd: nand: remove a bunch of unused commands Artem Bityutskiy
2013-03-05 13:17 ` [PATCH 07/11] mtd: nand: remove NAND_NO_PADDING macro Artem Bityutskiy
2013-03-05 13:17 ` [PATCH 08/11] mtd: nand: remove NAND_COPYBACK macro Artem Bityutskiy
2013-03-05 13:17 ` [PATCH 09/11] mtd: nand: use NAND_HAS_CACHEPROG Artem Bityutskiy
2013-03-05 13:17 ` [PATCH 10/11] mtd: nand: rename the id field of 'struct nand_flash_dev' Artem Bityutskiy
2013-03-05 13:17 ` [PATCH 11/11] mtd: nand: remove few tiny page NAND bits Artem Bityutskiy
2013-03-06  7:11 ` [PATCH 00/11] mtd: removals and simplifications Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5136F0FA.5080905@gmail.com \
    --to=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox