Problem with cfi_probe.c and Intel chip

[Eric W. Biederman]

David Woodhouse <dwmw2 at infradead.org> writes:

> ahennessy at mvista.com said:
> > I just tried the latest code  and discovered that the command used
> > before the query command  and also to return to read mode  in
> > cfi_probe.c  has been changed to 0xF0 - it used to be 0xFF .  The
> > board I'm testing on has an Intel strata chip and is not responding to
> > the query.  If I use 0xFF, then everything is fine.  AMD chips seems
> > to be happy with either command (
> 
> I seem to recall someone complaining before, and having to change it. But 
> if so, I don't see why it only came in with the jedec-probe stuff. 

O.k. I just did a skim through the JEDEC 21c section 3.5 assuming most
of the time flash designers would follow a variant of the standard.
And at various points both 0xF0 and 0xFF are mentioned as a reset,
with perhaps a little preference towards 0xFF.

The probe algorithm is pretty much reset the chip, and then read it's
id.  So there isn't a lot that can be simplified there.

We are pretty much probing for the jedec 1 byte command set
(intel) or the jedec multibyte command set (amd).  With respect to the
single byte command set, we are already sending the nonsense byte
multibyte prefix and expecting it to ignore it.  So expecting the
multibyte command set to ignore the reset for the single byte command
set is reasonable.  

If we run into further problems we can detangle the single byte and
the multibyte command set probes.
 
> Three options:
> 1. Change it to 0xFF and see if anyone screams.
Well I just did remove 0xFF and see if anyone screams, I should have
looked closer but I thought it was an intel specific then, and nothing
I have required it.  Though I admit 0xFF was not there originally.

> 2. Make it send both 0xFF and 0xF0.
So far I haven't heard of any breakage with this combination.  And now
that I have double checked and discovered in some weird fashion that
they are both equally valid, it is probably safe to leave them both
in.  At least until we hear of further breakage.

> 3. Make it work out what type of chip it's talking to and send the _right_ 
> 	command.
This suffers from extreme catch22.



Eric