From: ebiederman@lnxi.com (Eric W. Biederman)
To: linux-mtd@lists.infradead.org
Cc: David Woodhouse <dwmw2@infradead.org>, tharbaugh@lnxi.com
Subject: Re: [RFC] refactoring MTD cmdset ops, jedec_probe, and cfi_probe
Date: 13 Jul 2004 23:44:41 -0600 [thread overview]
Message-ID: <m3658rcfcm.fsf@maxwell.lnxi.com> (raw)
In-Reply-To: <m3y8lndhho.fsf@maxwell.lnxi.com>
ebiederman@lnxi.com (Eric W. Biederman) writes:
> Looking at where we are Dave has just reworked the code for handling multiple
> word sizes for reads and writes, and things are just starting to settle out.
> And since he is going to be gone he will be sending these changes to Linus
> later this week.
Ok. Where I am at.
I have modified ichxrom so now is insanely flexibly.
It handles cfi and jedec parts.
It handles 1,2,4 byte bus widths. (Since an LPC bus is packet
based there is no natural bus width).
It still special cases Intel firmware hubs but that is disabled
when it is not dealing with them. Both cases have been tested
both in 32bit and 64bit mode.
I have modified cfi_cmdset_0002 so that it retries in do_write_one_word.
For all of the other commands if an error occurs users can make
progress simply by retrying the command. When do_write_one_word
fails all users can do is erase and rewrite the block. Which
in the face of transient errors (especially from an SST chip)
can fail to make progress.
With those small fixes in place I have the mtd drivers working
for the primary cases I care about. So I should be able
to use what Dave merges into 2.6. now :)
Actually making ichxrom handle nearly every NOR flash case under the
sun was less painful then I thought. So unfortunately there is less
urgency to get the refactoring done now :(
However it is still on my TODO list so I will push it forward in a
little bit.
Eric
next prev parent reply other threads:[~2004-07-14 5:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-13 3:13 [RFC] refactoring MTD cmdset ops, jedec_probe, and cfi_probe Eric W. Biederman
2004-07-13 6:25 ` David Woodhouse
2004-07-13 7:05 ` Eric W. Biederman
2004-07-13 8:02 ` David Woodhouse
2004-07-13 14:23 ` Eric W. Biederman
2004-07-13 14:45 ` Thayne Harbaugh
2004-07-13 15:04 ` Eric W. Biederman
2004-07-13 15:21 ` Thayne Harbaugh
2004-07-13 15:40 ` Eric W. Biederman
2004-07-13 16:00 ` Eric W. Biederman
2004-07-14 5:44 ` Eric W. Biederman [this message]
2004-08-12 7:39 ` Eric W. Biederman
2004-07-13 15:25 ` Eric W. Biederman
2004-07-13 16:17 ` Josh Boyer
2004-08-12 7:13 ` Eric W. Biederman
2004-08-16 14:13 ` Josh Boyer
2004-07-13 16:36 ` Dan Post
2004-07-13 16:52 ` Nicolas Pitre
2004-07-13 17:33 ` Dan Post
2004-07-13 18:17 ` Nicolas Pitre
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=m3658rcfcm.fsf@maxwell.lnxi.com \
--to=ebiederman@lnxi.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=tharbaugh@lnxi.com \
/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