Re: [PATCH v2] hw/block/nand: Decommission the NAND museum

[Peter Maydell]

On Tue, 15 Sep 2020 at 18:52, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> This is the QEMU equivalent of this Linux commit (but 7 years later):
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7025a43a9da2
>
>     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 some of the iron age ones are transferred to the regular NAND
>     depot. Namely, only those which have unique device IDs are
>     transferred, and the ones which have conflicting device IDs are
>     removed.
>
> The machine using this device are:
> - axis-dev88
> - tosa (via tc6393xb_init)
> - spitz based (akita, borzoi, terrier)
>
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> Peter, as 4 of the 5 machines are ARM-based, can this go via your tree?
> ---
>  hw/block/nand.c | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/hw/block/nand.c b/hw/block/nand.c
> index 5c8112ed5a4..5f01ba2bc44 100644
> --- a/hw/block/nand.c
> +++ b/hw/block/nand.c
> @@ -138,7 +138,7 @@ static void mem_and(uint8_t *dest, const uint8_t *src, 
> size_t n)
>  # define ADDR_SHIFT            16
>  # include "nand.c"
>
> -/* Information based on Linux drivers/mtd/nand/nand_ids.c */
> +/* Information based on Linux drivers/mtd/nand/raw/nand_ids.c */
>  static const struct {
>      int size;
>      int width;
> @@ -154,15 +154,14 @@ static const struct {
>      [0xe8] = { 1,      8,      8, 4, 0 },
>      [0xec] = { 1,      8,      8, 4, 0 },
>      [0xea] = { 2,      8,      8, 4, 0 },
> -    [0xd5] = { 4,      8,      9, 4, 0 },
>      [0xe3] = { 4,      8,      9, 4, 0 },
>      [0xe5] = { 4,      8,      9, 4, 0 },
> -    [0xd6] = { 8,      8,      9, 4, 0 },
>
> -    [0x39] = { 8,      8,      9, 4, 0 },
> -    [0xe6] = { 8,      8,      9, 4, 0 },
> -    [0x49] = { 8,      16,     9, 4, NAND_BUSWIDTH_16 },
> -    [0x59] = { 8,      16,     9, 4, NAND_BUSWIDTH_16 },
> +    [0x6b] = { 4,        8,        9, 4, 0 },
> +    [0xe3] = { 4,        8,        9, 4, 0 },
> +    [0xe5] = { 4,        8,        9, 4, 0 },

This line adds an entry for 0xe5, but there is already one
further up in the array (you can see it in this hunk).

More generally, it doesn't seem to match the referenced
kernel commit, which deletes 14 lines and adds 5
(which are a subset of the 14 deleted, really, so
they probably show up for us as "9 deletions" since
we don't have the #ifdef...#endif the kernel does).

> +    [0xd6] = { 8,        8,        9, 4, 0 },
> +    [0xe6] = { 8,        8,        9, 4, 0 },
>
>      [0x33] = { 16,     8,      9, 5, 0 },
>      [0x73] = { 16,     8,      9, 5, 0 },

thanks
-- PMM