Re: [PATCH] mtd: spi-nor: Fixup page size and map selection for S25FS-S

[<Tudor.Ambarus@xxxxxxxxxxxxx>]

Hi, Alexander,

On Thursday, February 27, 2020 2:36:57 PM EEST Alexander A Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin@xxxxxxxxx>
> 
> Spansion S25FS-S family has an issue in Basic Flash Parameter Table:
> DWORD-11 bits 7-4 specify write page size 512 bytes. In reality this
> is configurable in the non-volatile CR3NV register and even factory
> default configuration is "wrap at 256 bytes". So blind relying on BFPT
> breaks write operation on these Flashes.
> 
> All this story is vendor-specific, so add the corresponding fixup hook
> which first restores the safe page size of 256 bytes from
> struct flash_info but checks is more performant 512 bytes configuration
> is active and adjusts the page_size accordingly.

Right, clear.

> 
> To read CR3V RDAR command is required which in turn requires addr width
> and read latency to be configured, which was not the case before. Setting
> these parameters is also later required for sector map selection, because:
> 
> JESD216 allows "variable address length" and "variable latency" in
> Configuration Detection Command Descriptors, in other words "as-is".
> And they are still unset during Sector Map Parameter Table parsing,
> which led to "map_id" determined erroneously as 0 for, e.g. S25FS128S.

Please let me know I I get this right. You need to determine the addr_width 
and read_dummy for the RDAR command, in order to determine if the 512 
page_size is active and use that instead. addr_width is not yet set because 
you probably are in the BFPT_DWORD1_ADDRESS_BYTES_3_OR_4 case, and as of now 
the case is not treated. nor->read_dummy is not set because the read operation 
is not yet selected.

Can we safely assume that the read_dummy for the RDAR command has the same 
value as the read_dummy value used for all the array read commands except Read 
(zero latency cycles) and RSFDP (8 latency cycles)? If yes, we can determine 
read_dummy from BFPT and get rid of the try and error iteration.

Next, we can probably use the same values at the SMPT parsing, if you hit the 
SMPT_CMD_ADDRESS_LEN_USE_CURRENT and SMPT_CMD_READ_DUMMY_IS_VARIABLE cases. 

Cheers,
ta


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