You said, if I remember correctly, that it (the chip) is a 16 bit but needed to be accessed in 8 bit mode, in this particular instance? Is that right? ... (davy scratches his head while still waking up... )
This might sound confusing, so I've tried to say too much rather than too little in the hopes that it will help.
First, I don't have a schematic, so I'm not sure how A1, A0 and/or BYTE# are wired. I'm still not sure if it's 8-bit or 16-bit in truth.
Regardless, the CFI probe and detection code only works when all of the CFI table offsets are doubled. This is consistent with addressing a 16-bit flash, since the address lines are typically shifted by one bit. The A0 line (and up) on the flash are driven by A1 and up on the CPU. So byte addresses 0, 2, 4 would access flash word-addresses 0, 1, 2. This is a typical arrangement for 16-bit memory. In most cases the A0 line on the CPU is simply not connected.
The mtd driver doesn't know what the board is doing, so to figure it out, it simply tries it both ways in the probe code. In our case, the probe is successful with an offset scaling factor of two. This is typical for a 16-bit word memory accessed by byte addresses. This "offset scaling factor" is called "cfi->device_type" in the mtd driver.
Flash chips usually want to see commands written to the magic offsets 0x555 and 0x2aa. To get these offsets to appear at the 16-bit flash, the CPU writes to byte addresses 0xaaa and 0x555, which get shifted right due to the A1->A0 hookup, to become 0x555 and 0x2aa, which is what the flash wants to see.
However, what the mtd driver does is it takes the magic offsets 0x555 and 0x2aa and it shifts them left using the scaling factor "cfi->device_type" to produce the necessary doubled CPU byte addresses. This is a problem because a shift-left of 0x2aa does not yield 0x555, but rather 0x554. I think this is the real problem.
Unfortunately, the flash chip really does want the CPU to generate the byte addresses 0xaaa and 0x555. It seems to be emulating the behavior of 16-bit addressing while using byte addresses. The mtd driver writes to 0x554, but this usually works, because the A0 bit would be dropped anyway, i.e. it's not connected.
What I decided to do was change the scaling factor back to one and let the code directly use 0xaaa and 0x555 instead. This should work, because cfi->device_type isn't used for anything else once the detection and CFI table parsing is finished. I dislike the hack on aesthetic grounds, but it works. A more elegant approach would be to fix up the 0x554, whenever it occurs due to the scaling, but I thought the one-liner was simpler, even if it seems weird.