Skip to contentSkip to conversation

Device ID collision in amd_flash.c

PATCH Jonas Holmberg 3 participants 6 messages Feb 2, 2005 – Feb 3, 2005 Memory technology devices (MTD)

lore
Share & tools
lore

Jonas Holmberg

author
#0 lore raw

The (obsolete) AMD NOR-flash driver has an "probe-table-entry" for AM29BDS643D that happens to match AM29DL640G as well, even though they have different block/sector-layouts.

I think the problem is that AMD is assigning device-IDs of more than 16-bits. Anyhow, both AM29BDS643D and AM29DL640G supports CFI, so I would like to remove support for them in amd_flash.c (patch below) to avoid problems.

OK to commit?

/Jonas

PS. Would this patch ever find it's way into Linux 2.4 or just Linux 2.6?

RCS file: /home/cvs/mtd/drivers/mtd/chips/amd_flash.c,v retrieving revision 1.26

amd_flash.c 2 Feb 2005 11:03:07 -0000 renamed from amd_flash.c 20 Nov 2004 12:49:04 -0000 1.26 +0 -12
diff -u -r1.26 amd_flash.c
@@ -67,7 +67,6 @@
 #define AM29LV160DT    0x22C4
 #define AM29LV160DB    0x2249
 #define AM29BDS323D     0x22D1
-#define AM29BDS643D    0x227E
 
 /* Atmel */
 #define AT49xV16x      0x00C0

@@ -618,17 +617,6 @@
                        { .offset = 0x3f0000, .erasesize = 0x02000, .numblocks =  8 },
                }
        }, {
-               .mfr_id = MANUFACTURER_AMD,
-               .dev_id = AM29BDS643D,
-               .name = "AMD AM29BDS643D",
-               .size = 0x00800000,
-               .numeraseregions = 3,
-               .regions = {
-                       { .offset = 0x000000, .erasesize = 0x10000, .numblocks = 96 },
-                       { .offset = 0x600000, .erasesize = 0x10000, .numblocks = 31 },
-                       { .offset = 0x7f0000, .erasesize = 0x02000, .numblocks =  8 },
-               }
-       }, {
                .mfr_id = MANUFACTURER_ATMEL,
                .dev_id = AT49xV16x,
                .name = "Atmel AT49xV16x",
author
#1 lore raw
Quoted 10 lines · Jonas Holmberg

The (obsolete) AMD NOR-flash driver has an "probe-table-entry" for AM29BDS643D that happens to match AM29DL640G as well, even though they have different block/sector-layouts.

I think the problem is that AMD is assigning device-IDs of more than 16-bits. Anyhow, both AM29BDS643D and AM29DL640G supports CFI, so I would like to remove support for them in amd_flash.c (patch below) to avoid problems.

OK to commit?

Silly me, who cares about obsolete drivers...
Let me rephrase that question: Any objections before I commit on friday (tomorrow)?

I still would like to know how bugfixes finds their way into Linux 2.4. As I understand, the main trunk in CVS is for 2.6 and I can't find any 2.4-branch...

Best regards
/Jonas

Quoted 44 lines

/Jonas

PS. Would this patch ever find it's way into Linux 2.4 or just Linux 2.6?

RCS file: /home/cvs/mtd/drivers/mtd/chips/amd_flash.c,v retrieving revision 1.26
diff -u -r1.26 amd_flash.c

amd_flash.c 2 Feb 2005 11:03:07 -0000 renamed from amd_flash.c 20 Nov 2004 12:49:04 -0000 1.26 +0 -12
@@ -67,7 +67,6 @@
 #define AM29LV160DT    0x22C4
 #define AM29LV160DB    0x2249
 #define AM29BDS323D     0x22D1
-#define AM29BDS643D    0x227E
 
 /* Atmel */
 #define AT49xV16x      0x00C0

@@ -618,17 +617,6 @@
                        { .offset = 0x3f0000, .erasesize = 0x02000, .numblocks =  8 },
                }
        }, {
-               .mfr_id = MANUFACTURER_AMD,
-               .dev_id = AM29BDS643D,
-               .name = "AMD AM29BDS643D",
-               .size = 0x00800000,
-               .numeraseregions = 3,
-               .regions = {
-                       { .offset = 0x000000, .erasesize = 0x10000, .numblocks = 96 },
-                       { .offset = 0x600000, .erasesize = 0x10000, .numblocks = 31 },
-                       { .offset = 0x7f0000, .erasesize = 0x02000, .numblocks =  8 },
-               }
-       }, {
                .mfr_id = MANUFACTURER_ATMEL,
                .dev_id = AT49xV16x,
                .name = "Atmel AT49xV16x",

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

#2 lore raw
Quoted 3 lines · Jonas Holmberg

Silly me, who cares about obsolete drivers...
Let me rephrase that question: Any objections before I commit on friday (tomorrow)?

Sorry, go ahead.

Quoted 3 lines

I still would like to know how bugfixes finds their way into Linux 2.4. As I understand, the main trunk in CVS is for 2.6 and I can't find any 2.4-branch...

In general, they don't get in to 2.4. Nobody cares about 2.4 any more. If it _works_ for you, all well and good. But if it hasn't already been working for you for a year, then why are you trying to make it work now? Use 2.6.

Feel free to send this change to Marcelo if you really care.

Signature · 1 line
dwmw2
author
#3 lore raw
Quoted 6 lines · David Woodhouse
Quoted 3 lines · Jonas Holmberg

Silly me, who cares about obsolete drivers...
Let me rephrase that question: Any objections before I commit on friday (tomorrow)?

Sorry, go ahead.

Thanks.

Quoted 8 lines
Quoted 4 lines

I still would like to know how bugfixes finds their way into Linux 2.4. As I understand, the main trunk in CVS is for 2.6 and I can't find any 2.4-branch...

In general, they don't get in to 2.4. Nobody cares about 2.4 any more. If it _works_ for you, all well and good. But if it hasn't already been working for you for a year, then why are you trying to make it work now?

I just noticed the bug. It only reveals itself when you try to erase the first sector on that particular chip, and we never had to do that, until now.

Quoted 1 line

Use 2.6.

Will do, but need bugfix for old stuff too.

It would be quite nice with a 2.4-branch that we can commit bugfixes to that could be sent to Marcelo regularly. But if I'm the first to ask, we probably don't need it.

Quoted 2 lines

Feel free to send this change to Marcelo if you really care.

OK.

/Jonas

#4 lore raw
Quoted 3 lines · Jonas Holmberg

It would be quite nice with a 2.4-branch that we can commit bugfixes to that could be sent to Marcelo regularly. But if I'm the first to ask, we probably don't need it.

We have one for JFFS2. For the MTD code we probably don't need it.

Signature · 1 line
dwmw2
#5 lore raw
Quoted 6 lines · David Woodhouse
Quoted 3 lines · Jonas Holmberg

It would be quite nice with a 2.4-branch that we can commit bugfixes to that could be sent to Marcelo regularly. But if I'm the first to ask, we probably don't need it.

We have one for JFFS2. For the MTD code we probably don't need it.

Unless you finally get around to removing all the inter_module_* stuff and use symbol_{get,put}... ;)

josh