Hi Vignesh, On 12/12/20 05:28PM, Vignesh Raghavendra wrote: > 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.
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
