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]
Message-ID: <46bc0f6f-30ad-6367-a960-08cf7262e741@wedev4u.fr>
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) },
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ