mtd: spi-nor: sfdp: Fix SMPT parsing when 4BAIT table is before SMPT

If 4BAIT table appears before SMPT then, nor->addr_width is set to 4 before SMPT table is parsed. This causes SMPT parser code to use addr_width of 4 for reading current sector map configuration in spi_nor_get_map_in_use() if SMPT_CMD_ADDRESS_LEN reads SMPT_CMD_ADDRESS_LEN_USE_CURRENT (see spi_nor_smpt_addr_width()). Instead code should be using the value presented by BFPT_DWORD1_ADDRESS_BYTES field. On S28HS family of devices this bug leads to selection of invalid sector mapping thus causing erase and write failures.

Fix this by parsing 4BAIT address table at the very end after all other parameter tables are parsed.

---
 drivers/mtd/spi-nor/sfdp.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

index 22cb519efe3f..6d4dc1549cc7 100644
@@ -1260,6 +1260,7 @@ static int spi_nor_parse_sccr(struct spi_nor *nor,
 int spi_nor_parse_sfdp(struct spi_nor *nor,
 		       struct spi_nor_flash_parameter *params)
 {
+	const struct sfdp_parameter_header *sfdp_4bait_param_header = NULL;
 	const struct sfdp_parameter_header *param_header, *bfpt_header;
 	struct sfdp_parameter_header *param_headers = NULL;
 	struct sfdp_header header;

@@ -1341,7 +1342,13 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
 			break;
 
 		case SFDP_4BAIT_ID:
-			err = spi_nor_parse_4bait(nor, param_header, params);
+			/*
+			 * Parse 4BAIT table at the end as this will end up
+			 * changing nor->addr_width obtained from BFPT.
+			 * But other parsers, such as SMPT parser, need to
+			 * know default/current addr_width of the flash.
+			 */
+			sfdp_4bait_param_header = param_header;
 			break;
 
 		case SFDP_PROFILE1_ID:

@@ -1369,6 +1376,12 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
 		}
 	}
 
+	if (sfdp_4bait_param_header &&
+	    spi_nor_parse_4bait(nor, sfdp_4bait_param_header, params)) {
+		dev_warn(dev, "Failed to parse optional parameter table: %04x\n",
+			 SFDP_PARAM_HEADER_ID(param_header));
+	}
+
 exit:
 	kfree(param_headers);
 	return err;

2.29.2


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Hi Vignesh,

I'm not convinced this is the best way to go about this. What if we have another table tomorrow that introduces some other side effect? Will we special-case all those as well? IMO a better way of going about this would be to make these parsers not affect the current state of the flash, but instead store that information as a possible future state of the flash. Then we can use that to finally decide what we want to do in spi_nor_set_addr_width(). In fact, that information is already stored via SNOR_F_HAS_4BAIT (though I'm not too opposed to adding a nor->params->addr_width).

I see this as a cleaner alternative to your approach. We do need to be careful about any obscure bugs here like with [0] though.

[0] https://lore.kernel.org/linux-mtd/[email protected]/

Regards,
Pratyush Yadav
Texas Instruments India

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/