From: Russell King <rmk@arm.linux.org.uk>
To: linux-kernel@vger.kernel.org
Cc: dwmw2@redhat.com
Subject: Recent patch to cfi.h screws MTD CFI layer
Date: Fri, 24 Nov 2000 17:56:54 +0000 (GMT) [thread overview]
Message-ID: <200011241756.eAOHutB16267@flint.arm.linux.org.uk> (raw)
The recent patch in 2.4.0-test11 causes MTD to oops the kernel:
diff -u --recursive --new-file v2.4.0-test10/linux/include/linux/mtd/cfi.h linux/include/linux/mtd/cfi.
h
--- v2.4.0-test10/linux/include/linux/mtd/cfi.h Tue Jul 4 10:12:34 2000
+++ linux/include/linux/mtd/cfi.h Tue Nov 7 10:46:04 2000
@@ -92,6 +92,7 @@
int numchips;
unsigned long chipshift; /* Because they're of the same type */
struct flchip chips[0]; /* per-chip data structure for each chip */
+ const char *im_name; /* inter_module name for cmdset_setup */
};
#define MAX_CFI_CHIPS 8 /* Entirely arbitrary to avoid realloc() */
This is what happens to chips[].start during initialisation:
chip 0 start 0
chip 1 start 800000
chip 2 start 1000000
chip 3 start 1800000
Intel/Sharp Extended Query Table at 0x0031
chip 0 start c013b45c <--- overwritten by write to im_name
chip 1 start 800000
chip 2 start 1000000
chip 3 start 1800000
chip 0 start c013b45c
chip 1 start 800000
chip 2 start 1000000
chip 3 start 1800000
number of CFI chips: 4
chip 0 start c013b45c
chip 1 start 800000
chip 2 start 1000000
chip 3 start 1800000
Here is a patch that fixes the problem, and includes a warning to tell
people not to add extra fields after the "chips" element.
--- linux.orig/include/linux/mtd/cfi.h Sat Nov 18 21:54:02 2000
+++ linux/include/linux/mtd/cfi.h Fri Nov 24 17:57:06 2000
@@ -209,8 +209,9 @@
must be of the same type. */
int numchips;
unsigned long chipshift; /* Because they're of the same type */
- struct flchip chips[0]; /* per-chip data structure for each chip */
const char *im_name; /* inter_module name for cmdset_setup */
+ struct flchip chips[0]; /* per-chip data structure for each chip */
+ /* do not add extra fields after "chips" */
};
#define MAX_CFI_CHIPS 8 /* Entirely arbitrary to avoid realloc() */
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King rmk@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next reply other threads:[~2000-11-24 18:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-24 17:56 Russell King [this message]
2000-11-24 18:52 ` Recent patch to cfi.h screws MTD CFI layer David Woodhouse
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=200011241756.eAOHutB16267@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=dwmw2@redhat.com \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).