Re: Problem writing to NOR flash

[ebiederman@lnxi.com (Eric W. Biederman)]

Andy Hawkins <a.hawkins@cabletime.com> writes:

> Hi all,
> 
> After a bit more digging and reading of the data sheet, it appears the
> the chip I'm using doesn't need locking and unlocking. I then went back
> to the version of the code where we had this working (whatever came with
> the 2.4.20 kernel) and found that none of this locking / unlocking
> mechanism was present.
> 
> So, to test I commented out the contents of cfi_amdstd_lock_varsize and
> cfi_amdstd_unlock_varsize, and I can now successfully write to the NOR!
> 
> Are these functions only required for some very specific chips? 

Yes.

> If so,
> what is the *correct* way for this code to determine whether or not they
> are needed (this code is in a 'generic' file, so I'm surprised that
> there's chip specific information in there).

When Thayne wrote the code he was assuming that since there were no
lock/unlock functions the lock/unlock entry points were simply
not called.  And he figured if it actually broken something someone
would scream.  And then he thought someone had removed the code
when cfi_cmdset_0002 was scrubbed a while ago.

In addition that code really is generic, it applies to firmware
hub parts and there are chips that use both cfi_cmdset_0001 and
cfi_cmdset_0002 that can use it.

When I get a chance it is my intention to refactor the probing
routines to make handling of chips with special capabilities
simpler.

As a first step I am putting a few conditionals in cfi_amdstd_setup
so that chips that we won't use those methods on chips that
don't support them.  Then we can look at better ways to organize
the probe code so the probe/setup code is not such a mess.

I have the first chunk done but I'm not ready to check it
in until I have a chance to test it.  And I am swamped right now...

Eric