* CFI fixup code
@ 2003-05-23 22:50 Stuart Menefy
2003-05-26 8:48 ` David Woodhouse
0 siblings, 1 reply; 3+ messages in thread
From: Stuart Menefy @ 2003-05-23 22:50 UTC (permalink / raw)
To: linux-mtd
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
Folks
Having been bitten several times now by buggy CFI data in various chips, I
thought I'd try and come up with an generic mechanism for working round
this problem.
The changes come in two parts. The largest change is actually just a tidy
up of the code which reads extended CFI tables, providing a utility
function which can be shared by the various CFI command sets, and ensuring
that the device manufacturer and ID is always available.
The second part of the patch is then very small. Simply provide a table
of fixup routines, which can be called as required, to fixup the CFI data.
The current Intel StrataFlash and AMD boot block location bugs have been
moved to use the new mechanism, and I've added a couple of fixups for ST
Flash devices which have appeared in this list over the last year or so.
The patches are available from:
ftp://ftp.superhlinux.com/pub/people/stuart/cfifixup/
Any comments welcome.
Stuart
[-- Attachment #2: Type: application/pgp-signature, Size: 185 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: CFI fixup code
2003-05-23 22:50 CFI fixup code Stuart Menefy
@ 2003-05-26 8:48 ` David Woodhouse
2003-05-26 21:42 ` David Woodhouse
0 siblings, 1 reply; 3+ messages in thread
From: David Woodhouse @ 2003-05-26 8:48 UTC (permalink / raw)
To: Stuart Menefy; +Cc: linux-mtd
On Fri, 2003-05-23 at 23:50, Stuart Menefy wrote:
> Folks
>
> Having been bitten several times now by buggy CFI data in various chips, I
> thought I'd try and come up with an generic mechanism for working round
> this problem.
Me Likee. Thanks. One comment though...
+ if (extp->MajorVersion != '1' ||
+ (extp->MinorVersion < '0' || extp->MinorVersion > '3')) {
You've made it accept CFI table versions 1.0 through 1.3 for _all_
chips, while some were only accepting 1.0->1.2 before.
That's probably not a problem since they _ought_ to be
backward-compatible, but if we actually trusted the hardware
manufacturers to display a modicum of intelligence, we wouldn't have had
that check there at all. And you wouldn't have been writing this patch
in the first place. I'm happy to remove it and perhaps reinstate it if
it ever actually bites.
Other than that, it looks fine. Please go ahead and commit it.
--
dwmw2
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: CFI fixup code
2003-05-26 8:48 ` David Woodhouse
@ 2003-05-26 21:42 ` David Woodhouse
0 siblings, 0 replies; 3+ messages in thread
From: David Woodhouse @ 2003-05-26 21:42 UTC (permalink / raw)
To: Stuart Menefy; +Cc: linux-mtd
On Mon, 2003-05-26 at 09:48, David Woodhouse wrote:
> On Fri, 2003-05-23 at 23:50, Stuart Menefy wrote:
> > Folks
> >
> > Having been bitten several times now by buggy CFI data in various chips, I
> > thought I'd try and come up with an generic mechanism for working round
> > this problem.
>
> Me Likee. Thanks. One comment though...
Oh, and please fix Kb to KiB.
--
dwmw2
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-05-26 21:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-05-23 22:50 CFI fixup code Stuart Menefy
2003-05-26 8:48 ` David Woodhouse
2003-05-26 21:42 ` David Woodhouse
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox