Usage of MTD_UADDR_UNNECESSARY broken?

[Erwin Authried]

Am Don, den 18.11.2004 schrieb Thayne Harbaugh um 15:44:
> On Thu, 2004-11-18 at 11:50 +0100, Alexander Hoffmann wrote:
> 
> > Then I guess that there is really the bug I described in my first mail.
> > I would recommend a check for MTD_UADDR_UNNECESSARY in the 
> > cfi_jedec_setup(), before
> > the unlock_addrs[] array is  referenced:
> > 
> > if ( uaddr != MTD_UADDR_UNNECESSARY ) {
> >                 p_cfi->addr_unlock1 = unlock_addrs[uaddr].addr1 & mask;
> >                 p_cfi->addr_unlock2 = unlock_addrs[uaddr].addr2 & mask;
> > }
> > return 1;
> 
> Apparently the "& mask" is not done anymore - you must be using an older
> version of jedec_probe.c.
> 
> It looks like your suggestion might be appropriate after the window
> check in jedec_setup() and before the finfo_uaddr() lookup.
> 
> I'm still trying to sort the test at the top of jedec_probe_chip():
> 
>  retry:
> 	if (!cfi->numchips) {
> 		uaddr_idx++;
> 
> 		if (MTD_UADDR_UNNECESSARY == uaddr_idx)
> 			return 0;
> 
> 		cfi->addr_unlock1 = unlock_addrs[uaddr_idx].addr1;
> 		cfi->addr_unlock2 = unlock_addrs[uaddr_idx].addr2;
> 	}
> 
> 
> I'm thinking that the MTD_UADDR_UNNECESSARY test (which checks for the
> end-of-loop condition) should be *prior* to the uaddr_idx++.  The way it
> is, chips that are MTD_UADDR_UNNECESSARY will *never* be tested and will
> *always* fail.

I believe that your conclusion is wrong. jedec_probe doesn't know
a-priori which chip is there, thus it can't omit the test. A test for a
chip with MTD_UADDR_UNNECESSARY will match at the first tested unlock
address, because a chip with MTD_UADDR_UNNECESSARY doesn't care about
the unlock sequence at all.

Regards,
Erwin