Re: [PATCH] mtd: spi-nor: sfdp: Fix wrong addr length and dummy when perform SMPT detection command

[Alexander Sverdlin <alexander.sverdlin@xxxxxxxxx>]

Hi!

On 21/04/2020 05:30, Yicong Yang wrote:
> As per SFDP(JESD216D, Section 6.5.3) says of SMPT 1st DWORD, 11b of
> bit[23:22] and 1111b of bit[19:16] represent variable
> {address length, read latency}, which means "the {address length,
> read latency} last set in memory device and this same value is used in the
> configuration dectection command". Currently we use address length
> and dummy byte of struct spi_nor in such conditions. But the value
> are 0 as they are not set at the time, which will lead to
> wrong perform of the dectection command.
> 
> As the last command is read SFDP(1S-1S-1S, the only mode we use in kernel),
> with 3-byte address and 8 dummy cycles, use the same values in
> variable situations to perform correct dectection command.

Well this will work and as the maintainers ignore the proper and even recommended by them solution,

Reviewed-by: Alexander Sverdlin <alexander.sverdlin@xxxxxxxxx>

> Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table")
> Signed-off-by: Yicong Yang <yangyicong@xxxxxxxxxxxxx>
> ---
>  drivers/mtd/spi-nor/sfdp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index f6038d3..27a8faa 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -624,7 +624,7 @@ static u8 spi_nor_smpt_addr_width(const struct spi_nor *nor, const u32 settings)
>  		return 4;
>  	case SMPT_CMD_ADDRESS_LEN_USE_CURRENT:
>  	default:
> -		return nor->addr_width;
> +		return 3;
>  	}
>  }
> 
> @@ -641,7 +641,7 @@ static u8 spi_nor_smpt_read_dummy(const struct spi_nor *nor, const u32 settings)
>  	u8 read_dummy = SMPT_CMD_READ_DUMMY(settings);
> 
>  	if (read_dummy == SMPT_CMD_READ_DUMMY_IS_VARIABLE)
> -		return nor->read_dummy;
> +		return 8;
>  	return read_dummy;
>  }

-- 
Best regards,
Alexander Sverdlin.

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