Re: ST M29W320D incorrectly configured

[ebiederm@xmission.com (Eric W. Biederman)]

David Woodhouse <dwmw2@infradead.org> writes:

> On Wed, 2008-10-29 at 19:53 -0400, Corinna Schultz wrote:
>> I'm having a problem getting the unlock addresses correctly configured  
>> for the ST M29W320D chip. CFI query data is shown below (from  
>> debugging statements I enabled and/or added to the driver). The chip  
>> is wired so that the #BYTE pin is low, putting the chip into x8 mode.  
>> The data bus is physically 8 bits.
>> 
>> I don't understand everything that's going on in the code, but it  
>> seems to me that the following code (taken from cfi_cmdset_0002.c,  
>> which sets the unlock addresses needed for writing and erasing) has a  
>> logic error. Maybe someone can explain it to me?
>> 
>>   if (    /* x16 in x8 mode */
>>      ((cfi->device_type == CFI_DEVICETYPE_X8) &&
>>       (cfi->cfiq->InterfaceDesc == 2))
>> 
>> 
>> The reason I think this is in error is that both the device type and  
>> the interfaceDesc are defined by the hardware, and not indicative of  
>> the mode. Besides, isn't this conditional actually testing if the chip
>> is an X8 chip and supports x8 and x16 async modes?

Ok.  I spent some time trying to understand the confusion.  And after looking
at this the code I don't see how we could possibly have a problem.

The only thing that sets device_type is gen_probe.  gen_probe sets
device_type to: map_bankwidth(map)/nr_chips.  Which is the bus width
the chip experiences.  Not how wide the chip actually is.

So I don't have a clue how you can get a device type of x16.  In a 8 bit wide
bus.

> It would be nice if we could do it that way, but these ST chips don't
> seem to work. When they're in 16-bit mode, they really do need a byte
> address of 0x555 for the second unlock address, not 0x554 (0x2aa*2) as
> every other chip seems to accept. Although it takes _extra_ logic to
> check the input on the 'A-1' pin, they seem to have it.

???  In 16bit mode there isn't an a low address pin so you can't even
express a byte address of 0x555.

David if device_type was actually returned or generated by the hardware
your patch makes sense.  But I can't find anywhere that seems to be
happening.

Now perhaps the proper fix is to rename device_type something like device_bus_width,
so it is clearer what is going.  Beyond that I don't see the need for change.

Eric