* linux-next: manual merge of the l2-mtd tree with the mtd tree
@ 2012-07-17 1:00 Stephen Rothwell
2012-07-25 15:21 ` Gerlando Falauto
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Rothwell @ 2012-07-17 1:00 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: linux-next, linux-kernel, David Woodhouse, Gerlando Falauto
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
Hi Artem,
Today's linux-next merge of the l2-mtd tree got a conflict in
drivers/mtd/chips/cfi_cmdset_0002.c between commit 420962884379 ("mtd:
cfi_cmdset_0002: Micron M29EW bugfixes as per TN-13-07") from the mtd
tree and commit 39c0c188e160 ("mtd: cfi_cmdset_0002: Micron M29EW
bugfixes as per TN-13-07") from the l2-mtd tree.
I just used the version in the mtd tree.
--
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] 9+ messages in thread* Re: linux-next: manual merge of the l2-mtd tree with the mtd tree
2012-07-17 1:00 linux-next: manual merge of the l2-mtd tree with the mtd tree Stephen Rothwell
@ 2012-07-25 15:21 ` Gerlando Falauto
2012-07-25 15:26 ` David Woodhouse
0 siblings, 1 reply; 9+ messages in thread
From: Gerlando Falauto @ 2012-07-25 15:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Artem Bityutskiy, linux-next, linux-kernel, DavidWoodhouse
Hi folks, Stepehen,
On 07/17/2012 03:00 AM, Stephen Rothwell wrote:
> Hi Artem,
>
> Today's linux-next merge of the l2-mtd tree got a conflict in
> drivers/mtd/chips/cfi_cmdset_0002.c between commit 420962884379 ("mtd:
> cfi_cmdset_0002: Micron M29EW bugfixes as per TN-13-07") from the mtd
> tree and commit 39c0c188e160 ("mtd: cfi_cmdset_0002: Micron M29EW
> bugfixes as per TN-13-07") from the l2-mtd tree.
>
> I just used the version in the mtd tree.
I have no clue how the whole linux integration process works, so please
forgive me if what I'm about to say will sound silly to all of you...
I'm just reading the above mail (a few days later than the original
post) and I can't figure out what happened.
At first I could not find commit 39c0c188e160 out of the master branch
in l2-mtd (http://git.infradead.org/users/dedekind/l2-mtd.git), then I
tried again with the commit ID and found it, but now I can't figure out
what branch it belongs to (looks like an orphaned branch).
Except that it differs from the "good" commit 420962884379 in that it
has been commited by Artem (as opposed to David), and *not*
signed-off-by David.
So could someone please spend a few words on what happened in the meantime?
To me it looks like the l2-mtd tree got rebased at some point, but I'm
quite at loss about this whole back-and-forth between trees.
I'm sure a few words could make my life much easier... :-)
Thanks a lot!
Gerlando
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: linux-next: manual merge of the l2-mtd tree with the mtd tree
2012-07-25 15:21 ` Gerlando Falauto
@ 2012-07-25 15:26 ` David Woodhouse
2012-07-25 15:36 ` Gerlando Falauto
0 siblings, 1 reply; 9+ messages in thread
From: David Woodhouse @ 2012-07-25 15:26 UTC (permalink / raw)
To: Gerlando Falauto
Cc: Stephen Rothwell, Artem Bityutskiy, linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
On Wed, 2012-07-25 at 17:21 +0200, Gerlando Falauto wrote:
>
> So could someone please spend a few words on what happened in the meantime?
> To me it looks like the l2-mtd tree got rebased at some point, but I'm
> quite at loss about this whole back-and-forth between trees.
> I'm sure a few words could make my life much easier... :-)
There's no need to worry. The l2-mtd tree is rebased on top of the mtd
tree, and contains patches that Artem thinks I'm likely to accept.
I apply them, sometimes with a few minor changes, or I occasionally
reject them. Sometimes if Artem doesn't *immediately* update his tree
after I push changes to mine, a 'conflict' appears between the two. You
can ignore it.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the l2-mtd tree with the mtd tree
2012-07-25 15:26 ` David Woodhouse
@ 2012-07-25 15:36 ` Gerlando Falauto
2012-07-25 15:39 ` David Woodhouse
0 siblings, 1 reply; 9+ messages in thread
From: Gerlando Falauto @ 2012-07-25 15:36 UTC (permalink / raw)
To: David Woodhouse
Cc: Stephen Rothwell, Artem Bityutskiy, linux-next, linux-kernel
Hi David,
On 07/25/2012 05:26 PM, David Woodhouse wrote:
> On Wed, 2012-07-25 at 17:21 +0200, Gerlando Falauto wrote:
>>
>> So could someone please spend a few words on what happened in the meantime?
>> To me it looks like the l2-mtd tree got rebased at some point, but I'm
>> quite at loss about this whole back-and-forth between trees.
>> I'm sure a few words could make my life much easier... :-)
>
> There's no need to worry. The l2-mtd tree is rebased on top of the mtd
> tree, and contains patches that Artem thinks I'm likely to accept.
>
> I apply them, sometimes with a few minor changes, or I occasionally
> reject them. Sometimes if Artem doesn't *immediately* update his tree
> after I push changes to mine, a 'conflict' appears between the two. You
> can ignore it.
>
thanks for your explanation.
So, is it correct to say that any patch contained within l2-mtd (but
*NOT* within linux-mtd) will eventually be killed? (Or rather,
*replaced* by the version eventually applied to linux-mtd)?
In other words, when you say "Artem updates his tree", it is technically
a rebase (so his version of a patch actually looks as if never existed),
right?
Thanks a lot!
Gerlando
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: linux-next: manual merge of the l2-mtd tree with the mtd tree
2012-07-25 15:36 ` Gerlando Falauto
@ 2012-07-25 15:39 ` David Woodhouse
0 siblings, 0 replies; 9+ messages in thread
From: David Woodhouse @ 2012-07-25 15:39 UTC (permalink / raw)
To: Gerlando Falauto
Cc: Stephen Rothwell, Artem Bityutskiy, linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
On Wed, 2012-07-25 at 17:36 +0200, Gerlando Falauto wrote:
>
> thanks for your explanation.
> So, is it correct to say that any patch contained within l2-mtd (but
> *NOT* within linux-mtd) will eventually be killed? (Or rather,
> *replaced* by the version eventually applied to linux-mtd)?
Usually, yes. It'll either get applied in some form or other to the
linux-mtd tree, or on the infrequent occasions that Artem merges
something that I object to, the author will get an email from me
explaining *why* it wasn't applied.
Sometimes I *do* just pull everything from Artem's tree, but usually I
don't.
> In other words, when you say "Artem updates his tree", it is
> technically a rebase (so his version of a patch actually looks as if
> never existed), right?
Yes.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* linux-next: manual merge of the l2-mtd tree with the mtd tree
@ 2013-03-15 0:53 Stephen Rothwell
0 siblings, 0 replies; 9+ messages in thread
From: Stephen Rothwell @ 2013-03-15 0:53 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: linux-next, linux-kernel, Brian Norris, David Woodhouse
[-- Attachment #1: Type: text/plain, Size: 16484 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 the mtd tree and
commits a4c121db7e85 ("mtd: nand_ids: minor clean-ups"), c11138000b6d
("mtd: decommission the NAND museum"), edac3311879c ("mtd: nand: remove
AG-AND support") and 663793025e57 ("mtd: nand_ids: introduce helper
macros") from the l2-mtd tree.
I fixed it up (I think - 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,625bc89..0000000
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@@ -10,163 -10,131 +10,134 @@@
*/
#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[] = {
+
+ #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[] = {
- 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] 9+ messages in thread* linux-next: manual merge of the l2-mtd tree with the mtd tree
@ 2013-03-15 0:58 Stephen Rothwell
2013-03-15 8:32 ` Artem Bityutskiy
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Rothwell @ 2013-03-15 0:58 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: linux-next, linux-kernel, Brian Norris, David Woodhouse
[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]
Hi Artem,
Today's linux-next merge of the l2-mtd tree got a conflict in
include/linux/mtd/nand.h between commit 5bc7c33ca93a ("mtd: nand:
reintroduce NAND_NO_READRDY as NAND_NEED_READRDY") from the mtd tree and
commit edac3311879c ("mtd: nand: remove AG-AND support") 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 include/linux/mtd/nand.h
index ef52d9c,33516eb..0000000
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@@ -165,35 -145,8 +145,15 @@@ typedef enum
*/
/* Buswidth is 16 bit */
#define NAND_BUSWIDTH_16 0x00000002
- /* Device supports partial programming without padding */
- #define NAND_NO_PADDING 0x00000004
/* Chip has cache program function */
#define NAND_CACHEPRG 0x00000008
- /* Chip has copy back function */
- #define NAND_COPYBACK 0x00000010
- /*
- * AND Chip which has 4 banks and a confusing page / block
- * assignment. See Renesas datasheet for further information.
- */
- #define NAND_IS_AND 0x00000020
- /*
- * Chip has a array of 4 pages which can be read without
- * additional ready /busy waits.
- */
- #define NAND_4PAGE_ARRAY 0x00000040
- /*
- * Chip requires that BBT is periodically rewritten to prevent
- * bits from adjacent blocks from 'leaking' in altering data.
- * This happens with the Renesas AG-AND chips, possibly others.
- */
- #define BBT_AUTO_REFRESH 0x00000080
+/*
+ * Chip requires ready check on read (for auto-incremented sequential read).
+ * True only for small page devices; large page devices do not support
+ * autoincrement.
+ */
+#define NAND_NEED_READRDY 0x00000100
+
/* Chip does not allow subpage writes */
#define NAND_NO_SUBPAGE_WRITE 0x00000200
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: linux-next: manual merge of the l2-mtd tree with the mtd tree
2013-03-15 0:58 Stephen Rothwell
@ 2013-03-15 8:32 ` Artem Bityutskiy
0 siblings, 0 replies; 9+ messages in thread
From: Artem Bityutskiy @ 2013-03-15 8:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Brian Norris, David Woodhouse
On Fri, 2013-03-15 at 11:58 +1100, Stephen Rothwell wrote:
> Hi Artem,
>
> Today's linux-next merge of the l2-mtd tree got a conflict in
> include/linux/mtd/nand.h between commit 5bc7c33ca93a ("mtd: nand:
> reintroduce NAND_NO_READRDY as NAND_NEED_READRDY") from the mtd tree and
> commit edac3311879c ("mtd: nand: remove AG-AND support") from the l2-mtd
> tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks Stephen, please, carry this one so far, I'll rebase my tree soon.
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply [flat|nested] 9+ messages in thread
* linux-next: manual merge of the l2-mtd tree with the mtd tree
@ 2016-01-05 2:05 Stephen Rothwell
0 siblings, 0 replies; 9+ messages in thread
From: Stephen Rothwell @ 2016-01-05 2:05 UTC (permalink / raw)
To: Brian Norris, David Woodhouse; +Cc: linux-next, linux-kernel
Hi Brian,
Today's linux-next merge of the l2-mtd tree got a conflict in:
drivers/mtd/mtdcore.c
between commit:
472b444eef93 ("mtd: fix cmdlinepart parser, early naming for auto-filled MTD")
from the mtd tree and commit:
07fd2f871c5e ("mtd: partitions: pass around 'mtd_partitions' wrapper struct")
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/mtdcore.c
index ffa288474820,89d811e7b04a..000000000000
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@@ -590,22 -589,20 +595,22 @@@ int mtd_device_parse_register(struct mt
const struct mtd_partition *parts,
int nr_parts)
{
+ struct mtd_partitions parsed;
int ret;
- struct mtd_partition *real_parts = NULL;
+ mtd_set_dev_defaults(mtd);
+
- ret = parse_mtd_partitions(mtd, types, &real_parts, parser_data);
- if (ret <= 0 && nr_parts && parts) {
- real_parts = kmemdup(parts, sizeof(*parts) * nr_parts,
- GFP_KERNEL);
- if (!real_parts)
- ret = -ENOMEM;
- else
- ret = nr_parts;
- }
- /* Didn't come up with either parsed OR fallback partitions */
- if (ret < 0) {
+ memset(&parsed, 0, sizeof(parsed));
+
+ ret = parse_mtd_partitions(mtd, types, &parsed, parser_data);
+ if ((ret < 0 || parsed.nr_parts == 0) && parts && nr_parts) {
+ /* Fall back to driver-provided partitions */
+ parsed = (struct mtd_partitions){
+ .parts = parts,
+ .nr_parts = nr_parts,
+ };
+ } else if (ret < 0) {
+ /* Didn't come up with parsed OR fallback partitions */
pr_info("mtd: failed to find partitions; one or more parsers reports errors (%d)\n",
ret);
/* Don't abort on errors; we can still use unpartitioned MTD */
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-01-05 2:05 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-17 1:00 linux-next: manual merge of the l2-mtd tree with the mtd tree Stephen Rothwell
2012-07-25 15:21 ` Gerlando Falauto
2012-07-25 15:26 ` David Woodhouse
2012-07-25 15:36 ` Gerlando Falauto
2012-07-25 15:39 ` David Woodhouse
2013-03-15 0:53 Stephen Rothwell
2013-03-15 0:58 Stephen Rothwell
2013-03-15 8:32 ` Artem Bityutskiy
2016-01-05 2:05 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).