From: Dan Eisenhut <deisenhut@wi.rr.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: do_erase_oneblock failing to detect lock-bit failure
Date: Fri, 26 Mar 2004 11:50:46 -0600 [thread overview]
Message-ID: <1080323446.25996.15.camel@localhost> (raw)
In-Reply-To: <1080222037.29835.50.camel@hades.cambridge.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]
On Thu, 2004-03-25 at 07:40, David Woodhouse wrote:
> On Thu, 2004-03-25 at 07:30 -0600, Dan Eisenhut wrote:
> > Is byte-lane swapping common?
>
> Not really. It's generally a symptom of hardware engineers who really
> don't understand the problem, and think it might help.
I looked into why they did this and apparently it was a recommendation
from Motorola. We are using a MPC8270 processor.
> > Wouldn't this code fail for someone
> > without byte-lane swapping but requiring little endian enabled? By
> > changing the if statements with (chipstatus & 0xNN) with (status &
> > CMD(0xNN)) appears to correct my problem, but I sure this is not the
> > best solution.
>
> You made me think about it again and now my head hurts. I suspect that
> we should be using cfi_read_query() to read the status bits, not
> cfi_read().
I tried changing cfi_read to cfi_read_query, which sets status to
0x00a2. But the immediate next check of "if (status & CMD(0x3a))" fails
since CMD(0x3a) resolves to 0x3a00.
Looking at it a little more, I made a couple changes which corrects the
problem for me. (See attached diff) How would this effect other boards
that are currently working on the existing code? I'm not sure how
boards that do any kind of swapping were working in the first place.
Maybe just never tested the return value on an erase to a locked block?
Dan
[-- Attachment #2: mtd_cfi_erase.diff --]
[-- Type: text/x-patch, Size: 1272 bytes --]
diff -uNr clean/drivers/mtd/chips/cfi_cmdset_0001.c mtd/drivers/mtd/chips/cfi_cmdset_0001.c
--- clean/drivers/mtd/chips/cfi_cmdset_0001.c 2004-03-26 10:33:48.000000000 -0600
+++ mtd/drivers/mtd/chips/cfi_cmdset_0001.c 2004-03-26 10:34:26.000000000 -0600
@@ -1373,8 +1373,8 @@
/* check for lock bit */
if (status & CMD(0x3a)) {
- unsigned char chipstatus = status;
- if (status != CMD(status & 0xff)) {
+ unsigned char chipstatus = cfi_to_cpu(status);
+ if (status != CMD(cfi_to_cpu(status) & 0xff)) {
int i;
for (i = 1; i<CFIDEV_INTERLEAVE; i++) {
chipstatus |= status >> (cfi->device_type * 8);
diff -uNr clean/include/linux/mtd/cfi.h mtd/include/linux/mtd/cfi.h
--- clean/include/linux/mtd/cfi.h 2004-03-26 10:33:50.000000000 -0600
+++ mtd/include/linux/mtd/cfi.h 2004-03-26 10:35:42.000000000 -0600
@@ -473,6 +473,21 @@
}
}
+static inline __u8 cfi_to_cpu(cfi_word val)
+{
+ if (cfi_buswidth_is_1()) {
+ return val;
+ } else if (cfi_buswidth_is_2()) {
+ return cfi16_to_cpu(val);
+ } else if (cfi_buswidth_is_4()) {
+ return cfi32_to_cpu(val);
+ } else if (cfi_buswidth_is_8()) {
+ return cfi64_to_cpu(val);
+ } else {
+ return 0;
+ }
+}
+
static inline void cfi_udelay(int us)
{
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,2,0)
prev parent reply other threads:[~2004-03-26 17:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-25 13:30 do_erase_oneblock failing to detect lock-bit failure Dan Eisenhut
2004-03-25 13:40 ` David Woodhouse
2004-03-26 17:50 ` Dan Eisenhut [this message]
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=1080323446.25996.15.camel@localhost \
--to=deisenhut@wi.rr.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.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