From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out02.mta.xmission.com ([166.70.13.232]) by bombadil.infradead.org with esmtp (Exim 4.68 #1 (Red Hat Linux)) id 1Kw8Vr-0003bD-Hy for linux-mtd@lists.infradead.org; Sat, 01 Nov 2008 04:55:04 +0000 From: ebiederm@xmission.com (Eric W. Biederman) To: David Woodhouse References: <20081029195349.imqvyxcajuoko0wo@imap.linux.ibm.com> <1225463927.16774.106.camel@macbook.infradead.org> Date: Fri, 31 Oct 2008 21:44:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: ST M29W320D incorrectly configured Cc: jwboyer@gmail.com, linux-mtd@lists.infradead.org, Corinna Schultz List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , David Woodhouse 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