* linux-next: manual merge of the l2-mtd tree with Linus' tree
@ 2013-03-19 0:19 Stephen Rothwell
0 siblings, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2013-03-19 0:19 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: linux-next, linux-kernel, Brian Norris, David Woodhouse, Huang Shijie
[-- Attachment #1: Type: text/plain, Size: 17108 bytes --]
Hi Artem,
Today's linux-next merge of the l2-mtd tree got a conflict in
drivers/mtd/nand/nand_ids.c between commit 5bc7c33ca93a ("mtd: nand:
reintroduce NAND_NO_READRDY as NAND_NEED_READRDY") from Linus' tree and
commit dc656666c450 ("mtd: add 4 Toshiba nand chips for the full-id
case") from the l2-mtd tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/mtd/nand/nand_ids.c
index 9c61238,1c242cc..0000000
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@@ -10,163 -10,150 +10,153 @@@
*/
#include <linux/module.h>
#include <linux/mtd/nand.h>
- /*
- * Chip ID list
- *
- * Name. ID code, pagesize, chipsize in MegaByte, eraseblock size,
- * options
- *
- * Pagesize; 0, 256, 512
- * 0 get this information from the extended chip ID
- + 256 256 Byte page size
- * 512 512 Byte page size
- */
- struct nand_flash_dev nand_flash_ids[] = {
+ #include <linux/sizes.h>
+
+ #define LP_OPTIONS NAND_SAMSUNG_LP_OPTIONS
+ #define LP_OPTIONS16 (LP_OPTIONS | NAND_BUSWIDTH_16)
+
+#define SP_OPTIONS NAND_NEED_READRDY
+#define SP_OPTIONS16 (SP_OPTIONS | NAND_BUSWIDTH_16)
+
- #ifdef CONFIG_MTD_NAND_MUSEUM_IDS
- {"NAND 1MiB 5V 8-bit", 0x6e, 256, 1, 0x1000, SP_OPTIONS},
- {"NAND 2MiB 5V 8-bit", 0x64, 256, 2, 0x1000, SP_OPTIONS},
- {"NAND 4MiB 5V 8-bit", 0x6b, 512, 4, 0x2000, SP_OPTIONS},
- {"NAND 1MiB 3,3V 8-bit", 0xe8, 256, 1, 0x1000, SP_OPTIONS},
- {"NAND 1MiB 3,3V 8-bit", 0xec, 256, 1, 0x1000, SP_OPTIONS},
- {"NAND 2MiB 3,3V 8-bit", 0xea, 256, 2, 0x1000, SP_OPTIONS},
- {"NAND 4MiB 3,3V 8-bit", 0xd5, 512, 4, 0x2000, SP_OPTIONS},
- {"NAND 4MiB 3,3V 8-bit", 0xe3, 512, 4, 0x2000, SP_OPTIONS},
- {"NAND 4MiB 3,3V 8-bit", 0xe5, 512, 4, 0x2000, SP_OPTIONS},
- {"NAND 8MiB 3,3V 8-bit", 0xd6, 512, 8, 0x2000, SP_OPTIONS},
-
- {"NAND 8MiB 1,8V 8-bit", 0x39, 512, 8, 0x2000, SP_OPTIONS},
- {"NAND 8MiB 3,3V 8-bit", 0xe6, 512, 8, 0x2000, SP_OPTIONS},
- {"NAND 8MiB 1,8V 16-bit", 0x49, 512, 8, 0x2000, SP_OPTIONS16},
- {"NAND 8MiB 3,3V 16-bit", 0x59, 512, 8, 0x2000, SP_OPTIONS16},
- #endif
-
- {"NAND 16MiB 1,8V 8-bit", 0x33, 512, 16, 0x4000, SP_OPTIONS},
- {"NAND 16MiB 3,3V 8-bit", 0x73, 512, 16, 0x4000, SP_OPTIONS},
- {"NAND 16MiB 1,8V 16-bit", 0x43, 512, 16, 0x4000, SP_OPTIONS16},
- {"NAND 16MiB 3,3V 16-bit", 0x53, 512, 16, 0x4000, SP_OPTIONS16},
-
- {"NAND 32MiB 1,8V 8-bit", 0x35, 512, 32, 0x4000, SP_OPTIONS},
- {"NAND 32MiB 3,3V 8-bit", 0x75, 512, 32, 0x4000, SP_OPTIONS},
- {"NAND 32MiB 1,8V 16-bit", 0x45, 512, 32, 0x4000, SP_OPTIONS16},
- {"NAND 32MiB 3,3V 16-bit", 0x55, 512, 32, 0x4000, SP_OPTIONS16},
-
- {"NAND 64MiB 1,8V 8-bit", 0x36, 512, 64, 0x4000, SP_OPTIONS},
- {"NAND 64MiB 3,3V 8-bit", 0x76, 512, 64, 0x4000, SP_OPTIONS},
- {"NAND 64MiB 1,8V 16-bit", 0x46, 512, 64, 0x4000, SP_OPTIONS16},
- {"NAND 64MiB 3,3V 16-bit", 0x56, 512, 64, 0x4000, SP_OPTIONS16},
-
- {"NAND 128MiB 1,8V 8-bit", 0x78, 512, 128, 0x4000, SP_OPTIONS},
- {"NAND 128MiB 1,8V 8-bit", 0x39, 512, 128, 0x4000, SP_OPTIONS},
- {"NAND 128MiB 3,3V 8-bit", 0x79, 512, 128, 0x4000, SP_OPTIONS},
- {"NAND 128MiB 1,8V 16-bit", 0x72, 512, 128, 0x4000, SP_OPTIONS16},
- {"NAND 128MiB 1,8V 16-bit", 0x49, 512, 128, 0x4000, SP_OPTIONS16},
- {"NAND 128MiB 3,3V 16-bit", 0x74, 512, 128, 0x4000, SP_OPTIONS16},
- {"NAND 128MiB 3,3V 16-bit", 0x59, 512, 128, 0x4000, SP_OPTIONS16},
-
- {"NAND 256MiB 3,3V 8-bit", 0x71, 512, 256, 0x4000, SP_OPTIONS},
+ /*
+ * The chip ID list:
+ * name, device ID, page size, chip size in MiB, eraseblock size, options
+ *
+ * If page size and eraseblock size are 0, the sizes are taken from the
+ * extended chip ID.
+ */
+ struct nand_flash_dev nand_flash_ids[] = {
+ /*
+ * Some incompatible NAND chips share device ID's and so must be
+ * listed by full ID. We list them first so that we can easily identify
+ * the most specific match.
+ */
+ {"TC58NVG2S0F 4G 3.3V 8-bit",
+ { .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
+ SZ_4K, SZ_512, SZ_256K, 0, 8, 224},
+ {"TC58NVG3S0F 8G 3.3V 8-bit",
+ { .id = {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08} },
+ SZ_4K, SZ_1K, SZ_256K, 0, 8, 232},
+ {"TC58NVG5D2 32G 3.3V 8-bit",
+ { .id = {0x98, 0xd7, 0x94, 0x32, 0x76, 0x56, 0x09, 0x00} },
+ SZ_8K, SZ_4K, SZ_1M, 0, 8, 640},
+ {"TC58NVG6D2 64G 3.3V 8-bit",
+ { .id = {0x98, 0xde, 0x94, 0x82, 0x76, 0x56, 0x04, 0x20} },
+ SZ_8K, SZ_8K, SZ_2M, 0, 8, 640},
+
- LEGACY_ID_NAND("NAND 4MiB 5V 8-bit", 0x6B, 512, 4, 0x2000, 0),
- LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 512, 4, 0x2000, 0),
- LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE5, 512, 4, 0x2000, 0),
- LEGACY_ID_NAND("NAND 8MiB 3,3V 8-bit", 0xD6, 512, 8, 0x2000, 0),
- LEGACY_ID_NAND("NAND 8MiB 3,3V 8-bit", 0xE6, 512, 8, 0x2000, 0),
++ LEGACY_ID_NAND("NAND 4MiB 5V 8-bit", 0x6B, 512, 4, 0x2000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 512, 4, 0x2000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE5, 512, 4, 0x2000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 8MiB 3,3V 8-bit", 0xD6, 512, 8, 0x2000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 8MiB 3,3V 8-bit", 0xE6, 512, 8, 0x2000, SP_OPTIONS),
+
- LEGACY_ID_NAND("NAND 16MiB 1,8V 8-bit", 0x33, 512, 16, 0x4000, 0),
- LEGACY_ID_NAND("NAND 16MiB 3,3V 8-bit", 0x73, 512, 16, 0x4000, 0),
- LEGACY_ID_NAND("NAND 16MiB 1,8V 16-bit", 0x43, 512, 16, 0x4000, NAND_BUSWIDTH_16),
- LEGACY_ID_NAND("NAND 16MiB 3,3V 16-bit", 0x53, 512, 16, 0x4000, NAND_BUSWIDTH_16),
++ LEGACY_ID_NAND("NAND 16MiB 1,8V 8-bit", 0x33, 512, 16, 0x4000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 16MiB 3,3V 8-bit", 0x73, 512, 16, 0x4000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 16MiB 1,8V 16-bit", 0x43, 512, 16, 0x4000, SP_OPTIONS16),
++ LEGACY_ID_NAND("NAND 16MiB 3,3V 16-bit", 0x53, 512, 16, 0x4000, SP_OPTIONS16),
+
- LEGACY_ID_NAND("NAND 32MiB 1,8V 8-bit", 0x35, 512, 32, 0x4000, 0),
- LEGACY_ID_NAND("NAND 32MiB 3,3V 8-bit", 0x75, 512, 32, 0x4000, 0),
- LEGACY_ID_NAND("NAND 32MiB 1,8V 16-bit", 0x45, 512, 32, 0x4000, NAND_BUSWIDTH_16),
- LEGACY_ID_NAND("NAND 32MiB 3,3V 16-bit", 0x55, 512, 32, 0x4000, NAND_BUSWIDTH_16),
++ LEGACY_ID_NAND("NAND 32MiB 1,8V 8-bit", 0x35, 512, 32, 0x4000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 32MiB 3,3V 8-bit", 0x75, 512, 32, 0x4000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 32MiB 1,8V 16-bit", 0x45, 512, 32, 0x4000, SP_OPTIONS16),
++ LEGACY_ID_NAND("NAND 32MiB 3,3V 16-bit", 0x55, 512, 32, 0x4000, SP_OPTIONS16),
+
- LEGACY_ID_NAND("NAND 64MiB 1,8V 8-bit", 0x36, 512, 64, 0x4000, 0),
- LEGACY_ID_NAND("NAND 64MiB 3,3V 8-bit", 0x76, 512, 64, 0x4000, 0),
- LEGACY_ID_NAND("NAND 64MiB 1,8V 16-bit", 0x46, 512, 64, 0x4000, NAND_BUSWIDTH_16),
- LEGACY_ID_NAND("NAND 64MiB 3,3V 16-bit", 0x56, 512, 64, 0x4000, NAND_BUSWIDTH_16),
++ LEGACY_ID_NAND("NAND 64MiB 1,8V 8-bit", 0x36, 512, 64, 0x4000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 64MiB 3,3V 8-bit", 0x76, 512, 64, 0x4000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 64MiB 1,8V 16-bit", 0x46, 512, 64, 0x4000, SP_OPTIONS16),
++ LEGACY_ID_NAND("NAND 64MiB 3,3V 16-bit", 0x56, 512, 64, 0x4000, SP_OPTIONS16),
+
- LEGACY_ID_NAND("NAND 128MiB 1,8V 8-bit", 0x78, 512, 128, 0x4000, 0),
- LEGACY_ID_NAND("NAND 128MiB 1,8V 8-bit", 0x39, 512, 128, 0x4000, 0),
- LEGACY_ID_NAND("NAND 128MiB 3,3V 8-bit", 0x79, 512, 128, 0x4000, 0),
- LEGACY_ID_NAND("NAND 128MiB 1,8V 16-bit", 0x72, 512, 128, 0x4000, NAND_BUSWIDTH_16),
- LEGACY_ID_NAND("NAND 128MiB 1,8V 16-bit", 0x49, 512, 128, 0x4000, NAND_BUSWIDTH_16),
- LEGACY_ID_NAND("NAND 128MiB 3,3V 16-bit", 0x74, 512, 128, 0x4000, NAND_BUSWIDTH_16),
- LEGACY_ID_NAND("NAND 128MiB 3,3V 16-bit", 0x59, 512, 128, 0x4000, NAND_BUSWIDTH_16),
++ LEGACY_ID_NAND("NAND 128MiB 1,8V 8-bit", 0x78, 512, 128, 0x4000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 128MiB 1,8V 8-bit", 0x39, 512, 128, 0x4000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 128MiB 3,3V 8-bit", 0x79, 512, 128, 0x4000, SP_OPTIONS),
++ LEGACY_ID_NAND("NAND 128MiB 1,8V 16-bit", 0x72, 512, 128, 0x4000, SP_OPTIONS16),
++ LEGACY_ID_NAND("NAND 128MiB 1,8V 16-bit", 0x49, 512, 128, 0x4000, SP_OPTIONS16),
++ LEGACY_ID_NAND("NAND 128MiB 3,3V 16-bit", 0x74, 512, 128, 0x4000, SP_OPTIONS16),
++ LEGACY_ID_NAND("NAND 128MiB 3,3V 16-bit", 0x59, 512, 128, 0x4000, SP_OPTIONS16),
+
- LEGACY_ID_NAND("NAND 256MiB 3,3V 8-bit", 0x71, 512, 256, 0x4000, 0),
++ LEGACY_ID_NAND("NAND 256MiB 3,3V 8-bit", 0x71, 512, 256, 0x4000, SP_OPTIONS),
/*
- * These are the new chips with large page size. The pagesize and the
- * erasesize is determined from the extended id bytes
+ * These are the new chips with large page size. Their page size and
+ * eraseblock size are determined from the extended ID bytes.
*/
- #define LP_OPTIONS NAND_SAMSUNG_LP_OPTIONS
- #define LP_OPTIONS16 (LP_OPTIONS | NAND_BUSWIDTH_16)
/* 512 Megabit */
- {"NAND 64MiB 1,8V 8-bit", 0xA2, 0, 64, 0, LP_OPTIONS},
- {"NAND 64MiB 1,8V 8-bit", 0xA0, 0, 64, 0, LP_OPTIONS},
- {"NAND 64MiB 3,3V 8-bit", 0xF2, 0, 64, 0, LP_OPTIONS},
- {"NAND 64MiB 3,3V 8-bit", 0xD0, 0, 64, 0, LP_OPTIONS},
- {"NAND 64MiB 3,3V 8-bit", 0xF0, 0, 64, 0, LP_OPTIONS},
- {"NAND 64MiB 1,8V 16-bit", 0xB2, 0, 64, 0, LP_OPTIONS16},
- {"NAND 64MiB 1,8V 16-bit", 0xB0, 0, 64, 0, LP_OPTIONS16},
- {"NAND 64MiB 3,3V 16-bit", 0xC2, 0, 64, 0, LP_OPTIONS16},
- {"NAND 64MiB 3,3V 16-bit", 0xC0, 0, 64, 0, LP_OPTIONS16},
+ EXTENDED_ID_NAND("NAND 64MiB 1,8V 8-bit", 0xA2, 64, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 64MiB 1,8V 8-bit", 0xA0, 64, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 64MiB 3,3V 8-bit", 0xF2, 64, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 64MiB 3,3V 8-bit", 0xD0, 64, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 64MiB 3,3V 8-bit", 0xF0, 64, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 64MiB 1,8V 16-bit", 0xB2, 64, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 64MiB 1,8V 16-bit", 0xB0, 64, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 64MiB 3,3V 16-bit", 0xC2, 64, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 64MiB 3,3V 16-bit", 0xC0, 64, LP_OPTIONS16),
/* 1 Gigabit */
- {"NAND 128MiB 1,8V 8-bit", 0xA1, 0, 128, 0, LP_OPTIONS},
- {"NAND 128MiB 3,3V 8-bit", 0xF1, 0, 128, 0, LP_OPTIONS},
- {"NAND 128MiB 3,3V 8-bit", 0xD1, 0, 128, 0, LP_OPTIONS},
- {"NAND 128MiB 1,8V 16-bit", 0xB1, 0, 128, 0, LP_OPTIONS16},
- {"NAND 128MiB 3,3V 16-bit", 0xC1, 0, 128, 0, LP_OPTIONS16},
- {"NAND 128MiB 1,8V 16-bit", 0xAD, 0, 128, 0, LP_OPTIONS16},
+ EXTENDED_ID_NAND("NAND 128MiB 1,8V 8-bit", 0xA1, 128, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 128MiB 3,3V 8-bit", 0xF1, 128, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 128MiB 3,3V 8-bit", 0xD1, 128, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 128MiB 1,8V 16-bit", 0xB1, 128, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 128MiB 3,3V 16-bit", 0xC1, 128, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 128MiB 1,8V 16-bit", 0xAD, 128, LP_OPTIONS16),
/* 2 Gigabit */
- {"NAND 256MiB 1,8V 8-bit", 0xAA, 0, 256, 0, LP_OPTIONS},
- {"NAND 256MiB 3,3V 8-bit", 0xDA, 0, 256, 0, LP_OPTIONS},
- {"NAND 256MiB 1,8V 16-bit", 0xBA, 0, 256, 0, LP_OPTIONS16},
- {"NAND 256MiB 3,3V 16-bit", 0xCA, 0, 256, 0, LP_OPTIONS16},
+ EXTENDED_ID_NAND("NAND 256MiB 1,8V 8-bit", 0xAA, 256, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 256MiB 3,3V 8-bit", 0xDA, 256, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 256MiB 1,8V 16-bit", 0xBA, 256, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 256MiB 3,3V 16-bit", 0xCA, 256, LP_OPTIONS16),
/* 4 Gigabit */
- {"NAND 512MiB 1,8V 8-bit", 0xAC, 0, 512, 0, LP_OPTIONS},
- {"NAND 512MiB 3,3V 8-bit", 0xDC, 0, 512, 0, LP_OPTIONS},
- {"NAND 512MiB 1,8V 16-bit", 0xBC, 0, 512, 0, LP_OPTIONS16},
- {"NAND 512MiB 3,3V 16-bit", 0xCC, 0, 512, 0, LP_OPTIONS16},
+ EXTENDED_ID_NAND("NAND 512MiB 1,8V 8-bit", 0xAC, 512, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 512MiB 3,3V 8-bit", 0xDC, 512, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 512MiB 1,8V 16-bit", 0xBC, 512, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 512MiB 3,3V 16-bit", 0xCC, 512, LP_OPTIONS16),
/* 8 Gigabit */
- {"NAND 1GiB 1,8V 8-bit", 0xA3, 0, 1024, 0, LP_OPTIONS},
- {"NAND 1GiB 3,3V 8-bit", 0xD3, 0, 1024, 0, LP_OPTIONS},
- {"NAND 1GiB 1,8V 16-bit", 0xB3, 0, 1024, 0, LP_OPTIONS16},
- {"NAND 1GiB 3,3V 16-bit", 0xC3, 0, 1024, 0, LP_OPTIONS16},
+ EXTENDED_ID_NAND("NAND 1GiB 1,8V 8-bit", 0xA3, 1024, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 1GiB 3,3V 8-bit", 0xD3, 1024, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 1GiB 1,8V 16-bit", 0xB3, 1024, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 1GiB 3,3V 16-bit", 0xC3, 1024, LP_OPTIONS16),
/* 16 Gigabit */
- {"NAND 2GiB 1,8V 8-bit", 0xA5, 0, 2048, 0, LP_OPTIONS},
- {"NAND 2GiB 3,3V 8-bit", 0xD5, 0, 2048, 0, LP_OPTIONS},
- {"NAND 2GiB 1,8V 16-bit", 0xB5, 0, 2048, 0, LP_OPTIONS16},
- {"NAND 2GiB 3,3V 16-bit", 0xC5, 0, 2048, 0, LP_OPTIONS16},
+ EXTENDED_ID_NAND("NAND 2GiB 1,8V 8-bit", 0xA5, 2048, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 2GiB 3,3V 8-bit", 0xD5, 2048, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 2GiB 1,8V 16-bit", 0xB5, 2048, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 2GiB 3,3V 16-bit", 0xC5, 2048, LP_OPTIONS16),
/* 32 Gigabit */
- {"NAND 4GiB 1,8V 8-bit", 0xA7, 0, 4096, 0, LP_OPTIONS},
- {"NAND 4GiB 3,3V 8-bit", 0xD7, 0, 4096, 0, LP_OPTIONS},
- {"NAND 4GiB 1,8V 16-bit", 0xB7, 0, 4096, 0, LP_OPTIONS16},
- {"NAND 4GiB 3,3V 16-bit", 0xC7, 0, 4096, 0, LP_OPTIONS16},
+ EXTENDED_ID_NAND("NAND 4GiB 1,8V 8-bit", 0xA7, 4096, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 4GiB 3,3V 8-bit", 0xD7, 4096, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 4GiB 1,8V 16-bit", 0xB7, 4096, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 4GiB 3,3V 16-bit", 0xC7, 4096, LP_OPTIONS16),
/* 64 Gigabit */
- {"NAND 8GiB 1,8V 8-bit", 0xAE, 0, 8192, 0, LP_OPTIONS},
- {"NAND 8GiB 3,3V 8-bit", 0xDE, 0, 8192, 0, LP_OPTIONS},
- {"NAND 8GiB 1,8V 16-bit", 0xBE, 0, 8192, 0, LP_OPTIONS16},
- {"NAND 8GiB 3,3V 16-bit", 0xCE, 0, 8192, 0, LP_OPTIONS16},
+ EXTENDED_ID_NAND("NAND 8GiB 1,8V 8-bit", 0xAE, 8192, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 8GiB 3,3V 8-bit", 0xDE, 8192, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 8GiB 1,8V 16-bit", 0xBE, 8192, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 8GiB 3,3V 16-bit", 0xCE, 8192, LP_OPTIONS16),
/* 128 Gigabit */
- {"NAND 16GiB 1,8V 8-bit", 0x1A, 0, 16384, 0, LP_OPTIONS},
- {"NAND 16GiB 3,3V 8-bit", 0x3A, 0, 16384, 0, LP_OPTIONS},
- {"NAND 16GiB 1,8V 16-bit", 0x2A, 0, 16384, 0, LP_OPTIONS16},
- {"NAND 16GiB 3,3V 16-bit", 0x4A, 0, 16384, 0, LP_OPTIONS16},
+ EXTENDED_ID_NAND("NAND 16GiB 1,8V 8-bit", 0x1A, 16384, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 16GiB 3,3V 8-bit", 0x3A, 16384, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 16GiB 1,8V 16-bit", 0x2A, 16384, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 16GiB 3,3V 16-bit", 0x4A, 16384, LP_OPTIONS16),
/* 256 Gigabit */
- {"NAND 32GiB 1,8V 8-bit", 0x1C, 0, 32768, 0, LP_OPTIONS},
- {"NAND 32GiB 3,3V 8-bit", 0x3C, 0, 32768, 0, LP_OPTIONS},
- {"NAND 32GiB 1,8V 16-bit", 0x2C, 0, 32768, 0, LP_OPTIONS16},
- {"NAND 32GiB 3,3V 16-bit", 0x4C, 0, 32768, 0, LP_OPTIONS16},
+ EXTENDED_ID_NAND("NAND 32GiB 1,8V 8-bit", 0x1C, 32768, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 32GiB 3,3V 8-bit", 0x3C, 32768, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 32GiB 1,8V 16-bit", 0x2C, 32768, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 32GiB 3,3V 16-bit", 0x4C, 32768, LP_OPTIONS16),
/* 512 Gigabit */
- {"NAND 64GiB 1,8V 8-bit", 0x1E, 0, 65536, 0, LP_OPTIONS},
- {"NAND 64GiB 3,3V 8-bit", 0x3E, 0, 65536, 0, LP_OPTIONS},
- {"NAND 64GiB 1,8V 16-bit", 0x2E, 0, 65536, 0, LP_OPTIONS16},
- {"NAND 64GiB 3,3V 16-bit", 0x4E, 0, 65536, 0, LP_OPTIONS16},
+ EXTENDED_ID_NAND("NAND 64GiB 1,8V 8-bit", 0x1E, 65536, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 64GiB 3,3V 8-bit", 0x3E, 65536, LP_OPTIONS),
+ EXTENDED_ID_NAND("NAND 64GiB 1,8V 16-bit", 0x2E, 65536, LP_OPTIONS16),
+ EXTENDED_ID_NAND("NAND 64GiB 3,3V 16-bit", 0x4E, 65536, LP_OPTIONS16),
- /*
- * Renesas AND 1 Gigabit. Those chips do not support extended id and
- * have a strange page/block layout ! The chosen minimum erasesize is
- * 4 * 2 * 2048 = 16384 Byte, as those chips have an array of 4 page
- * planes 1 block = 2 pages, but due to plane arrangement the blocks
- * 0-3 consists of page 0 + 4,1 + 5, 2 + 6, 3 + 7 Anyway JFFS2 would
- * increase the eraseblock size so we chose a combined one which can be
- * erased in one go There are more speed improvements for reads and
- * writes possible, but not implemented now
- */
- {"AND 128MiB 3,3V 8-bit", 0x01, 2048, 128, 0x4000,
- NAND_IS_AND | NAND_4PAGE_ARRAY | BBT_AUTO_REFRESH},
-
- {NULL,}
+ {NULL}
};
- /*
- * Manufacturer ID list
- */
+ /* Manufacturer IDs */
struct nand_manufacturers nand_manuf_ids[] = {
{NAND_MFR_TOSHIBA, "Toshiba"},
{NAND_MFR_SAMSUNG, "Samsung"},
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: linux-next: manual merge of the l2-mtd tree with Linus' tree
2012-12-13 15:15 ` Murali Karicheri
@ 2012-12-14 13:38 ` Kumar, Anil
0 siblings, 0 replies; 13+ messages in thread
From: Kumar, Anil @ 2012-12-14 13:38 UTC (permalink / raw)
To: Karicheri, Muralidharan
Cc: Stephen Rothwell, Artem Bityutskiy, linux-next, linux-kernel,
Grant Likely
________________________________________
From: Karicheri, Muralidharan
Sent: Thursday, December 13, 2012 8:45 PM
To: Kumar, Anil
Cc: Stephen Rothwell; Artem Bityutskiy; linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; Grant Likely
Subject: Re: linux-next: manual merge of the l2-mtd tree with Linus' tree
On 12/13/2012 12:38 AM, Kumar, Anil wrote:
> On Thu, Dec 13, 2012 at 07:07:55, Stephen Rothwell wrote:
>> Hi Artem,
>>
>> Today's linux-next merge of the l2-mtd tree got a conflict in
>> Documentation/devicetree/bindings/arm/davinci/nand.txt between commit
>> fed16bba8726 ("mtd: nand: davinci: fix the binding documentation") from
>> Linus' tree and commit 192afdbfbc5c ("mtd: davinci: add support for
>> parition binding nodes") from the l2-mtd tree.
>>
>> I fixed it up (maybe- see below) and can carry the fix as necessary (no
>> action is required).
>>
>> --
>> Cheers,
>> Stephen Rothwell sfr@canb.auug.org.au
>>
>> diff --cc Documentation/devicetree/bindings/arm/davinci/nand.txt
>> index 49fc7ad,4746452..0000000
>> --- a/Documentation/devicetree/bindings/arm/davinci/nand.txt
>> +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
>> @@@ -23,16 -23,37 +23,24 @@@ Recommended properties
>> - ti,davinci-nand-buswidth: buswidth 8 or 16
>> - ti,davinci-nand-use-bbt: use flash based bad block table support.
>>
>> + nand device bindings may contain additional sub-nodes describing
>> + partitions of the address space. See partition.txt for more detail.
>> +
>> -Example (enbw_cmc board):
>> -aemif@60000000 {
>> - compatible = "ti,davinci-aemif";
>> - #address-cells =<2>;
>> - #size-cells =<1>;
>> - reg =<0x68000000 0x80000>;
>> - ranges =<2 0 0x60000000 0x02000000
>> - 3 0 0x62000000 0x02000000
>> - 4 0 0x64000000 0x02000000
>> - 5 0 0x66000000 0x02000000
>> - 6 0 0x68000000 0x02000000>;
>> - nand@3,0 {
>> - compatible = "ti,davinci-nand";
>> - reg =<3 0x0 0x807ff
>> - 6 0x0 0x8000>;
>> - #address-cells =<1>;
>> - #size-cells =<1>;
>> - ti,davinci-chipselect =<1>;
>> - ti,davinci-mask-ale =<0>;
>> - ti,davinci-mask-cle =<0>;
>> - ti,davinci-mask-chipsel =<0>;
>> - ti,davinci-ecc-mode = "hw";
>> - ti,davinci-ecc-bits =<4>;
>> - ti,davinci-nand-use-bbt;
>> +Example(da850 EVM ):
>> +nand_cs3@62000000 {
>> + compatible = "ti,davinci-nand";
>> + reg =<0x62000000 0x807ff
>> + 0x68000000 0x8000>;
>> + ti,davinci-chipselect =<1>;
>> + ti,davinci-mask-ale =<0>;
>> + ti,davinci-mask-cle =<0>;
>> + ti,davinci-mask-chipsel =<0>;
>> + ti,davinci-ecc-mode = "hw";
>> + ti,davinci-ecc-bits =<4>;
>> + ti,davinci-nand-use-bbt;
>> +
>> - partition@180000 {
>> - label = "ubifs";
>> - reg =<0x180000 0x7e80000>;
>> - };
>> ++ partition@180000 {
>> ++ label = "ubifs";
>> ++ reg =<0x180000 0x7e80000>;
> partition@180000 is sub-node of nand_cs3@62000000.
> nand_cs3@62000000 needs to use below properties
>
> #address-cells =<1>;
> #size-cells =<1>;
>
> Without these properties DT build will give reg format Warning.
>
>> + };
>> };
>>
>Anul,
>Could you point me to a corresponding driver commit id?
from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
commit ID : cdeadd712f52b16a9285386d61ee26fd14eb4085
add OF support for the davinci nand controller
Thanks,
Anil
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: linux-next: manual merge of the l2-mtd tree with Linus' tree
2012-12-13 5:38 ` Kumar, Anil
@ 2012-12-13 15:15 ` Murali Karicheri
2012-12-14 13:38 ` Kumar, Anil
0 siblings, 1 reply; 13+ messages in thread
From: Murali Karicheri @ 2012-12-13 15:15 UTC (permalink / raw)
To: Kumar, Anil
Cc: Stephen Rothwell, Artem Bityutskiy, linux-next, linux-kernel,
Grant Likely
On 12/13/2012 12:38 AM, Kumar, Anil wrote:
> On Thu, Dec 13, 2012 at 07:07:55, Stephen Rothwell wrote:
>> Hi Artem,
>>
>> Today's linux-next merge of the l2-mtd tree got a conflict in
>> Documentation/devicetree/bindings/arm/davinci/nand.txt between commit
>> fed16bba8726 ("mtd: nand: davinci: fix the binding documentation") from
>> Linus' tree and commit 192afdbfbc5c ("mtd: davinci: add support for
>> parition binding nodes") from the l2-mtd tree.
>>
>> I fixed it up (maybe- see below) and can carry the fix as necessary (no
>> action is required).
>>
>> --
>> Cheers,
>> Stephen Rothwell sfr@canb.auug.org.au
>>
>> diff --cc Documentation/devicetree/bindings/arm/davinci/nand.txt
>> index 49fc7ad,4746452..0000000
>> --- a/Documentation/devicetree/bindings/arm/davinci/nand.txt
>> +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
>> @@@ -23,16 -23,37 +23,24 @@@ Recommended properties
>> - ti,davinci-nand-buswidth: buswidth 8 or 16
>> - ti,davinci-nand-use-bbt: use flash based bad block table support.
>>
>> + nand device bindings may contain additional sub-nodes describing
>> + partitions of the address space. See partition.txt for more detail.
>> +
>> -Example (enbw_cmc board):
>> -aemif@60000000 {
>> - compatible = "ti,davinci-aemif";
>> - #address-cells =<2>;
>> - #size-cells =<1>;
>> - reg =<0x68000000 0x80000>;
>> - ranges =<2 0 0x60000000 0x02000000
>> - 3 0 0x62000000 0x02000000
>> - 4 0 0x64000000 0x02000000
>> - 5 0 0x66000000 0x02000000
>> - 6 0 0x68000000 0x02000000>;
>> - nand@3,0 {
>> - compatible = "ti,davinci-nand";
>> - reg =<3 0x0 0x807ff
>> - 6 0x0 0x8000>;
>> - #address-cells =<1>;
>> - #size-cells =<1>;
>> - ti,davinci-chipselect =<1>;
>> - ti,davinci-mask-ale =<0>;
>> - ti,davinci-mask-cle =<0>;
>> - ti,davinci-mask-chipsel =<0>;
>> - ti,davinci-ecc-mode = "hw";
>> - ti,davinci-ecc-bits =<4>;
>> - ti,davinci-nand-use-bbt;
>> +Example(da850 EVM ):
>> +nand_cs3@62000000 {
>> + compatible = "ti,davinci-nand";
>> + reg =<0x62000000 0x807ff
>> + 0x68000000 0x8000>;
>> + ti,davinci-chipselect =<1>;
>> + ti,davinci-mask-ale =<0>;
>> + ti,davinci-mask-cle =<0>;
>> + ti,davinci-mask-chipsel =<0>;
>> + ti,davinci-ecc-mode = "hw";
>> + ti,davinci-ecc-bits =<4>;
>> + ti,davinci-nand-use-bbt;
>> +
>> - partition@180000 {
>> - label = "ubifs";
>> - reg =<0x180000 0x7e80000>;
>> - };
>> ++ partition@180000 {
>> ++ label = "ubifs";
>> ++ reg =<0x180000 0x7e80000>;
> partition@180000 is sub-node of nand_cs3@62000000.
> nand_cs3@62000000 needs to use below properties
>
> #address-cells =<1>;
> #size-cells =<1>;
>
> Without these properties DT build will give reg format Warning.
>
>> + };
>> };
>>
Anul,
Could you point me to a corresponding driver commit id?
Murali
^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: linux-next: manual merge of the l2-mtd tree with Linus' tree
2012-12-13 1:37 Stephen Rothwell
@ 2012-12-13 5:38 ` Kumar, Anil
2012-12-13 15:15 ` Murali Karicheri
0 siblings, 1 reply; 13+ messages in thread
From: Kumar, Anil @ 2012-12-13 5:38 UTC (permalink / raw)
To: Stephen Rothwell, Artem Bityutskiy
Cc: linux-next, linux-kernel, Grant Likely, Karicheri, Muralidharan
On Thu, Dec 13, 2012 at 07:07:55, Stephen Rothwell wrote:
> Hi Artem,
>
> Today's linux-next merge of the l2-mtd tree got a conflict in
> Documentation/devicetree/bindings/arm/davinci/nand.txt between commit
> fed16bba8726 ("mtd: nand: davinci: fix the binding documentation") from
> Linus' tree and commit 192afdbfbc5c ("mtd: davinci: add support for
> parition binding nodes") from the l2-mtd tree.
>
> I fixed it up (maybe- see below) and can carry the fix as necessary (no
> action is required).
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
> diff --cc Documentation/devicetree/bindings/arm/davinci/nand.txt
> index 49fc7ad,4746452..0000000
> --- a/Documentation/devicetree/bindings/arm/davinci/nand.txt
> +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
> @@@ -23,16 -23,37 +23,24 @@@ Recommended properties
> - ti,davinci-nand-buswidth: buswidth 8 or 16
> - ti,davinci-nand-use-bbt: use flash based bad block table support.
>
> + nand device bindings may contain additional sub-nodes describing
> + partitions of the address space. See partition.txt for more detail.
> +
> -Example (enbw_cmc board):
> -aemif@60000000 {
> - compatible = "ti,davinci-aemif";
> - #address-cells = <2>;
> - #size-cells = <1>;
> - reg = <0x68000000 0x80000>;
> - ranges = <2 0 0x60000000 0x02000000
> - 3 0 0x62000000 0x02000000
> - 4 0 0x64000000 0x02000000
> - 5 0 0x66000000 0x02000000
> - 6 0 0x68000000 0x02000000>;
> - nand@3,0 {
> - compatible = "ti,davinci-nand";
> - reg = <3 0x0 0x807ff
> - 6 0x0 0x8000>;
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ti,davinci-chipselect = <1>;
> - ti,davinci-mask-ale = <0>;
> - ti,davinci-mask-cle = <0>;
> - ti,davinci-mask-chipsel = <0>;
> - ti,davinci-ecc-mode = "hw";
> - ti,davinci-ecc-bits = <4>;
> - ti,davinci-nand-use-bbt;
> +Example(da850 EVM ):
> +nand_cs3@62000000 {
> + compatible = "ti,davinci-nand";
> + reg = <0x62000000 0x807ff
> + 0x68000000 0x8000>;
> + ti,davinci-chipselect = <1>;
> + ti,davinci-mask-ale = <0>;
> + ti,davinci-mask-cle = <0>;
> + ti,davinci-mask-chipsel = <0>;
> + ti,davinci-ecc-mode = "hw";
> + ti,davinci-ecc-bits = <4>;
> + ti,davinci-nand-use-bbt;
> +
> - partition@180000 {
> - label = "ubifs";
> - reg = <0x180000 0x7e80000>;
> - };
> ++ partition@180000 {
> ++ label = "ubifs";
> ++ reg = <0x180000 0x7e80000>;
partition@180000 is sub-node of nand_cs3@62000000.
nand_cs3@62000000 needs to use below properties
#address-cells = <1>;
#size-cells = <1>;
Without these properties DT build will give reg format Warning.
> + };
> };
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* linux-next: manual merge of the l2-mtd tree with Linus' tree
@ 2012-12-13 1:37 Stephen Rothwell
2012-12-13 5:38 ` Kumar, Anil
0 siblings, 1 reply; 13+ messages in thread
From: Stephen Rothwell @ 2012-12-13 1:37 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: linux-next, linux-kernel, Kumar, Anil, Grant Likely, Murali Karicheri
[-- Attachment #1: Type: text/plain, Size: 2316 bytes --]
Hi Artem,
Today's linux-next merge of the l2-mtd tree got a conflict in
Documentation/devicetree/bindings/arm/davinci/nand.txt between commit
fed16bba8726 ("mtd: nand: davinci: fix the binding documentation") from
Linus' tree and commit 192afdbfbc5c ("mtd: davinci: add support for
parition binding nodes") from the l2-mtd tree.
I fixed it up (maybe- see below) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc Documentation/devicetree/bindings/arm/davinci/nand.txt
index 49fc7ad,4746452..0000000
--- a/Documentation/devicetree/bindings/arm/davinci/nand.txt
+++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
@@@ -23,16 -23,37 +23,24 @@@ Recommended properties
- ti,davinci-nand-buswidth: buswidth 8 or 16
- ti,davinci-nand-use-bbt: use flash based bad block table support.
+ nand device bindings may contain additional sub-nodes describing
+ partitions of the address space. See partition.txt for more detail.
+
-Example (enbw_cmc board):
-aemif@60000000 {
- compatible = "ti,davinci-aemif";
- #address-cells = <2>;
- #size-cells = <1>;
- reg = <0x68000000 0x80000>;
- ranges = <2 0 0x60000000 0x02000000
- 3 0 0x62000000 0x02000000
- 4 0 0x64000000 0x02000000
- 5 0 0x66000000 0x02000000
- 6 0 0x68000000 0x02000000>;
- nand@3,0 {
- compatible = "ti,davinci-nand";
- reg = <3 0x0 0x807ff
- 6 0x0 0x8000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ti,davinci-chipselect = <1>;
- ti,davinci-mask-ale = <0>;
- ti,davinci-mask-cle = <0>;
- ti,davinci-mask-chipsel = <0>;
- ti,davinci-ecc-mode = "hw";
- ti,davinci-ecc-bits = <4>;
- ti,davinci-nand-use-bbt;
+Example(da850 EVM ):
+nand_cs3@62000000 {
+ compatible = "ti,davinci-nand";
+ reg = <0x62000000 0x807ff
+ 0x68000000 0x8000>;
+ ti,davinci-chipselect = <1>;
+ ti,davinci-mask-ale = <0>;
+ ti,davinci-mask-cle = <0>;
+ ti,davinci-mask-chipsel = <0>;
+ ti,davinci-ecc-mode = "hw";
+ ti,davinci-ecc-bits = <4>;
+ ti,davinci-nand-use-bbt;
+
- partition@180000 {
- label = "ubifs";
- reg = <0x180000 0x7e80000>;
- };
++ partition@180000 {
++ label = "ubifs";
++ reg = <0x180000 0x7e80000>;
+ };
};
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: linux-next: manual merge of the l2-mtd tree with Linus' tree
2012-05-29 2:45 ` Stephen Rothwell
2012-05-29 7:42 ` David Woodhouse
@ 2012-05-29 8:19 ` Artem Bityutskiy
1 sibling, 0 replies; 13+ messages in thread
From: Artem Bityutskiy @ 2012-05-29 8:19 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Sascha Hauer, Fabio Estevam, David Woodhouse
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
On Tue, 2012-05-29 at 12:45 +1000, Stephen Rothwell wrote:
> Hi Artem,
>
> On Tue, 29 May 2012 12:33:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > This tree (l2-mtd) needs to be updated since most of its patches (but not
> > commits) have been merged into upstream trees. Artem, you and Dave
> > Woodhouse need to discuss your work flow. (Or I just need to remove the
> > l2-mtd tree from linux-next.)
>
> I fact, I screwed up the various merge resolutions that the above mess
> caused, so I just dropped the l2-mtd tree for today. Please fix it up.
Yeah, I should have rebased it yesterday against dwmw2's tree. I've just
done this and this should fix the issue. Thanks!
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: linux-next: manual merge of the l2-mtd tree with Linus' tree
2012-05-29 2:45 ` Stephen Rothwell
@ 2012-05-29 7:42 ` David Woodhouse
2012-05-29 8:19 ` Artem Bityutskiy
1 sibling, 0 replies; 13+ messages in thread
From: David Woodhouse @ 2012-05-29 7:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Artem Bityutskiy, linux-next, linux-kernel, Sascha Hauer, Fabio Estevam
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
On Tue, 2012-05-29 at 12:45 +1000, Stephen Rothwell wrote:
> Hi Artem,
>
> On Tue, 29 May 2012 12:33:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > This tree (l2-mtd) needs to be updated since most of its patches (but not
> > commits) have been merged into upstream trees. Artem, you and Dave
> > Woodhouse need to discuss your work flow. (Or I just need to remove the
> > l2-mtd tree from linux-next.)
>
> I fact, I screwed up the various merge resolutions that the above mess
> caused, so I just dropped the l2-mtd tree for today. Please fix it up.
That is generally the intention. As discussed when we added the l2-mtd
tree to linux-next, it is operating as my 'patchwork' with Artem's
initial review. So dropping it when it conflicts with the main tree is
what we would expect.
I actually rounded everything up from Artem's tree 2 weeks ago, and
committed it with minor fixes and one rejected patch. Unfortunately,
when 'git push' told me "Everything up-to-date" it was lying, so that
didn't make it onto the *server* until yesterday when I noticed;
apologies for that.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: linux-next: manual merge of the l2-mtd tree with Linus' tree
2012-05-29 2:33 Stephen Rothwell
2012-05-29 2:38 ` Stephen Rothwell
@ 2012-05-29 2:45 ` Stephen Rothwell
2012-05-29 7:42 ` David Woodhouse
2012-05-29 8:19 ` Artem Bityutskiy
1 sibling, 2 replies; 13+ messages in thread
From: Stephen Rothwell @ 2012-05-29 2:45 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: linux-next, linux-kernel, Sascha Hauer, Fabio Estevam, David Woodhouse
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
Hi Artem,
On Tue, 29 May 2012 12:33:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> This tree (l2-mtd) needs to be updated since most of its patches (but not
> commits) have been merged into upstream trees. Artem, you and Dave
> Woodhouse need to discuss your work flow. (Or I just need to remove the
> l2-mtd tree from linux-next.)
I fact, I screwed up the various merge resolutions that the above mess
caused, so I just dropped the l2-mtd tree for today. Please fix it up.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: linux-next: manual merge of the l2-mtd tree with Linus' tree
2012-05-29 2:33 Stephen Rothwell
@ 2012-05-29 2:38 ` Stephen Rothwell
2012-05-29 2:45 ` Stephen Rothwell
1 sibling, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2012-05-29 2:38 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: linux-next, linux-kernel, Sascha Hauer, Fabio Estevam, David Woodhouse
[-- Attachment #1: Type: text/plain, Size: 573 bytes --]
On Tue, 29 May 2012 12:33:01 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the l2-mtd tree got a conflict in
> drivers/mtd/nand/mxc_nand.c between commit 97c3213fd9fc ("mtd mxc_nand:
> prepare/unprepare clock") from Linus' tree and commit 625bdd2a6bd0
> ("nand: mxc_nand: Use clk_prepare_enable/clk_disable_unprepare") from the
> l2-mtd tree.
>
> The former is a superset of the latter.
Actually they modify different functions, so I fixed it up.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* linux-next: manual merge of the l2-mtd tree with Linus' tree
@ 2012-05-29 2:33 Stephen Rothwell
2012-05-29 2:38 ` Stephen Rothwell
2012-05-29 2:45 ` Stephen Rothwell
0 siblings, 2 replies; 13+ messages in thread
From: Stephen Rothwell @ 2012-05-29 2:33 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: linux-next, linux-kernel, Sascha Hauer, Fabio Estevam, David Woodhouse
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
Hi Artem,
Today's linux-next merge of the l2-mtd tree got a conflict in
drivers/mtd/nand/mxc_nand.c between commit 97c3213fd9fc ("mtd mxc_nand:
prepare/unprepare clock") from Linus' tree and commit 625bdd2a6bd0
("nand: mxc_nand: Use clk_prepare_enable/clk_disable_unprepare") from the
l2-mtd tree.
The former is a superset of the latter.
This tree (l2-mtd) needs to be updated since most of its patches (but not
commits) have been merged into upstream trees. Artem, you and Dave
Woodhouse need to discuss your work flow. (Or I just need to remove the
l2-mtd tree from linux-next.)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: linux-next: manual merge of the l2-mtd tree with Linus' tree
2012-01-11 2:38 Stephen Rothwell
@ 2012-01-11 11:15 ` Artem Bityutskiy
0 siblings, 0 replies; 13+ messages in thread
From: Artem Bityutskiy @ 2012-01-11 11:15 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Linus, David Woodhouse
[-- Attachment #1: Type: text/plain, Size: 260 bytes --]
On Wed, 2012-01-11 at 13:38 +1100, Stephen Rothwell wrote:
> I just used the l2-mtd tree version. But this tree needs cleaning up to
> represent what was actually merged upstream.
Yes, will be cleaned up, thanks.
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* linux-next: manual merge of the l2-mtd tree with Linus' tree
@ 2012-01-11 2:38 Stephen Rothwell
2012-01-11 11:15 ` Artem Bityutskiy
0 siblings, 1 reply; 13+ messages in thread
From: Stephen Rothwell @ 2012-01-11 2:38 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: linux-next, linux-kernel, Linus, David Woodhouse
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
Hi Artem,
Today's linux-next merge of the l2-mtd tree got a conflict in
fs/jffs2/erase.c between commit 10934478e44d ("mtd: do use mtd->point
directly") from Linus' tree and commit aa64d929dfae ("jffs2: do not
initialize variable unnecessarily") from the l2-mtd tree.
The commit from Linus' tree above is also in the l2-mtd tree. This is
because the l2-mtd tree commits were (at least partially) rebased before
being merged into Linus' tree.
I just used the l2-mtd tree version. But this tree needs cleaning up to
represent what was actually merged upstream.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* linux-next: manual merge of the l2-mtd tree with Linus' tree
@ 2011-12-19 2:57 Stephen Rothwell
0 siblings, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2011-12-19 2:57 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: linux-next, linux-kernel, Jonas Gorski
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
Hi Artem,
Today's linux-next merge of the l2-mtd tree got a conflict in
drivers/mtd/maps/bcm963xx-flash.c between commit 4e549d6d4a32 ("MTD:
MAPS: bcm963xx-flash.c: explicitly include module.h") from Linus' tree
and commit 573052d2e4a4 ("mtd: maps: remove the now unused
bcm963xx-flash") from the l2-mtd tree.
The latter removes the file, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-03-19 0:19 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-19 0:19 linux-next: manual merge of the l2-mtd tree with Linus' tree Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2012-12-13 1:37 Stephen Rothwell
2012-12-13 5:38 ` Kumar, Anil
2012-12-13 15:15 ` Murali Karicheri
2012-12-14 13:38 ` Kumar, Anil
2012-05-29 2:33 Stephen Rothwell
2012-05-29 2:38 ` Stephen Rothwell
2012-05-29 2:45 ` Stephen Rothwell
2012-05-29 7:42 ` David Woodhouse
2012-05-29 8:19 ` Artem Bityutskiy
2012-01-11 2:38 Stephen Rothwell
2012-01-11 11:15 ` Artem Bityutskiy
2011-12-19 2:57 Stephen Rothwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).