CFI vs JEDEC read commands

[Stuart Menefy <Stuart.Menefy@st.com>]

Folks

In adding support for ST M29W160DT I've come across what looks like
a bug in the chip, but but which has exposed what looks like an
inconsistency in the probing in MTD.

The board I'm working on has two banks of Flash mapped into contiguous
addresses, and I was seeing problems when probing for the second bank
of Flash. The problem is that the first bank is being left in command
mode after the probe, and so the second bank is detected as an alias
for the first.

In cfi_cfi_probe() there is a call to cfi_send_cmd(0xff, ...) which I
assume is supposed to reset the device back to read mode to avoid this
problem. However the ST chip uses 0xf0 as its reset code, and changing
the 0xff to 0xf0 appears to fix the problem. 

All the documentation I've been able to check, for both CFI and JEDEC
devices, including the ST M29W160DT indicates that an unrecognised
command should put the device back into read mode. Unfortunately the ST
chip doesn't appear to be doing this, which I assume is a bug.

Has anybody else come across a problem like this?

However, this got me looking at the code. In virtually every case, a
'read' command is 0xf0, apart from two (one in cfi_cfi_probe and
the other in cfi_cmdset_unknown), when is it 0xff. Is this
deliberate, and would changing the remaining two to 0xf0 cause any
problems?

Many thanks

Stuart