jedec_probe.c bug: AMD AM29LV800 in byte mode

[Steve Wahl <steve.wahl@qlogic.com>]

Hello, list.

I'm newly returning to this list; I used to be on it, went through a
change in employment, and now, surprise, I'm doing some related work
again.

I emailed David (dwmw2) directly to ask how I should aproach this, but
he either didn't get it or correctly blew me off :-).  I'm assuming
the former, but hold nothing against him if it's the latter.

I did see one other post in the archives that refered to the *400, not
*800 version of this chip, but I didn't see any real solution.

The meat of the problem is: when this chip is in byte mode, the id
should be read from location 2, and when the chip is in word mode, the
id should be read from location 1.  The jedec_read_id() code does the
exact opposite.

I'd be more than willing to develop and offer a patch, but I don't
have a clue as to the range of chips this code applies to, and how to
know which ones need to change.  The best I can suggest at the moment
is reading both locations and indicating in the jedec_table[] which
location should be compared with. (Does anybody think that's the right
way to go?  I'll see if I can work such a patch up if so...)

I have a current patch which just changes the location where ID is
read from.  It makes this chip work, but of course breaks all the
others.  

Background:

    System is based on a PPC chip, is currently running Linux 2.4 with
    the old amd_flash.c driver (with a similar patch).  I'm porting
    Linux 2.6 to this system.  Previous 2.4 port person just did the
    patch on his own for this company and as far as I can tell didn't
    inform the world that a change had to be made.  I'd rather get the
    mainline MTD code working so that (A) future ports (Linux 2.8?)
    won't run into the problem, and (B) I have a set of code that will
    still work when my hardware guys decide to change to a flash chip
    that my current kludge breaks.

    If anyone cares, we're not running a filesystem on this chip, just
    need to re-write the boot code with it.  We have another chip
    that's NAND, on which we're using YAFFS.

Thanks for listening,

--> Steve Wahl, Qlogic Corporation.