[PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories
From: Yogesh Narayan Gaur <hidden>
Date: 2018-10-17 07:46:41
Also in:
lkml
Hi Boris,
-----Original Message----- From: Boris Brezillon [mailto:boris.brezillon at bootlin.com] Sent: Wednesday, October 17, 2018 1:00 PM To: Yogesh Narayan Gaur <redacted> Cc: Cyrille Pitchen <redacted>; Tudor Ambarus [off-list ref]; marek.vasut at gmail.com; dwmw2 at infradead.org; computersforpeace at gmail.com; richard at nod.at; linux-kernel at vger.kernel.org; nicolas.ferre at microchip.com; cyrille.pitchen at microchip.com; linux-mtd at lists.infradead.org; linux-arm- kernel at lists.infradead.org; Cristian.Birsan at microchip.com Subject: Re: [PATCH v3 1/2] mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories On Wed, 17 Oct 2018 09:10:45 +0200 Boris Brezillon [off-list ref] wrote:quoted
On Wed, 17 Oct 2018 09:07:24 +0200 Boris Brezillon [off-list ref] wrote:quoted
On Wed, 17 Oct 2018 02:07:43 +0000 Yogesh Narayan Gaur [off-list ref] wrote:quoted
quoted
Actually there is no entry of s25fs512s in current spi-nor.c file. For my connected flash part, jedec ID read points to s25fl512s. I have asked my board team to confirm the name of exact connected flash part. When I check the data sheet of s25fs512s, it also points to the same Jedec ID information. { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256, ....} But as stated earlier, if I skip reading SFDP or read using 1-1-1 protocol then read are always correct. For 1-4-4 protocol read are wrong and on further debugging found that Read code of 0x6C is being send as opcode instead of 0xEC. If I revert this patch, reads are working fine.Can you try with the following patch?Hm, nevermind. The problem is actually not related to 4B vs non-4B mode but 1-1-4 vs 1-4-4 modes.
Yes, that's only I have stated in my first mail that instead of 1-4-4 mode read opcode is being sent for 1-1-4 mode.
quoted
Can you try with this patch applied?
With suggested patch, read for protocol 1-4-4 working correctly. [ 1.625360] m25p80 spi0.0: found s25fl512s, expected m25p80 [ 1.631094] m25p80 spi0.0: failed to parse SMPT (err = -22) [ 1.636661] 261 8c4c780 opcode(read:eb, pp:2, erase:d8) [ 1.641878] 266 8c4c780 opcode(read:ec, pp:12, erase:dc) [ 1.647200] m25p80 spi0.0: s25fl512s (65536 Kbytes) Without this patch, param_headers are getting freed and restoring previous erase map i.e. opcode related to 1-1-4 protocol. -- Regards Yogesh Gaur
quoted hunk ↗ jump to hunk
--->8---diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index9407ca5f9443..cf33d834698c 100644--- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c@@ -3132,6 +3132,17 @@ static int spi_nor_parse_sfdp(struct spi_nor *nor, switch (SFDP_PARAM_HEADER_ID(param_header)) { case SFDP_SECTOR_MAP_ID: err = spi_nor_parse_smpt(nor, param_header); + if (err) { + dev_warn(dev, + "failed to parse SMPT (err = %d)\n", + err); + /* + * SMPT parsing is optional, let's not drop + * all information we extracted so far just + * because it failed. + */ + err = 0; + } break; default: