Hi Boris, > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon@xxxxxxxxxxx] > Sent: Wednesday, October 17, 2018 1:00 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@xxxxxxx> > Cc: Cyrille Pitchen <cyrille.pitchen@xxxxxxxxxx>; Tudor Ambarus > <tudor.ambarus@xxxxxxxxxxxxx>; marek.vasut@xxxxxxxxx; > dwmw2@xxxxxxxxxxxxx; computersforpeace@xxxxxxxxx; richard@xxxxxx; > linux-kernel@xxxxxxxxxxxxxxx; nicolas.ferre@xxxxxxxxxxxxx; > cyrille.pitchen@xxxxxxxxxxxxx; linux-mtd@xxxxxxxxxxxxxxxxxxx; linux-arm- > kernel@xxxxxxxxxxxxxxxxxxx; Cristian.Birsan@xxxxxxxxxxxxx > 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 <boris.brezillon@xxxxxxxxxxx> wrote: > > > On Wed, 17 Oct 2018 09:07:24 +0200 > > Boris Brezillon <boris.brezillon@xxxxxxxxxxx> wrote: > > > > > On Wed, 17 Oct 2018 02:07:43 +0000 > > > Yogesh Narayan Gaur <yogeshnarayan.gaur@xxxxxxx> wrote: > > > > > > > > > > > > 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. > > > > 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 > --->8--- > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index > 9407ca5f9443..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: ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/