linux-kernel - Re: [PATCH] mtd: spi-nor: add support for Microchip sst26vf064b QSPI memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 1 Aug 2017 23:57:49 +0200
From:   Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>
To:     Claudiu Beznea <claudiu.beznea@...rochip.com>,
        marek.vasut@...il.com, dwmw2@...radead.org,
        computersforpeace@...il.com, boris.brezillon@...e-electrons.com,
        richard@....at
Cc:     linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
        nicolas.ferre@...rochip.com
Subject: Re: [PATCH] mtd: spi-nor: add support for Microchip sst26vf064b QSPI
 memory

Hi Claudiu,

Le 28/07/2017 à 11:41, Claudiu Beznea a écrit :
> Add support for Microchip sst26vf064b QSPI memory.
> 
> Signed-off-by: Claudiu Beznea <claudiu.beznea@...rochip.com>
> ---
>  drivers/mtd/spi-nor/spi-nor.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index 196b52f..796aac4 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -1081,6 +1081,7 @@ static const struct flash_info spi_nor_ids[] = {
>  	{ "sst25wf040b", INFO(0x621613, 0, 64 * 1024,  8, SECT_4K) },
>  	{ "sst25wf040",  INFO(0xbf2504, 0, 64 * 1024,  8, SECT_4K | SST_WRITE) },
>  	{ "sst25wf080",  INFO(0xbf2505, 0, 64 * 1024, 16, SECT_4K | SST_WRITE) },
> +	{ "sst26vf064b", INFO(0xbf2643, 0,  4 * 1024, 2048, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },

I don't know what to do in this case; Marek any advice?

The issue is that Microchip SST26 memories are uniform for the 4K erase
sector size but not uniform for other sector sizes (32K, 64K, ...).

Like this, erase operations would work if
CONFIG_MTD_SPI_NOR_USE_4K_SECTOR is defined because then the 20h/21h
opcodes would be used in any case.

However when the former macro is undefined, the D8h/DCh opcodes would be
used instead. Hence erasing sectors in the middle of the memory would
not work as expected because nor->mtd.erasesize == 4 * 1024 but the
actual erase size of middle erase blocks/sectors is bigger: you may
erase more than expected.

Marek, do you think we could take this patch as is, with the known
limitations, and wait for a later patch dealing with non-uniform erase
sector map to fix them?

Also, nor->mtd.erasesize is used by above mtd layer like UBIFS to decide
the size of the Physical and Logical Erase Bloc size. Not sure if this
is still true now but I had troubles the last time I've tried to create
a UBI file-system with a spi-nor memory using a 4K erase sector size

http://lists.infradead.org/pipermail/linux-mtd/2013-July/047665.html

Best regards,

Cyrille

>  
>  	/* ST Microelectronics -- newer production may have feature updates */
>  	{ "m25p05",  INFO(0x202010,  0,  32 * 1024,   2, 0) },
>