Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752871AbbHUBiT (ORCPT ); Thu, 20 Aug 2015 21:38:19 -0400 Received: from mail-oi0-f50.google.com ([209.85.218.50]:33269 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752089AbbHUBiR (ORCPT ); Thu, 20 Aug 2015 21:38:17 -0400 MIME-Version: 1.0 In-Reply-To: <20150820203726.GE74600@google.com> References: <1440053705-3836-1-git-send-email-vndao@altera.com> <201508201003.38179.marex@denx.de> <201508201052.47502.marex@denx.de> <20150820203726.GE74600@google.com> Date: Fri, 21 Aug 2015 09:38:15 +0800 Message-ID: Subject: Re: [PATCH] [PATCH v5] mtd:spi-nor: Add Altera Quad SPI Driver From: Viet Nga Dao To: Brian Norris Cc: Marek Vasut , "linux-mtd@lists.infradead.org" , David Woodhouse , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , nga_chi86 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2918 Lines: 67 On Fri, Aug 21, 2015 at 4:37 AM, Brian Norris wrote: > On Thu, Aug 20, 2015 at 05:18:14PM +0800, Viet Nga Dao wrote: >> You might misunderstand the hardware problem i mention here. This soft >> IP controller is able to provide the ID for our Altera EPCS/EPCQ flash >> chips, which are non JEDEC chips. As from EPCQ device data sheet >> (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf), >> the device ID is 8 bit data. > > 8 bits of data is vastly insufficient for uniquely identifying a flash. > This is not extendible and is not really a candidate for inclusion in > mainline, unless it's somehow guaranteed that these flash can only be > used with your controller (and I'm not sure how you would do that). > Otherwise, you need to augment every flash with more out-of-band > device-tree information. > >> The remaining problem here is that this >> controller is able to support Micron chips but it currently has >> limitation in providing only 8 bit ID, which is not full JEDEC ID for >> Micron chips. > > You're just proving my point. I will not support "READ ID" detection > that is based on only 8 bits of ID. > >> Hence, we are asking hardware engineer to find out the >> solution so that the driver does not need to do any dirty hacking. > > OK, then I wish your hardware team great speed. > >> And >> so, this table should still be here even hardware fix will take place >> or not. > > I'm not sure how you come to this conclusion. > I have this conclusion is because Altera EPCQ/EPCS flashes are non JEDEC. Thus on the spi_device_id table, the ID in the INFO struct must be filled up with zeros in order to matches the current framework. However, since i still persist to have the device id check in my driver, as suggested by Rash, I should implement it locally in my driver. And this table is the look up table for the device ID of supported flashes. Or maybe you can give me any other better idea? > BTW, to reiterate one other question that I feel wasn't adequately > answered: what does the full ID string look like for these EPCS/EPCQ > flash chips? Not the ID as seen by your limited controller, but the ID > that can be reported by the flash chip. Is it really only an 8-bit > number? Or does it have a longer string that your controller just can't > read? > Yes, As you can refer to page 32 of EPCQ flash datasheet (https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cfg/cfg_cf52012.pdf), "This operation reads the 8-bit device identification of the EPCQ device from the DATA1 output pin". Table 29 lists the EPCQ device identifications Nga -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/